Technical Director
[EMAIL PROTECTED]
Mobile: +44 (0)7977 216 223
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.
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Douglas Knudsen
Sent: 26 June 2005 05:16
To: [email protected]
Subject: Re: [flexcoders] Cairngorm For Dummies?
view.dispatchEvent( { type:"select" } );
from GraphicalProductListViewHelper.as in the cairngorn store app does! Doesn't seem to follow the above event/controller/listener approach.
DK
That is bloody awesome! Yes definitely helped, many many thanks Steven, I know you must be a very person.
Regards,
Malcolm
From: [email protected] [mailto: [email protected]] On Behalf Of Steven Webster
Sent: Saturday, 25 June 2005 1:05 AM
To: [email protected]
Subject: RE: [flexcoders] Cairngorm For Dummies?
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 Directoriteration::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
--
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.
--
Douglas Knudsen
http://www.cubicleman.com
this is my signature, like it?
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
--
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
- Visit your group "flexcoders" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
