Hmm, so each fuse action that has any display loads a swf?  This is weird
approach.  What I think is nice about the Flash environment vs. the
traditional web environment is the fact that Flash has 'state'.  The
environment is a little different than web programming, it is more similar
to "traditional" programming.  It's the end of a long day, so let me see if
I can collect my thoughts and attempt to explain this properly.

On the web, each action the user takes is individual and un-connected.  In
CF and other languages, we can make up for this lack of state and piece
things together with session, client variables, etc.  In Flash this is
unnecessary, because a Flash application behaves more like a traditional
client application; having full continuous knowledge of the user's behavior.

With Flash, you can do all gathering of user input and retrieving of data
"behind the scenes", using loadVariables() or XML().  You can even load a
completely different Flash movie "behind the scenes" using loadMovie(), so
you never really need to redirect the user to different URLs.

The Flash environment also allows you to write more object-oriented code.
Each Moveiclip can be considered an Object, and each SWF is, in essence, a
movieclip.  You can develop functional Flash components completely
independent of the main application it's included in, much like Fuses I
suppose.  Each movieclip has it's own set of properties and methods.  You
can segment all of your application's functionality into separate objects
(movieclips).    This is nothing new, many languages currently do this.
But, it is much different than the way ColdFusion operates, so it's worth
mentioning.

The common denominator in a Flash application is the main timeline.  This
timeline is similar to the function of main() in C apps, and the main
fusebox in XFB apps(from what I've gathered from the XFB discussion).   All
of the objects that you use in a Flash app can use the main timeline as a
storage place for global variables or what-have-you.

There are parallels between object-oriented code, the way Flash apps are
structured, and Fusebox.  I'm not convinced that Flash can benefit from a
Fusebox implementation.  However, I do think that a slightly tweaked version
of Fusedoc would be great for Flash movieclips.

---
Paul Mone
Ninthlink Consulting Group
[EMAIL PROTECTED]
http://www.ninthlink.com
619.222.7082


-----Original Message-----
From: Scott Vincent [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 29, 2001 3:18 PM
To: Fusebox
Subject: RE: some cool tutorials I'm working on


That is interesting timing. I was just working on a "Flash-box" app myself.

I am embedding a seperate .swf in each .cfm page for both the form input and
the query display pages. The underlying interface for each movie comes from
a shared library and it's a different movie clip for each movie which takes
care of the data. Currently I know nothing of WDDX (so I am interested in
seeing Steve's implementation of this) so I was planning on creating an xml
document from the database in .asp on the server and then parsing that into
the Flash movie clip.

When I get the examples cleaned up I'll post them as well.

Scott

-----Original Message-----
************************ Model Citizen ************************
Since so many people have asked me about how you connect Flash to a
Fusebox application I'm creating a series of tutorials on
SecretAgents.com to do so.

The cool part... instead of the display fuses containing HTML they
output a WDDX packet. The WDDX is then passed into the Flash movie and
the user interface is displayed there with the data passed in as WDDX.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at 
http://www.fusionauthority.com/bkinfo.cfm

Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Reply via email to