tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/10-how-to-handle-statesRobotlegs: Discussion 2018-10-18T16:35:06Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/6105902009-11-19T19:38:06Z2009-11-19T19:38:06ZHow to handle states<div><p>In general, you should try to avoid digging into objects (ie<br>
view.childView.button.addListener) as this creates a very tight<br>
"structural" coupling. It might be better to listen directly to
the<br>
view for custom bubbling events that you fire manually from the
nested<br>
button.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/6105902009-11-19T19:42:28Z2009-11-19T19:42:28ZHow to handle states<div><p>Or, if you are like me and avoid bubbling like the plague,
assign the click handler of the button to a method on the view that
dispatches the custom event.</p></div>Joel Hookstag:robotlegs.tenderapp.com,2009-10-18:Comment/6105902009-11-19T20:36:09Z2009-11-19T20:36:12ZHow to handle states<div><p>I have opted to create an mx:Model object in the view and when
the wizard is complete, I dispatch an event and pass that object
into the mediator so I can transfer all the values into the
application model.</p></div>terrytag:robotlegs.tenderapp.com,2009-10-18:Comment/6105902009-11-20T03:41:11Z2009-11-20T03:41:13ZHow to handle states<div><p>after many different attempts to wire my app in different ways,
I really think I am starting to pick up how robot legs is supposed
to work. I am just struggling with when to use the framework and
when to just write some code. For instance, I need to control the
flow of my view states, do I make a model and commands to to do
this? or do I control the flow of my states using local code in the
view? Which case makes you guys cringe the most? Should I think of
everything my app does as a command?</p></div>Terrytag:robotlegs.tenderapp.com,2009-10-18:Comment/6105902009-11-20T03:53:28Z2009-11-20T03:53:28ZHow to handle states<div><p>A complex component that utilizes view states can manage those
states internally. This sort of business really isn't the
responsibility of the framework. Commands do not define everything
the application does, they define interaction between the layers,
or tiers, of your application. A user clicks a button, that updates
some data. This triggers an event that executes a command that
delivers that data to a Model class.</p>
<p>Does that help at all?</p></div>Joel Hookstag:robotlegs.tenderapp.com,2009-10-18:Comment/6105902009-11-20T04:02:14Z2009-11-20T04:02:17ZHow to handle states<div><p>Yes, I will now print that paragraph and tape it on my monitor
for rest of this application build :)</p></div>Terrytag:robotlegs.tenderapp.com,2009-10-18:Comment/6105902009-11-20T16:43:05Z2009-11-20T16:43:05ZHow to handle states<div><p>Haha :) Just to re-iterate:</p>
<p>Generally speaking, view components should manage their own
state as<br>
much as possible - and that state should have very little to do
with<br>
the "application" state. Model classes manage application state,
and<br>
Mediators translate changes in that state into calls that view<br>
components can understand. The view components should pretty much
be<br>
oblivious to the application they happen to find themselves in.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/6105902009-11-20T20:23:43Z2009-11-20T20:23:43ZHow to handle states<div><p>There is a distinct separation between the visual state of an
application and the state of the underlying data. Of course, the
state of the data affects the visual representation of the
components, but in terms of the visual user experience (states,
transitions, and other goodies Flex provides us) they are managed
by the component in response to the state of the data. Flex, as a
framework in and of itself, provides a robust toolkit for managing
state inside view components, and this should definitely be
leveraged in our Flex applications.</p></div>Joel Hookstag:robotlegs.tenderapp.com,2009-10-18:Comment/6105902009-11-23T05:01:11Z2009-11-23T05:01:11ZHow to handle states<div><p>After taking a break from it and coming back to my project I
immediately facepalmed and instantly went to work fixing
everything. I did get hung up for about an hour because I forgot to
override clone() for one of my events. Once I decided that the view
is the view and it should handle view things, everything started to
come together for me.<br></p></div>Terrytag:robotlegs.tenderapp.com,2009-10-18:Comment/6105902009-11-23T18:05:15Z2009-11-23T18:05:15ZHow to handle states<div><p>Excellent!</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/6105902009-11-24T13:09:12Z2010-10-23T09:55:00ZHow to handle states<div><p>Just curious Joel, why do you avoid bubbling? Because it's very hard to find the originator of the event, ... or?<br />
I'm indecisive on whether or not to use event bubbling. When using pureMVC I used event bubbling to listen to custom 'VIEW_CREATED' events in my main mxml file, which just passed this on to it's mediator to let it create the corresponding mediators ( a very crude form of mediator mapping i guess) This was a huge timesaver because it was completely independent of the view hierarchy.<br />
But since I'm not using pureMVC anymore I'm doubting whether it's ok to use event bubbling...</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/6105902009-11-24T14:22:51Z2009-11-24T14:22:51ZHow to handle states<div><p>Ya, I've been bit by the "wtf is the originator" and I am a bit
of a control freak. I want to be as explicit as possible in my
code. Having events race up and down the display list looking for
listeners disturbs me. The bubbling you describe is actually the
exact mechanism that the MediatorMap uses for automatic mediation
(automatic mediation disturbs me a bit too ;) ).</p></div>Joel Hookstag:robotlegs.tenderapp.com,2009-10-18:Comment/6105902009-11-24T16:11:54Z2010-10-23T09:55:00ZHow to handle states<div><p>Sound like you're just easily disturbed ;)<br />
No, I understand what you mean, there's something 'surely this'll go wrong' about it, however so far I haven't encountered any problems yet.</p>
<p>Funnily I get the same shivers whenever I start debugging other people's cairngorm & pureMVC projects when it concerns events/notifications. Where is this coming from? Obviously if they strictly adhere to best practices you <em>should</em> be able to find out pretty easily where a notification originates from, but still...<br />
Decoupling means freedom which in turn means less control in some areas...</p></div>creynders