Caringorm Drawback a solution..

This blog is thanks to Derrick's views which I concur with and the inspiration for this sample code from joe's Blog ..

What led to this code..

1. The cairngorm draw back of a failure to communicate from the command to the view.

2. The non ability to track an event after dispatch which is very essential.

A extremely detailed analysis is available courtesy Jess.

A small review of the code... (details available at joe's Blog)...

From the command one can send results or intimate the view that a particular event has completed or faultered.

 

So we dispatch an cairngorm event from the command. This is controlled by viewcontroller a sort of frontcontroller and another || sort of command which handles the event.

Now in the view we are listening to this event so as soon as this event occurs the functions are performed. 

This introduces a lot of flexibility in the view and the command is reusable and it gets into the true code reuse formula...

sample code..

Cairngorm Phew!!!

Cairngorm was always a slippery eel. You hold one class the other slips through your hands. But thanks to David Tucker & other bloggers it enabled me to put together an example which one may relish. Probably it may be just another example but you know what my exp. says the more examples you browse:

1. You get better in reading code.

2. You get a different perspective.

3. Nobody can say you ripped in out from this blog..just joking..

Lets start with few basics. I know this ya da da da is there every where but its important you know.. My post must be long you see... So here goes my version..

First thing none of these bifurcations are strict you could implement every thing in one page or break it into tiny pieces.. Why? since the whole community is reading it like that nah it makes sense on a long run.

You must have  a Main.mxml which is going to house all other elements of this jig saw puzzle. 

modelLocator will hold the variables which area going to be common across modules and which has to be accessed in the command section. we'll see that later.

view: this will hold the view section or the so called front end of the flex application

vo(value object): some thing like a bean we use in java while send data to the event to the command. I am coming to that ..

Front controller: the supervisor.. He says which event is linked to which command. 

Event: when you want to perform an operation we could trigger an event.. We could pass data into the event too..

Command: At last we are here.. This would perform all the dirty operations talking to database updating the model variables  handling results and all that.. They say the model variables can be touched only by the command ..

service: it holds the declaration of the remoteObject ,Httpservice and all that Just the declaration thats all..

Delegate: Now the command is really over stressed so lets delegate some part of the work. The delegate will talk to the service and handle the remote calls..

Who should bear the results.

The responder is responsible to handle faults and results..

So the command now modifies the model variables and ta da thats cairngorm...

It sounds wierd right.. 

Visit davidtucker.net for some fantastic video tutorials.

The other sites..

cairngormdocs.org

the adobe labs site for cairngorm..

By the way there is a sample application that I promised and here it is

source Files