|
That is bloody awesome! Yes definitely helped,
many many thanks Steven, I know you must be a very person. Regards, Malcolm From:
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 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.
-- 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
|
- RE: [flexcoders] Cairngorm For Dummies? Malcolm
- Re: [flexcoders] Cairngorm For Dummies? Douglas Knudsen
- RE: [flexcoders] Cairngorm For Dummies? Steven Webster
