|
|||||
|
|||
|
6. Development and Deployment This chapter presents important information about developing with Turbine 7 and about deploying into a production server. A few notes are included for Turbine 5.0 users as well as a series of useful tips on working with Turbine. Before
we can do anything with Turbine, we must make sure it is correctly installed
and running. A simple test to see if your Turbine installation is running
is available here. In this section we'll propose the optimal settings to develop a Turbine application and the tools provided by Turbine for debugging. Turbine keeps its settings in a text file located at the root of its installation named system.settings. In this file Turbine stores things like: the default font to use, image settings, debug settings, etc. All these settings are global and can be customized, by simply editing this file (and restarting your web server). Some of these settings are important to simplify the development and debugging tasks - the recommended settings for this purpose are:
This setting
tells Turbine to always include the Turbine Window in the generated
media. The Turbine Window will show the errors and warnings log for
the current media - it is also very useful if you want to trace messages
from the generated Flash, through the turbineDebug(msg) Action
Script function.
This setting
tells Turbine to log all the errors and all the warnings. With this
configuration you will receive all the warnings and errors that might
occur during the media generation.
The above setting tells Turbine to log into the Turbine Window as well as into a text file. This text log file is located on the Turbine installation directory and is named turbine.log. Please note that these settings are read when Turbine starts up, which is usually when the web server starts or restarts, so any change you did to the system.settings file will only take effect the next time you restart your web server .
In this section we'll describe the steps involved in a typical deployment into a production machine. This description assumes the production machine is already setup, with the web server properly configured and with Turbine properly installed: 1 - Change the System Settings The system.settings file mentioned in the last section should be edited before starting to copy anything to the production machine. First make a backup of the file and set the following settings to:
We could
even remove the warnings (and info if set) since in
a production environment we are not interested in this extra information,
however errors are always important and should be logged.
The media
keyword was removed since we do not want the final user to see any eventual
errors. With this configuration the error log is only sent to the turbine.log
file.
This setting
will hide the Turbine Window. 2 - Copy the files to the target machine To move your application into a production machine, the following steps are involved:
And that's all you have to do - next, test your application to check if it works. If it does not work, please carefully check each one of the above steps, looking for any missing or incorrect step.
Turbine 7 is so much more powerful than its ASP Turbine 5.0 predecessor, that almost every area includes new features. Unfortunately, in the process, some back-compatibility had to be abandoned on some areas. What follows is a resume of some features that have been changed or completely replaced on this new version: DrawScript was replaced by MML Drawscript is no longer available and has been substituted by a much more expressive XML language which we call MML for short. We hope you won't regret this new feature as soon as you see MML working. Old Template Property was replaced by Media loading Turbine 7 no longer has such a concept as a unique template. It was replaced by the concept of several pieces of Media that can be loaded and mixed together. Media templates can now be Flash .swf or MML files. One important difference is that when any media template is loaded it is automatically merged into the resulting media and its Turbine variables are interpreted in the moment they are read. Due to this behavior you should define your Turbine variables and DataSets before you load any media template that depends on such variables or DataSets. Some commands have changed or have been removed Some commands have changed (for the better we believe) and as such you should be careful when using them; other commands have disappeared altogether, usually when better alternatives exist. The list of changes is:
Please
note that Turbine 7 and Turbine 5.0 can co-exist on the same machine
without any problems. In this subsection we will show you some tips that will hopefully transform themselves in time-savers for you. IE displays text "garbage" instead of Flash movie Internet
Explorer (IE) sometimes displays text "garbage" instead of
a Flash Movie - this may happen after a previous ASP scripting error
and when requesting the movie in a full browser window. Explicitly define Media.* settings If not defined, global media settings like the frame rate or Flash version will assume the values of the first media template to be loaded. By explicitly defining the pertinent media settings, you are not dependent on the characteristics of the loaded templates, which can change during the development process. Be careful when dealing with Video Video is a wonderful feature of Turbine 7, but it can create some problems if not used on the right way. Video encoding is, by its nature, a CPU and memory-intensive process, so the following characteristics should be counted on when encoding videos to Flash - most of these are limitations derived from running on a web server environment:
One possible
solution for overload issues is to encode "offline" and save
the resulting file to disk - for instance have a scheduled task that
once a day calls a special page that performs the encoding tasks. Response.Expires = -1 is your friend Everybody already had problems with the web browser cache. To avoid it we encourage you to start your ASP scripts with the line:
Of course, there are situations when you want the web browser to cache the page (but usually not during development). Server time vs. Client time Be careful not to misunderstand the difference between server time and client time: The resulting media is assembled on server time by loading several kinds of media and that's where Turbine works to assemble media. For instance, Turbine variables and DataSets only exist during server time, and are expanded (transformed in concrete values) during server time. At client time, Turbine already did its work and is no longer present, only its generated media, which is now running. This resulting media (which is now running in the client side) can however have information that previously was in the form of Turbine variables or DataSets, now available on the form of Action Script variables, as long as they were published during server time. Have your .asp files cleaned If your script ends with a Turbine.GenerateFlash command then it's very important to remember not to have any text before the ASP script block ( <% ... %> ) as all this info will be served to the web browser, and can cause the generated Flash Movie to be misunderstood by the Flash plug-in on the browser. Text after the ASP script block where the Flash movie is generated will also be sent to the web browser and can possibly be misunderstood by the Flash plug-in. Don't leave text after the trailing %> of the ASP script block. Components like to be together When using multiple Flash components, it's advisable to create a single Flash .swf with all the components to be included - the .swf acts as a kind of a component library, which is more efficient than including from separate Flash .swf files and rules out any component version mismatches that might occur. |
|||
|
|||