[thelist] RE: Flash Remoting MX v Flash Communications Server MX

Marcus Andersson marcus at bristav.se
Thu Sep 23 10:12:07 CDT 2004

Gavin Lilley wrote:
> To reduce development time, I have been told that the remoting tool is a
> much smarter alternative as I can setup data sources using actionscript
> which is not only faster but the data source changes are handled by flash
> and automatically stored back in the database. 

I'm subscribed to another list devoted to a native XML database called Exist. There was a posting there the 
other day about using Flash Remoting/databinding in conjunction with Exist. The setup is fairly 
straightforward if you know your way around in Flash and I beleive you can save *a lot of* development time 
using the methodology described (it totally shortcuts the need for scripting at the server-level). I can't 
really tell anything about the robustness and stuff since I haven't tried it myself but it does look good on 


Posted to exist-open at lists.sourceforge.net by Olaf Greve at 2004-09-21:

Hi guys,

O.k., as promised, I am now posting my findings as well as the strategy
for successfully using Flash MX 2004 Professional with the eXist XML
database. Note: this message constitutes almost a complete tutorial, so
it is rather LONG, but -IMO- well worth reading and trying out...

Firstly: this message is cross-posted to the
exist-open at lists.sourceforge.net eXist mailing list, as well as to the
flashcoders at chattyfig.figleaf.com Flash mailing list, so there will be
some mutually new stuff for many (most?) people on both lists. Please
feel free to ask details where desired.

Secondly: I'd like to especially thank Wolfgang Meier for creating eXist
as an open source DB; it is excellent, and I greatly appreciated
Wolfgang's quick replies to pleas for help when debugging the
interactivity between both technologies. For those out there who
consider using ultra expensive commercial XML databases such as
Talamino: perhaps it's a good idea to give a glance at:
http://exist.sourceforge.net first.  ;)

Thirdly: the prerequisites for the below are the eXist XML DB (this is a
JDK 1.4+ based Java application, so it nicely works cross-platform - I
successfully tested it under Windows XP as well as under Debian Linux),
as well as Flash MX 2004 Professional, version 7.20.

Then to dig a bit into the gory details:

The strategy is to first add an XML file to the eXist DB. I will not go
into the details of that, as it is straightforward eXist functionality,
and hence a no-brainer. Once that is done, we are ready to set up the
Flash part. There is an excellent tutorial explaining most of what we
have to do at:
(be sure to download the required files at:
www.macromedia.com/go/flmx2004_data_tutorials this includes the
XUpdateResolver component which we will need).

Now that you're somewhat more familiar with the theory behind it, I
shall give a (relatively) brief overview of what I did in order to get
everything working (note: the fake URL www.ourserver.com will of course
have to be replaced by the servername or IP address of the machine on
which the DB is running!):
-Set up an XML file in the eXist DB - let's assume the name 'test.xml'
in a collection called 'testcol'.
-Create a new Flash document (Note: MX 2004 pro, 7.2, using AS 2.0!!!),
and add an XMLConnector component. Use a local copy of the test.xml file
to set-up the schema part of the XMLConnector (see the tutorial for the
logic behind this), and set the XMLConnector's direction to receive
only. Set the 'URL' parameter (direction = in) of the XMLConnector to:
-Add a Dataset component, and 'databind' it to the XMLConnector as in
the tutorial.
-Add a Datagrid component, and 'databind' it to the Dataset as in the
-Add an XUpdateResolver component, and 'databind' it to the Dataset as
in the tutorial.
-Add a second XMLConnector and 'databind' its 'params' parameter to the
Xupdatepacket of the XUpdateResolver component (if so desired you can
also 'databind' the 'results' parameter to an output field, in order to
see what the eXist server returns after update operations). In the 'URL'
parameter (direction = out) you have to specify the address of the eXist
REST servlet, this will be e.g.:
-Now, add a button component as detailed in the tutorial for triggering
the loading of the inititial set of data, the following AS pseudo-code
will be sufficient in the on(click) handler: _root.xmlInCon.trigger()
-Then, add a second button component as detailed in the tutorial for
generating the Xupdatepackets. Add an on(click) handler with the
following code:
on (click) {
-Now for a more tricky action: the standard xUpdatePackets that are
generated will address the data relative to the dataset. You will want
to map this to the actual DB structure. This can be done on the 'schema'
tab of the XupdateResolver component. Select the 'deltaPacket :
DeltaPacket' property, and in the encoder options you can then set the
proper prefix, e.g. (for addressing something a point by means of its ID
attribute in a structure like <park><points><point id='123' x='1'
y='2'/><point id='234' x='3' y='5'/></points></park>), onw would use:
//park/points/point[@id='?id']). This will probably require some
fiddling around until the proper Xupdatepackets are generated. This is
relatively easy to debug though.
-Another tricky bit is that the eXist server requires credentials before
actually allowing updates (this one took me a while to get working!). It
is done by sending an 'Authorization' handler, which is base64 encoded.
So, first you'll need a base64 encoder. Luckily enough one can be found
at: http://ghostwire.com/forums/index.php?showtopic=498&st=0 save the
files as 'base64.as' and put it in Flash's include path (you then do not
have to explicitly include it in the Flash document).
-Once that is over with, we have to make sure the XupdatePacket includes
a custom header, as specified above. In order to do so, select the
XupdateResolver component, and add the following AS code to it:
on (beforeApplyUpdates) {
	var credentials:String = String("myuser:");
	var b64_credentials = new base64(credentials);
	var encoded:String = b64_credentials.encode();
	xupdatePacket.addRequestHeader("Authorization", "Basic " +
Note: the 'credentials' string is of the format: username:password,
shown above is an example for a user called 'myuser' and with no
-That's basically it!

Now, when running the application, the trigger on the first XMLConnector
will load the requested file from the XML DB and propagate the values as
set up to the dataset (or to multiple datasets, if so desired). If the
dataset was 'databound' to some UIs, they will also now contain the read
values. Then, when changing some of the values, the Dataset component
will AUTOMATICALLY keep track of these changes behind the scene. When
the applyUpdates method is triggered, these updates are processed. At
that point in time, the deltaPacket is sent to the XupdateResolver,
which in turn converts it into an Xupdate packet (note: different
resolvers can be used, some of them can e.g. generate SQL statements
instead of Xupdates!), adds the Authorization header to it, passes it
along to the outgoing XML connector, which sends it to the DB, and
returns the results.

Tres cool, n'est pas?  :)

The above may sound tricky, but really it is not. Once this has been
done once, and all steps are clear, you can literally create the
complete datatransfer architecture for applications within an hour time
or so.
Put that opposed to what nowadays is done all too often still, where an
intermediary custom script layer generates custom XML coming from a
relational database model (which also takes considerably longer to work
out than just adding an XML file to an XML DB!).

I certainly know which of these two alternatives I'll be using from now
on!  :)


More information about the thelist mailing list