jesus, if one inocent question can do that... what would a full time consulting contract get me?!
(standing ovation) Aldo On 6/24/05, Steven Webster <[EMAIL PROTECTED]> wrote: > > Hi guys, > > The book does kinda build up through the Web Services and Java Chapters to > explaining why we introduce the patterns, but it was never intended as a > ground-zero to hero guide. We are midway through blogging the Cairngorm > Store, but once again have become a little busy with consulting. > > The chapter "ActionScript 2.0 Design Patterns for Rich Internet > Applications" in the ActionScript 2.0 Dictionary discusses the motivation > for patterns a great deal; I'm awaiting that chapter as a PDF from > Macromedia Press, and will blog at www.richinternetapps.com as soon as it's > available. > > Here's a crib-sheet for dummies though. > > Take one use-case as follows: > > "On hitting the send/receive button, the system will poll the server for new > messages since the last request, return any new messages to the client and > display them in the inbox" > > Let's assume this is your first use-case you've implemented, and you have no > application built whatsoever. > > 1. Create a flex project (unzip flex.war) > > 2. Pull the cairngorm SWC into your project so you have all the classes > available to you > > 3. Create Index.mxml > - Make sure and instantiate your controller (so that your > application has a brain) > - Make sure and instantiate your Model Locator (so that your > application has a memory) > - Make sure and instantiate your Service Locator (so that your > application has a voice) > > 4. Create your user-interface using Flex. However you like. We don't > care. > > 5. When the user clicks your send/receive button, that's a user-gesture, > and it's Cairngorm time. > - On Button click, broadcast a "sendReceiveMessage" to your > controller > 6. Tell your controller to listen for that message. More importantly, > make sure your controller knows > who it's gonna call when it hears that message > - In the controller, register a SendReceiveMessageCommand to the > "sendReceiveMessage" event > 7. Now you need to provide that SendReceiveMessageCommand > - It's a command, so implement the Command interface > - It's going to invoke the server, and handle the responses from the > server, so implement the Responder interface > - Implement an execute() method on your command to do all the work > when the controller says so > - In your execute() method, call some business logic for sending > and receiving messags > - In your execute() method, call the sendReceiveMessages() > method on your business delegate > > 8. Grand. Now you have a command that will be executed every single time > the controller hears the event > corresponding to the user clicking the send/receive messages button. > > 9. Now you need to provide the business delegate. So create > MessagingDelegate. On MessagingDelegate, > add a method called "sendReceiveMessages()" for your command to call > - In the constructor of the delegate, lookup the MessageService > - In the sendReceiveMessages method, call the method on the delegate > - Think of the delegate as a proxy to some server-side method > somewhere. Who cares how that server-side > method works, all you need to care about is that it does. It'll > return an array of messages, and all that > mx.utils.Delegate() magic in your delegate methods (see Cairngorm > examples) will ensure that your > SendReceiveMessageCommand that called it, will get those messages > as results. > > 10. Getting there. Problem is, we don't have a service. So let's now > open up our Service Locator in Services.mxml > - Add a definition of the service. Maybe it's a RemoteObject. > Maybe it's a Web Service. If you're really bad, > maybe it's an HTTPService. But don't worry, it the Service > Locator's little secret - the delegate, and all the > other business logic in your app need never know how it was > implemented. This is good. > > 11. I'll assume for now you've implemented the server-side service. I > hope you used RemoteObject to access it > as well, whether it was a Java POJO or a CFC. > > Recap time. So user clicked a button, you broadcast an event. You told your > controller to listen for that event, > and you told the controller what command to call when that event happened. > You wrote the command, you > added an execute() method, and that execute method called the business logic > to send and receive messages. > Your business delegate asked the service locator for the service (it doesn't > know what kind of service it is, the > service locator hides all of those unnecessary details) and called it, and > then handed the results back to the > command class. > > But wait. What is the command class going to do with the results. > Cairngorm time. > > 12. Add an onResult() method to your SendReceiveMessageCommand. In fact, > you implemented the > Responder interface earlier, so the compiler won't let you away with > NOT implementing it. In that > onResult() method, Flex is going to hand you an array of results > from the server. Let's assume that > it hands you an array of ValueObjects that are going to simply have > attributes for all the properties > of your messages. from, date, subject, messageBody, etc. If you > used registerClass on your > value objects, they'll be identical to your server-side value objects > if you're using Java. Anyway. > > 13. Inside your onResult() method, you want Flex to update the user > interface (the Inbox) with the > new message details. You want to change the model, and as a > consequence, have the view > update. Model .. updating view ? Sounds like data-binding to me. > > 14. Create something on your ModelLocator called newInboxMessages:Array > - in the onResult() method of your command, update newInboxMessages > in your model locator, > to contain the new messages that your onReuslt() method just > received back from the server. > > 15. Go find the data-grid you used to implement your Inbox. Bind the > dataProvider of that data-grid > to newInboxMessages on your model locator. You just worry about > updating the model, let > binding worry about notifying and updating the view. > > And that's it. > > That's the thought process you go through in taking a use-case and > implementing it with cairngorm: > > 1. Broadcast event > 2. Make sure event is registered with controller, and make sure it tells > controller which Command to use > 3. Write the Command. Have it use the business delegate to call services, > have it use the model locator > if it needs to know any state before calling the command, and have it > use the model locator to update > the state when it's finished. > 4. Add any methods to the relevant business delegate that are required by > the command > 5. Add any services to the service locator that are required by the > business delegate > 6. Bind your view to the model locator. > > Over time ... most of your effort will cycle around 2 and 3, and application > development will proceed at > a rate of knots. > > I hope the above is useful ..... it's not Cairngorm for Dummies; but it's > the process of breaking a business problem into a technical solution using > Flex and Cairngorm. > > I hope it works for you, > > Best, > > Steven > PS. A bit of grammar and spell checking, and I think I might just have > written Cairngorm for Dummies. Caffeine rocks. > > -- > > > Steven Webster > Technical Director > iteration::two > > > 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. > > > > > > -- > Flexcoders Mailing List > FAQ: > http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Search Archives: > http://www.mail-archive.com/flexcoders%40yahoogroups.com > > > ________________________________ > 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. -- ::::: Aldo Bucchi ::::: mobile (56) 8 429 8300 -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 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: http://docs.yahoo.com/info/terms/
