I found it on neil's blog
take a look at http://nwebb.co.uk/blog/?p=118
Showing posts with label Cairngorm. Show all posts
Showing posts with label Cairngorm. Show all posts
Thursday, August 30, 2007
Monday, August 6, 2007
10 Tips For Working With Cairngorm
source : here
These apply to Flex 2.0.1 with any version of Cairngorm. Since people’s programming background varies in Flex, these are not facts, just my opinions based on my experiences using ARP & Cairngorm for over 2 years. Furthermore, there are alternatives to Cairngorm, I just cannot try them as much as I like. Now that I’m doing product work, I can’t just “try this framework on this new project”. I live in the same code base longer supporting existing clients, and can’t do dramatic re-factoring without getting fired.
1. If Cairngorm looks complicated, don’t worry, it is, and you’re not alone
“Bunch of code on _root vs. all of these classes and conventions? This’ll take forever!”. It takes getting used to. I felt “comfortable with Cairngorm” on my 4th project with it. To this day, I still mod it though, and try different things. As more people come into Flex, there are more cool ideas and techniques floating around.
2. If it feels like it’s taking a long time just to do something in Cairngorm, it does.
“OMFG… 3 classes just to execute what would take me 1 line in Flash? Lamesauce!”. Code gen can help here, at least at the beginning of the project.
3. Only Commands set data on the Model; you can break this, just don’t if you can help it.
In Model View Controller, only the Controller sets data on the Model. In this case, the Commands are the Controller (usually), and as such, setting ModelLocator data is their job, and their job alone. If data is getting f’d up, you immediately know it’s in the Command. You never have to question “who’s setting my data, where, and when?”.
4. Delegates make the server call and parse the data (sometimes in a Factory)
This has only happened once in my career: I was hitting PHP for the back-end, parsing XML, and in the middle of the project, we switched to OpenAMF and Java where I had to parse objects. Using Delegates means you only have to re-code your Delegates, not the rest of your app. The Commands still get the same data.
The only reason I use Factories is because A) parsing can be a lot of code and you don’t want to make your Delegates look more complicated than they are and B) you can share parsing routines easily in the same Factory class.
5. If you see a Command parsing data, it’s coded wrong.
Parsing is differently from filtering, modifying, and assembling. IE, making Value Objects from XML should be done in the Delegate, not the Command. Making associations between ArrayCollections, injecting default values are both ok. Remember, the key here is if the Command is touching raw server data, you’re either not using Delegates correctly, or have AMFPHP/FDS/WebOrb working correctly, hehe.
6. There are 3 ways to use Commands & Delegates. I prefer A because it’s consistent, leads to short class files, and is very explicit.
A) For every use case, you make 1 Command and 1 Event. This can sometimes also mean 1 Delegate. (ie, LoginEvent, LoginCommand, LoginDelegate)
B) For every use case that’s related, you can consolidate them into a package path. So, Login, ChangePassword, and ForgotPassword would all be in the same class. You’d then use constants to determine which one to run. (ie, LoginEvent has LOGIN, CHANGE_PASSWORD, and FORGOT_PASSWORD as String constants. Your LoginCommand has a switch statement which determines which one to run. Your LoginDelegate has 3 methods; login, changePassword, and forgotPassword that your Command can use.
C) Variances on B. Maybe 1 Event and 1 Command, but multiple Delegates. This is not a cop-out bullet item, rather, I’ve seem many derivatives that can all be traced back to “B with mods”.
7. ViewLocators are considered bad practice.
That said, there are developers who still love and use them. The use case, however, is valid: Having a View “know” when something in a Command has occurred. I use callbacks, some set data on the Model to trigger callbacks on the Views (maybe via a setter function), and some use addEventListener in tandem with CairngormEventDispatcher.
8. ViewHelpers are considered bad practice.
That said, there are developers who love the idea of “code behind”. I’ve yet to see a consistent theme on the blogs and mailing lists. There are 2 reasons that are common:
A) They don’t like mixing ActionScript & MXML.
B) They want to separate their View’s from their “View controller code”
Some use the script tag to point to an external file (lame in my opinion; you have to define your controls as member variables and you end up with twice as many View classes). Some use inheritance where you extend your GUI MXML. Others take the reverse, and have the GUI MXML extend the ActionScript ViewHelper. Some will even take the Composition over extending MovieClip approach I’ve seen a lot of coders do in Flash. Instead of their ViewHelper extending a view class, it’ll instead take a UIComponent as a parameter, say in an init method, and use that UIComponent via composition.
To me, you’ll get over it as you get more comfortable with Flex. Code your components in MXML with code up top in a script tag. If you really need efficiency, or start doing some really low-level, abstract type classes, then you can start coding your components in ActionScript. If you want to get stuff done today, use MXML.
9. Don’t use flash.net.Responder, use mx.rpc.Responder instead.
Yes, it’s frustrating because Flex 2.0.1 doesn’t give you the source, but in my opinion, Flex Builder doesn’t handle same-named classes very well. Just go with what Flex uses, and call it a day. If someone requires flash.net.Responder, code a wrapper to bring him into Flex land. “Sir… you need a tie to get into this restaurant. We have one in the back, one moment.”
10.Try not to have View’s use CairngormEventDispatcher (or Events that extend CairngormEvent use event.disaptch()).
Instead, have those deeply nested views dispatch events. Either bubble them up so a master controller View can then fire off Cairngorm events, or bucket-brigade them up. The most common scenario is itemRenderers that are a custom class in DataGrids.
You:
- make the itemRenderer class. If you have something in it that is clickable, dispatch a custom click event. Make it bubble.
- extend the DataGrid that uses your custom itemRenderer, and put the custom event in the metadata up top. Otherwise, the class that houses the DataGrid will only be allowed to subscribe to the event via MXML, only ActionScript. If you use MXML, it’ll fail to compile because the DataGrid doesn’t have that event in it’s source code.
It may feel cool at first to have a LoginForm for example dispatch the LoginEvent, but if you need to use it for a different purpose elsewhere, you’re screwed; it’s hard-coded to use a specific CairngormEvent. This applies to all components. Encapsulate your components and do your best to do what BT does: “bubble it up”.
These apply to Flex 2.0.1 with any version of Cairngorm. Since people’s programming background varies in Flex, these are not facts, just my opinions based on my experiences using ARP & Cairngorm for over 2 years. Furthermore, there are alternatives to Cairngorm, I just cannot try them as much as I like. Now that I’m doing product work, I can’t just “try this framework on this new project”. I live in the same code base longer supporting existing clients, and can’t do dramatic re-factoring without getting fired.
1. If Cairngorm looks complicated, don’t worry, it is, and you’re not alone
“Bunch of code on _root vs. all of these classes and conventions? This’ll take forever!”. It takes getting used to. I felt “comfortable with Cairngorm” on my 4th project with it. To this day, I still mod it though, and try different things. As more people come into Flex, there are more cool ideas and techniques floating around.
2. If it feels like it’s taking a long time just to do something in Cairngorm, it does.
“OMFG… 3 classes just to execute what would take me 1 line in Flash? Lamesauce!”. Code gen can help here, at least at the beginning of the project.
3. Only Commands set data on the Model; you can break this, just don’t if you can help it.
In Model View Controller, only the Controller sets data on the Model. In this case, the Commands are the Controller (usually), and as such, setting ModelLocator data is their job, and their job alone. If data is getting f’d up, you immediately know it’s in the Command. You never have to question “who’s setting my data, where, and when?”.
4. Delegates make the server call and parse the data (sometimes in a Factory)
This has only happened once in my career: I was hitting PHP for the back-end, parsing XML, and in the middle of the project, we switched to OpenAMF and Java where I had to parse objects. Using Delegates means you only have to re-code your Delegates, not the rest of your app. The Commands still get the same data.
The only reason I use Factories is because A) parsing can be a lot of code and you don’t want to make your Delegates look more complicated than they are and B) you can share parsing routines easily in the same Factory class.
5. If you see a Command parsing data, it’s coded wrong.
Parsing is differently from filtering, modifying, and assembling. IE, making Value Objects from XML should be done in the Delegate, not the Command. Making associations between ArrayCollections, injecting default values are both ok. Remember, the key here is if the Command is touching raw server data, you’re either not using Delegates correctly, or have AMFPHP/FDS/WebOrb working correctly, hehe.
6. There are 3 ways to use Commands & Delegates. I prefer A because it’s consistent, leads to short class files, and is very explicit.
A) For every use case, you make 1 Command and 1 Event. This can sometimes also mean 1 Delegate. (ie, LoginEvent, LoginCommand, LoginDelegate)
B) For every use case that’s related, you can consolidate them into a package path. So, Login, ChangePassword, and ForgotPassword would all be in the same class. You’d then use constants to determine which one to run. (ie, LoginEvent has LOGIN, CHANGE_PASSWORD, and FORGOT_PASSWORD as String constants. Your LoginCommand has a switch statement which determines which one to run. Your LoginDelegate has 3 methods; login, changePassword, and forgotPassword that your Command can use.
C) Variances on B. Maybe 1 Event and 1 Command, but multiple Delegates. This is not a cop-out bullet item, rather, I’ve seem many derivatives that can all be traced back to “B with mods”.
7. ViewLocators are considered bad practice.
That said, there are developers who still love and use them. The use case, however, is valid: Having a View “know” when something in a Command has occurred. I use callbacks, some set data on the Model to trigger callbacks on the Views (maybe via a setter function), and some use addEventListener in tandem with CairngormEventDispatcher.
8. ViewHelpers are considered bad practice.
That said, there are developers who love the idea of “code behind”. I’ve yet to see a consistent theme on the blogs and mailing lists. There are 2 reasons that are common:
A) They don’t like mixing ActionScript & MXML.
B) They want to separate their View’s from their “View controller code”
Some use the script tag to point to an external file (lame in my opinion; you have to define your controls as member variables and you end up with twice as many View classes). Some use inheritance where you extend your GUI MXML. Others take the reverse, and have the GUI MXML extend the ActionScript ViewHelper. Some will even take the Composition over extending MovieClip approach I’ve seen a lot of coders do in Flash. Instead of their ViewHelper extending a view class, it’ll instead take a UIComponent as a parameter, say in an init method, and use that UIComponent via composition.
To me, you’ll get over it as you get more comfortable with Flex. Code your components in MXML with code up top in a script tag. If you really need efficiency, or start doing some really low-level, abstract type classes, then you can start coding your components in ActionScript. If you want to get stuff done today, use MXML.
9. Don’t use flash.net.Responder, use mx.rpc.Responder instead.
Yes, it’s frustrating because Flex 2.0.1 doesn’t give you the source, but in my opinion, Flex Builder doesn’t handle same-named classes very well. Just go with what Flex uses, and call it a day. If someone requires flash.net.Responder, code a wrapper to bring him into Flex land. “Sir… you need a tie to get into this restaurant. We have one in the back, one moment.”
10.Try not to have View’s use CairngormEventDispatcher (or Events that extend CairngormEvent use event.disaptch()).
Instead, have those deeply nested views dispatch events. Either bubble them up so a master controller View can then fire off Cairngorm events, or bucket-brigade them up. The most common scenario is itemRenderers that are a custom class in DataGrids.
You:
- make the itemRenderer class. If you have something in it that is clickable, dispatch a custom click event. Make it bubble.
- extend the DataGrid that uses your custom itemRenderer, and put the custom event in the metadata up top. Otherwise, the class that houses the DataGrid will only be allowed to subscribe to the event via MXML, only ActionScript. If you use MXML, it’ll fail to compile because the DataGrid doesn’t have that event in it’s source code.
It may feel cool at first to have a LoginForm for example dispatch the LoginEvent, but if you need to use it for a different purpose elsewhere, you’re screwed; it’s hard-coded to use a specific CairngormEvent. This applies to all components. Encapsulate your components and do your best to do what BT does: “bubble it up”.
Sunday, July 29, 2007
Friday, July 27, 2007
Cairngorm ViewHelpers
http://nwebb.co.uk/blog/?p=84
== quote ==
The use of ViewHelpers in an architectural framework seems to be a bit of a grey area/hotly debated topic ( Jesse Warden summed up both of these things in quite an amusing way some time ago here). I don't have the breadth of knowledge to take one side or another, but I can explain how (and why) we are using them in our current project.
From what I can gather, many people see ViewHelpers as a way to locate, keep track of and simplify the use of Views. The rationale goes like this: when you work on a large project with quite a few people, and the team are creating lots of views, it becomes harder to keep track of the views and what they all do - the ViewLocator makes it easy to locate a particular view (using a descriptive String) and ViewHelpers themselves only expose public methods, thus simplifying working with views for people unfamiliar with the internals of that View.
That's not how we use them here.
Using ViewHelpers To Manipulate Existing Views (Without Updating The Model):
In a simplified view of Cairngorm, the Command class retrieves some info from a DataBase and updates the Model. The View is then updated through bindings to the Model. The Command should not know about the View.
So what happens when you want to do something to the View but you don't want to store anything in the Model? What if you simply wanted to make-visible some text in the View to say that all client-side data was up-to-date? You could set some flag/property in the Model, update that property and get the View to respond, but is that necessarily the right thing to do? Perhaps my simplified example could be better, but there are times where it doesn't feel right to be cluttering up the Model with properties that you don't feel are truly needed or rightly belong in the Model.
Sometimes it seems as if the Command should be able to manipulate the View, yet the Command should know nothing about the View, and you can achieve this with a ViewHelper. The ViewHelper sits in-between the two classes so that the Command and View are no-longer tightly coupled. The Command uses the ViewLocator ( a Singleton) to find the ViewHelper, and calls methods on it which in turn call methods on the View.
Note: To me, the notes in the Cairngorm ViewHelper class sound like they are backing up this as a valid use of ViewHelpers.
Using ViewHelpers When Creating Popups:
Let's say that a user needs to see some information (from a database) in order to make a decision about how many "widgets" to create. You are interested in the user's input (i.e. how many widgets he/she wants to create) but you don't want to store all the retrieved information in your application's Model - you are happy to discard it.
In other words, you want to generate a View (a pop-up window) from a Command. Here is an overview:
The Command would run, retrieve some info from the database and generate a pop-up window. The user would use the data to make a decision about how many widgets to create and enter a value in some input field. When he/she presses the "submit" button on the pop-up window, you remove the pop-up and return the input-value back to the Command. The Command then updates the Model with this value and the main View is updated accordingly via bindings.
Once again, this can be achieved using ViewHelpers without breaking the rule about letting the Command know about the View ( in much the same way as described above).
Using ViewHelpers When Adding Listeners To Popups:
Supposing for a moment that you did let your Command directly create your View... another problem with pop-ups that you may encounter, would be that they probably don't exist at the time you want to add any event-Listeners to it. You can try creating the pop-up first and adding the listeners upon creation, but that's not great.
The ViewHelper is a great place for putting an event-proxy. Extend the class and add the proxy functionality.
Now, rather than the Command listening to the View (which may not even exist, in which case you'll get a "null" error), you listen for events as if they were dispatched from the ViewHelper:
i.e. myViewHelper.addListener ("evtName", someFunc);
One way of coding this could be that when the Command tries to add a listener to the ViewHelper, you take all that info, wrap it up in an object and store it within an array on the ViewHelper.
As soon as the ViewHelper has created the View, it uses that information to add event listeners (between itself and the View). When an event is dispatched from the View it calls the method on the ViewHelper, which in turn calls the corresponding method on the Command class.
Okay, well there are my thoughts on ViewHelpers.
It would be great to hear your opinions (and alternative suggestions) for achieving these types of interactions within a Cairngorm app. Please feel free to leave feedback and add to the already raging debate about ViewHelpers
== quote ==
The use of ViewHelpers in an architectural framework seems to be a bit of a grey area/hotly debated topic ( Jesse Warden summed up both of these things in quite an amusing way some time ago here). I don't have the breadth of knowledge to take one side or another, but I can explain how (and why) we are using them in our current project.
From what I can gather, many people see ViewHelpers as a way to locate, keep track of and simplify the use of Views. The rationale goes like this: when you work on a large project with quite a few people, and the team are creating lots of views, it becomes harder to keep track of the views and what they all do - the ViewLocator makes it easy to locate a particular view (using a descriptive String) and ViewHelpers themselves only expose public methods, thus simplifying working with views for people unfamiliar with the internals of that View.
That's not how we use them here.
Using ViewHelpers To Manipulate Existing Views (Without Updating The Model):
In a simplified view of Cairngorm, the Command class retrieves some info from a DataBase and updates the Model. The View is then updated through bindings to the Model. The Command should not know about the View.
So what happens when you want to do something to the View but you don't want to store anything in the Model? What if you simply wanted to make-visible some text in the View to say that all client-side data was up-to-date? You could set some flag/property in the Model, update that property and get the View to respond, but is that necessarily the right thing to do? Perhaps my simplified example could be better, but there are times where it doesn't feel right to be cluttering up the Model with properties that you don't feel are truly needed or rightly belong in the Model.
Sometimes it seems as if the Command should be able to manipulate the View, yet the Command should know nothing about the View, and you can achieve this with a ViewHelper. The ViewHelper sits in-between the two classes so that the Command and View are no-longer tightly coupled. The Command uses the ViewLocator ( a Singleton) to find the ViewHelper, and calls methods on it which in turn call methods on the View.
Note: To me, the notes in the Cairngorm ViewHelper class sound like they are backing up this as a valid use of ViewHelpers.
Using ViewHelpers When Creating Popups:
Let's say that a user needs to see some information (from a database) in order to make a decision about how many "widgets" to create. You are interested in the user's input (i.e. how many widgets he/she wants to create) but you don't want to store all the retrieved information in your application's Model - you are happy to discard it.
In other words, you want to generate a View (a pop-up window) from a Command. Here is an overview:
The Command would run, retrieve some info from the database and generate a pop-up window. The user would use the data to make a decision about how many widgets to create and enter a value in some input field. When he/she presses the "submit" button on the pop-up window, you remove the pop-up and return the input-value back to the Command. The Command then updates the Model with this value and the main View is updated accordingly via bindings.
Once again, this can be achieved using ViewHelpers without breaking the rule about letting the Command know about the View ( in much the same way as described above).
Using ViewHelpers When Adding Listeners To Popups:
Supposing for a moment that you did let your Command directly create your View... another problem with pop-ups that you may encounter, would be that they probably don't exist at the time you want to add any event-Listeners to it. You can try creating the pop-up first and adding the listeners upon creation, but that's not great.
The ViewHelper is a great place for putting an event-proxy. Extend the class and add the proxy functionality.
Now, rather than the Command listening to the View (which may not even exist, in which case you'll get a "null" error), you listen for events as if they were dispatched from the ViewHelper:
i.e. myViewHelper.addListener ("evtName", someFunc);
One way of coding this could be that when the Command tries to add a listener to the ViewHelper, you take all that info, wrap it up in an object and store it within an array on the ViewHelper.
As soon as the ViewHelper has created the View, it uses that information to add event listeners (between itself and the View). When an event is dispatched from the View it calls the method on the ViewHelper, which in turn calls the corresponding method on the Command class.
Okay, well there are my thoughts on ViewHelpers.
It would be great to hear your opinions (and alternative suggestions) for achieving these types of interactions within a Cairngorm app. Please feel free to leave feedback and add to the already raging debate about ViewHelpers
Conditional visualization in Cairngorm 2.x using the ChangeWatcher class
http://blog.comtaste.com/2007/07/conditional_visualization_in_c_1.html
package ...
{
...
public class MyViewHelper extends ViewHelper
{
private var myChangeWatcher:ChangeWatcher;
public function MyViewHelper() {
myChangeWatcher = ChangeWatcher.watch(MyModelLocator.getInstance(), “myDataSource”, prepareDataProvider);
}
private function prepareDataProvider(event:Event) {
var myAC:ArrayCollection = new ArrayCollection();
for each(var item:Object in MyModelLocator.getInstance().myDataSource) {
//if item satisfies certain conditions
myAC.addItem(item);
}
view.myDataProvider = myAC;
}
}
}
package ...
{
...
public class MyViewHelper extends ViewHelper
{
private var myChangeWatcher:ChangeWatcher;
public function MyViewHelper() {
myChangeWatcher = ChangeWatcher.watch(MyModelLocator.getInstance(), “myDataSource”, prepareDataProvider);
}
private function prepareDataProvider(event:Event) {
var myAC:ArrayCollection = new ArrayCollection();
for each(var item:Object in MyModelLocator.getInstance().myDataSource) {
//if item satisfies certain conditions
myAC.addItem(item);
}
view.myDataProvider = myAC;
}
}
}
Thursday, July 26, 2007
Cairngorm and SequenceCommand Gotcha
source: here
Another quick post about a gotcha I found when using the SequenceCommand in Cairngorm. I was using an iterator in my command to get a next item and determine if I can use that item or if I need move on to the next...an so on. I had originally decided to just make the nextEvent another event that would run the same command and reuse the logic if I needed to try again. Well since then I had to re-factor the code to work all in one shot since apparently not too far into that sequence of commands I get a stack overflow error. I'm surprised at how quickly it happens since there isn't really much going on. So, I like my re-factored code better anyway and this is a bit of info that you might find useful in the rare occasion you might be thinking about causing a command to basically run itself more than a couple times.
Another quick post about a gotcha I found when using the SequenceCommand in Cairngorm. I was using an iterator in my command to get a next item and determine if I can use that item or if I need move on to the next...an so on. I had originally decided to just make the nextEvent another event that would run the same command and reuse the logic if I needed to try again. Well since then I had to re-factor the code to work all in one shot since apparently not too far into that sequence of commands I get a stack overflow error. I'm surprised at how quickly it happens since there isn't really much going on. So, I like my re-factored code better anyway and this is a bit of info that you might find useful in the rare occasion you might be thinking about causing a command to basically run itself more than a couple times.
Wednesday, June 27, 2007
Cairngorm 2.1 Store live example ( Flex, amfphp, Cairngorm )
files needed before running.
amfphp 1.2
RemoteObjectAMF0 - (Flex 2 / Flash Player 9)
Cairngorm 2.2.1 Beta Binary (SWC) more ref, see here
how to
1) make RemoteObjectAMF0 component
unzip renaun_com_RemoteObjectAMF0.zip , u will find src directory, use flex builder
to create new library project RemoteObjectAMF0_comp inside the src folder, then
right click project->properties -> Flex Library Build Path ->Assets , check the
manifest.xml, then select Flex Library Compiler on left side panel , add
additional compiler arguments:
-namespace http://renaun.com/flex/rpc "manifest.xml"
-include-namespaces http://renaun.com/flex/rpc
2) create renaun_com_RemoteObjectAMF0 flex project
right click project->properties -> Flex Build Path -> Add SWC
select the Cairngorm swc and RemoteObjectAMF0_comp swc
3) set CairngormStoreWebMain.mxml as Default application
compile and run it.
here is the live example
amfphp 1.2
RemoteObjectAMF0 - (Flex 2 / Flash Player 9)
Cairngorm 2.2.1 Beta Binary (SWC) more ref, see here
how to
1) make RemoteObjectAMF0 component
unzip renaun_com_RemoteObjectAMF0.zip , u will find src directory, use flex builder
to create new library project RemoteObjectAMF0_comp inside the src folder, then
right click project->properties -> Flex Library Build Path ->Assets , check the
manifest.xml, then select Flex Library Compiler on left side panel , add
additional compiler arguments:
-namespace http://renaun.com/flex/rpc "manifest.xml"
-include-namespaces http://renaun.com/flex/rpc
2) create renaun_com_RemoteObjectAMF0 flex project
right click project->properties -> Flex Build Path -> Add SWC
select the Cairngorm swc and RemoteObjectAMF0_comp swc
3) set CairngormStoreWebMain.mxml as Default application
compile and run it.
here is the live example
Subscribe to:
Posts (Atom)