RE: [flexcoders] Flash + Cairngorm Example With Source Code

[Steven Webster]

Hi Kent,   Thanks Robin and Steven.  That makes total sense.  I have been approaching my current implementation with a background in Java and JSPs not in Cold Fusion or even thinking about it by doing what I would call a poor mans version of web services (xml sans SOAP).  I have been lucky enough to be using the AMF gateway for this.  In the end I am left with the following network architecture:    For avoidance of doubt, I'm approaching this very much from a J2EE background as well, like yourself.  To answer your question on "couldn't a client-side command just invoke server-side command" the answer is that yes, it could.  I'm loathe to become religious about how the patterns should be used, and if your use-case merits the omission of the client-side delegate, then so be it.  You're your own best architect.   However ..... I do prefer that my client-side commands are insulated from the implementation details of the service; that's a "nice" reason for the separation.  However, as an RIA scales, more often than not I would find that a service that is exposed through my client-side delegate, has utility in more than one context.  By way of example ... in an SMS messaging application, I may have a delegate method MessagingDelegate.sendSMS( message : MessageVO )   Now -- I have utility in my application to create a new message, reply to a message and to forward a message ... for new message; when replying to a message, I may want to prefix the message with ">" characters, same with forwarding a message.  Furthermore, I may want new messages and messages I reply to to appear in an Outbox, but forwarded messages to go into a "Forwarded" folder (spare me some poetic license here).  The point ... in all cases I have a need to simply call MessagingDelegate.sendSMS() but for each of these 3 use-cases the preconditions and the post-conditions around that delegate call are different.   With a Command/Delegate separation, the preconditions can be handled in the execute() method of the command, the post conditions can be handled in the onResult() method of the command, but the MessagingDelegate can simply expose the raw functionality of interacting with an SMS gateway and sending a message.   Another example of the utility of commands, is the ability to create base-commands for related use-cases in an application; I'll not provide convoluted example here, but there have been discussions on list about AuthenticatedCommands (commands that should only execute if logged in user with appropriate credentials is present in application state, with a dispatch to login screen if not the case).  Again ... the Command is just a nicer level of abstraction for this behavior, than the delegate, which is really just "delegating the business service calls".   You may not agree ... and that's the great thing about Cairngorm; you don't have to.  If you want to call services directly from the Command class, go for your life.  You may at a later date find yourself refactoring towards the delegate, other times you may not.  For me, experience of building lots and lots of Flash and Flex RIAs is that the separation is common enough that I feel comfortable having it, and now recommending it, as a starting point for archticture, and not something I refactor towards.       Flex Side                     Network                     J2EE Server  ---------       ----------     ||     ---------       -------------------       ------ | Command | <=> | Delegate | <= || => | Command | <=> | Business Delegate | <=> | EJBs |  ---------       ----------     ||     ---------       -------------------       ------   By doing this I allow Struts to be a Command on the server side and can keep my Business Delegate clean of any HTTPRequest or AMF processing knowledge.  I guess the only open question is would you still pass different Command objects to the Delegate on the Flex side and have more then one function in the delegate that does processing or would you keep it as a one to one relationship between Commands and Delegates to avoid accidental calls of the wrong onResult   handler?       The only reason I would see to keep the server-side command, is if you have legacy Struts business logic that you want to build Flex UI upon (or if you want to support Flex + JSP presentation tiers).  Personally, I'd rather see your client-side delegate calling your server-side delegate; the Flex gateway handles all the nuances of AMF (unless you're explicitly using Remoting rather than RemoteObject ... and if so, why ?).  So your server-side delegate can be a POJO that is also protocol unaware (ie it doesn't talk HTTP) and your Flex delegate can invoke that.     One of my beefs with Struts has always been that Commands (Actions) are HTTP aware, which was a pain when wanting to use Struts with alternate presentation tier technologies.  I know there are solutions, I just never found them simple or elegant.   I'd rather see the Command (Action) in Struts handle protocol-specific stuff (ie sticking things in and out of HTTPRequest, HTTPResponse and HTTPSession, passing tokens to prevent double-submits, handling URL encoding, and all that other horrible stuff that Flex has allowed me to forget about :) ) and that business logic be pushed back into the business delegate.  It tends to thicken up the server-side business delegate (ie it's not just a POJO facade to your Stateless Session EJB) but the upside is that it thins out your actions, and makes it MUCH easier to bolt Flex + J2EE together.  The stuff you'll typically have in your server-side Command moves very elegantly towards a rich-client architecture; lots of HTTPSession and HTTPRequest stuffing becomes more elegantly implemented as client-side state (ie the ModelLocator strategy in Cairngorm 0.99) for instance.   But don't get me wrong ... if invoking your Struts actions as the point-of-entry into your J2EE infrastructure works for you, then it works for you.  I'm not challenging it, I'm just saying it's not for me :-)   BTW Once I finally got a grasp on the basics of Cairngorm and Flex my development has been able to movie very fast.        Good to hear ... that's the aim of Cairngorm after all, to get guys like you building bigger Flex apps better and faster.   Look forward to seeing what you produce,   Best wishes,   Steven PS.  Not sure why you're worrying about rich and immersive user-experiences, you're an ASCII art pro. ;)   -- Steven Webster Technical Director iteration::two [EMAIL PROTECTED]   Office:  +44 (0)131 338 6108 Mobile: +44 (0)7977 216 223   This e-mail and any associated attachments transmitted with it may contain confidential information and must not be copied, or disclosed, or used by anyone other than the intended recipient(s). If you are not the intended recipient(s) please destroy this e-mail, and any copies of it, immediately.   Please also note that while software systems have been used to try to ensure that this e-mail has been swept for viruses, iteration::two do not accept responsibility for any damage or loss caused in respect of any viruses transmitted by the e-mail. Please ensure your own checks are carried out before any attachments are opened. Yahoo! Groups Links To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/   To unsubscribe from this group, send an email to: [EMAIL PROTECTED]   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.