|
Contents |
| Articles |
| Behaviors |
| Books |
| Director News |
| Director Web Sites |
| FAQ |
| Games |
| Mailing Lists |
| News Groups |
| Project Examples |
| Reviews |
| Software |
| Tools |
| Useful Web Sites |
| Utilities |
| Xtras |
|
Added on 1/8/2001
|
Developing Projects Using Director and ASP
|
Compatibilities: |
Rating: |
For this article I thought I'd pass on my experiences with developing Director/Shockwave movies using ASP. The following tips are from my own experiences and I've tried, wherever possible, to pass on what I believe to be 'best practice'. Many of these tips are applicable to other scripting languages and you should adapt them to whatever your situation is.
Get the source|
Do Some Preparatory Planning
One of the first things I did was to build my Director project, create the website and build the scripts. It seemed like the way to go. After all, the bulk of the work was in Director, so this took up most of my time. Then I 'shopped' for a host. Of course when I went with my first host, the directories were mapped in a completely different way, so I had to reconfigure the site structure, then recode the URL's in Director and upload everything. After this, I had a few weeks of frustration with the host. Things that they promised worked, didn't and I decided to go with a new host. Of course, they were on a completely different server and mapped everything differently, so I had to do it all again. Now I always do some investigation. I check out the host's reliability, either by finding someone who uses them and or trying to get some URL's from the host and test that it all works. I try to either talk to them on the phone or see how fast they respond to email queries. What language(s) do they support? What's the server running on? Do they access a Database using DSN or DSN-less connections? Once I've decided to go with them, I then investigate the site structure and map this structure on my hard drive. It will cut your development time in half and enables you to remove site structure as part of the debugging process. Get A Personal Web Server Now that you have a site you should get a local web server that is either the same as or closely mirrors your web host's server. There are many available but pay careful attention to which language(s) your going to write your scripts in. There's no point in getting Apache if you want to run ASP. Though you can get some ASP support with Apache, you will not be able to get access to a database unless you get another add-on. If you're going to do ASP, use PWS(Win95,98) or IIS(NT, Win 2000) which are on the Windows CD. You will also have to get the latest update to MDAC, Microsoft Data Access Components. NOTE: if you're using PWS then you will get an error dialog stating that MTS (Microsoft Transaction Server) failed. This is OK and will not affect any of your operations. Database Access Database access is achieved in one of two ways. DSN - a dsn(Data Source Name) is an alias to your database. When you access your database the server will look up the alias name and then translate this to a path and the driver to use to access the DB. DSN-less - a dsn-less connection means that you specify the path and driver to use eg The advantages are that a DSN wraps everything up quite neatly, whereas a DSN-less connection is faster and can also support more concurrent users than a DSN. Personally, I use a DSN-less connection. More. Use Server-Side Includes In the beginning I hard coded everything. It was a way of learning the language and coming to terms with how to implement it. Everytime I wrote a script that accessed the Database, I also rewrote the code to connect to it. This was pretty much always the same. Now I use an include file that creates a connection string eg <% Dim dbPath function getPath(choiceIn) Select Case choiceIn Case "" dbPath = "C:mySitemySiteRootdbmyDB.mdb" Case "yes" dbPath = "D:webspacemySitemySiteRootdbmyDB.mdb" End Select getPath = "PROVIDER=MICROSOFT.JET.OLEDB.4.0;DATA SOURCE=" & dbPath End Function %> The script is wrapped up in a function. Why have I done this? On my test machine the site is on drive C whereas on my web host's machine it's on drive E as well as having one extra folder to access. What this allows me to do is then pass the variable, choiceIn from Director, either as an empty string or as "yes". If the string is empty then we're testing locally. If not, then we're on the server. If I saved this script as 'myconnection.asp' I could use it in any subsequent scripts like so: <%@ LANGUAGE = "VBSCRIPT"%> <% Dim choiceIn, oConn choiceIn = getPath(Request.Form("usePath")) ' open a database connection Set oConn = Server.CreateObject("ADODB.Connection") oConn.open choiceIn ' continue on with the rest of the script %> Use Director To Test Which Address To Use This tip is very similar to using an SSI. When I developed a Director movie locally I would use a local address. When I was then ready to upload the file, I changed all the addresses to point to a web address. Of course, there were times when I forgot to change the address and everything went a bit 'pear-shaped'. So I started to add some additional properties to my behaviours that enabled me to forget about this problem. A typical behaviour script would look like this: property theURL property netID on beginSprite me netID = VOID theURL = getURL(me) end on getURL me if (the runmode contains "Author") then return "http://127.0.0.1/mySite/scripts/ascript.asp" else return "http://www.mySit.com/scripts/ascript.asp" end if end on submit me, data if netID = VOID then netID = postNetText(theURL,data) end if end As you can see, the script now allows for flexibility but the URL's are still hard-coded but at least I can change these from script to script. Always Check Your Data To minimise time spent developing, I created a simple script that reads any data sent from any application, not just Director, using either post or get methods. I always use this script to verify what I'm sending, both locally and on the net. You should to. The script is always available on Shocknet at http://www.shocknet.org.uk/public/sniffer.asp. Just use the URL with your get or postNetText query. Validate On The Client Side Not a Lou Reed song but true all the same. Make sure that your data is in a form that your database expects. Rather than convert a string into an integer on the server, do it in Director. Then you can display a dialog to the user without having to commit to sending the query; the request won't fail and your log files will demonstrate to your host that you are a considerate and respectful user. Returning Data Because ASP and other languages are designed to write results to a web page, most of the methods for writing data are not applicable when working with Director. ASP has a one line statement to return all records from a record set, GetString(). The GetString() method, used with empty parameters, returns all records delimited by a TAB (it's primary use is to write HTML table data). However, we can simply add some parameters to format the data in a more expected format. The following table illustrates some possible outcomes:
If you'd like to see more including some examples then read this tutorial. Making The Development Cycle Easier I don't know about you, but when things don't work, unless the problem seems obvious, you can spend a long time tracking it down. When something does work you can have an enormous feeling of satisfaction. To this end, I've started to have a slightly backwards approach to development. Instead of coding everything first and then testing. I test everything first and then code it. I built a simple utility movie that sits in my xtras folder. With this movie I perform any network process, whether getting a text file, preloading a graphic or some other media file and running a query using get or post methods. When I'm writing some network Lingo I use the movie to test that it all works by just selecting the method and typing in the address. If I'm sending a query then I add the additional name/value parameters. The movie monitors the download, tells you how long it took, file size, mime-type, error status and even reminds you to use preloadNetThing if you try to download a graphic or other media file using getNetText. If you'd like a copy then you can download it in a winzip format and is about 37K in size. Food For Thought Having been working with server scripting languages for a while now, I've tried lots of different ideas and you should investigate some. Did you know you can send SQL from Director? Instead of just sending parameters in a query you can send the SQL to carry out the operation. The upshot is that you only need one script that accepts the SQL string being sent, establishes a connection and either returns a result, inserts a new record or updates a table or field. More Did you know you can embed code in your object and embed tags? Though beyond the scope of this article you can read up on it here. Finally I hope this has given you some good ideas on getting started developing Director projects and using Server Side languages. My experiments with CGI and Director over the past few years have led me to believe that Director can offer a far more flexible environment than just using a web page or a Flash movie. If you have any comments about this article or other ideas then you can email me. I've put some addresses for resources at the bottom of this page. Finally I'd like to thank Chuck for hosting MediaMacros and creating a much needed resource. I'd also like to thank Dave Mennenoh whose HTMLingo was used for all the script examples (saves so much formatting time). And also to all those tireless individuals on the Lingo forum. Take care and good luck Hussein. Resources Cold Fusion Apache MDAC PHP4 MySql php.net for the PHP manual and other documentation Sqlcourse.com learn SQL online As always Shocknet has many tutorials and strategies to integrating Director and server technologies. | |||||||||||||||||||||
Contact |
|
MMI |
Send e-mail