lennel.org

at the design patterns user group tonight. its over at brightcove in cambridge (on the T kendall/MIT)

all good fun.

After playing for a while in flex too i had to do two flex 1.5 projects in a row (of which the second one is in progress). I found states to be an excellent mechanism for laying out forms and applications in flex 2, and pined for simmiliar functionality in flex 1.5. As sometimes happens i happened to stumble on an oppurtunity to build this.

so here is my implementation of states in flex 1.5, on my to-do list is being able to specify which transitions should run when changing one state to another as  this is standard at the moment. also due to licensing issues (i have applied for a flex 1.5 community license and it is being processed) i cannot currently post an example swf, but find included a complete application.

the only tag that is suported  at the moment is the setProperty tag. also note that th default property for the basedOn attribute is the currentState="".

so if you, like me, have to do some flex 1.5 stuff from time to time still, well i hope this helps.

here is an sample of a mcml component.

btw do not use this in the root application (mx:application tag) as it doesn't work in there, too lazy to figure out why, and i never put any code in there anyway so...

i would like to thank my current employers who allowed me to blog this

sample app

In an earlier post i exlpained what states and viewstacks are in the broadest most incomprehensible terms, so after a prompting from Tink i put together a simple example and hopefully a much better and detailed explanation.

abstract:
In the example i have two main views that can be toggled with the buttons on the top saying previous screen and next screen. This toggeling is done via a viewstack's current display index and it gets that info from databinding. Each of those two views in turn has states assigned to them. The first view's states example used mxml to declare the states, whilst the second view (of the collapsable panel) uses an external class which is composed onto the view, the state and effect is thus created via actionscript. The viewstack also illustrates the use of creationpolicy.

the readable information:

on viewstacks, databinding and creationpolicy:
With the what is this behind us, lets jump a but into the explanation of exactly what i did here. the app is viewable here

http://xperiments.lennel.org/ViewStackStatesExample/

and the source is availible via a right click.

In the application entry point (the mx:Application tags) i declare my viewStack that contains the two screens as such:

notice that the ViewStack's selectedIndex (which of the views its displaying) is bound to a property called displayIndex.

the code for that property looks like this

what does this code do. its a simple getter and setter, where the setter checks the bounds on the viewstack so we don't step over the upper limit of the controls within the viewstack and we don't go lower than 0. that is all done in this line:

so the viewstack has an array called childDescriptors where each descriptor represents each compoin the viewstack. check my previous post on creationpolicy and descriptors to understand how descriptors work. Also notice this binding tag

this says that the property (a getter in this case) that follows this line must be made bindable by the compiler/flex. when this property changes the event that it dispaches is called updateView as we can see in this line of code in the setter

so thats a brief overview of databinding in flex as well. nice and easy i think.  ok so lets look at the creationpolicy bit of the second screen in the viewstack.

there are 4 types of creation policy  values all, auto, queued and none. i am not going to go into detail into all of them, instead just discussing what none does. a creation policy of none says don't create this component until i tell you to. the advantage of that is that you only need to use the resources involved in that when you need to. i think creationpoilicy will most likely be a post sometime in the future.

to create a child component when its creation policy is set to none you use

where the second argument says recurse into that component and its childcomponents and create them as well. there are otherways to do this, but i still have a lot to say on states!

now on to states:

the file called MyComponent.mxml has got its states laid out in mxml with the transition defined in mxml as well.

look at this mxml

what does this say. there are 3 states defined here (yes i know there are only two state tags!), the third being the default state, where i put the components to start of with. to change a state all i have to do is set the currentState property to a state-name (each state has a name attribute)

or to revert to the default state set the currentstate property to an empty string. so actionscript wise the potential values look as such based on this example

to get the transitions to work  when i define my transitions

i say from which state to which state this transition must be  used. doing this

means from any state to any state use this transition. thus i can define several transitions and start doing stuff like this:

you get the idea i hope.  the great thing about states in this fashion is that my designers can switch to the design view in flexbuilder, choose which state they are working on, drag the components around, my mxml gets updated, and me as the developer doesn't have to do anything designwise. that is great in my opinion.

however lets take the following example:

i have a certain set of states that i want to reuse accross several components, which might change. so if i declare them in mxml and these states change, then i might have to update it in several places. this would normally be solved using a design pattern called composition in code, but mxml does not give us that luxery.

adding states via composition:

those of you who use other frameworks will now of viewhelpers. a viewhelper is a class that is associated with a view that takes certain types logic  away from the view itself and encapsulates it. my personal preference in this regard is that any kind of logic that must be applied to the data set before it is displayed should be taken care of in a view helper  (thus in my little world it acts as a translator between the model and the view in case they speak different languages) and if the data entered by the user needs to be massaged before a method is called on a controller the viewhelper does that as well. nuff of that, back to the problem at hand.

so what i did is i created a class that adds these states that i want to use in several places to a uiComponent via code, then in my component on the initialize event i create that class and pass in a refrence to the component itself.

so my initialize event's handler fucntion looks like this:

where the second argument is just something that my class uses, and the first argument is a refrence to the component.

so my class looks like this:

excuse all the garbage in the class i mucked around for a fair bit trying different things.

so what does this do?  look at the createStates function. first off i check if this component has other states assigned to it, if it does grab 'em, else create a new array in which i will store my states.

then in this code

i create a state, give it a name, create a setProperty instance and say on which component i want to set the property, the property's name i want to set and the value, then i push the property into the state's overrides array. then lastly i add this new state to the stateArray. repeat for other states i want to create, add water and then leave in the oven for 20 minutes.

then in the following code