Futurescale, Inc.
PureMVC Home
The PureMVC Framework
Code at the Speed of Thought
Over 10 years of community discussion and knowledge are maintained here as a read-only archive.
New discussions should be taken up in issues on the appropriate projects at
https://github.com/PureMVC
PureMVC Architects Lounge
Announcements and General Discussion
General Discussion
handling mx:state view creation and view re-activation in mvc
Pages: [
1
]
« previous
next »
Author
Topic: handling mx:state view creation and view re-activation in mvc (Read 11548 times)
arisco97
Jr. Member
Posts: 14
handling mx:state view creation and view re-activation in mvc
«
on:
December 28, 2008, 05:20:44 »
Although I can have work arounds, I am looking to understand how someone has tackled the re-activation of a state that involes addChild.
The addChild component fires a creationComplete event to get its mediator registered. However I am looking for a clean way of informing the mediator of the reactivation of this child. The creationComplete won't play a role in the reactivation of this child.
Thanks.
Logged
arisco97
Jr. Member
Posts: 14
Re: handling mx:state view creation and view re-activation in mvc
«
Reply #1 on:
December 28, 2008, 11:08:44 »
just to add code context ... a sample below:
//parent code ...
// state s1 adds component c1.
// c1 fires a creationComplete to the parent, which in turn fires
// EVENT_C1_CREATED to inform the mediator
//
// watch I had to keep a boolean flag as state to track the creation.
<mx:states>
<mx:State name="s1">
<mx:AddChild>
<mx:target>
<components:C1 id="c1"
onc1CreatedEvent="_bc1Created = true;
dispatchEvent(new Event(EVENT_C1_CREATED));"/>
//base state
//As the user may reactivate S1 after initial creation, the mediator needs to know again.
// the boolean flag is checked to re fire the creation event to allow the mediator to do whatever....
<components:B1 id="b1"
c1SelectedEvent="currentState='customScanInputState';
(_bc1Created)?dispatchEvent(new Event(EVENT_C1_CREATED)):''"
This is a mess. I hope someone can provide me guidance.
Thank you.
«
Last Edit: December 28, 2008, 11:10:53 by arisco97
»
Logged
puremvc
Global Moderator
Hero Member
Posts: 2871
Re: handling mx:state view creation and view re-activation in mvc
«
Reply #2 on:
December 29, 2008, 06:38:21 »
One mediator needs to hande the component (or application) that has the state changes).
When the children are added or removed from that component, the mediatorshould respond to the added and events by creating and registering the approprriate mediator passing the reference to the added component from the event.
The mediator for the newly added component should listen for the removed event for its child and respond by nulling its viewComponent property and removing itself with facad.removeMediator.
-=Cliff>
Logged
arisco97
Jr. Member
Posts: 14
Re: handling mx:state view creation and view re-activation in mvc
«
Reply #3 on:
December 29, 2008, 08:13:07 »
Cliff, thanks. Just one clarification - as I did not get info on Adobe.
Does the state event 'enter_state' get fired only after all the addChild views are available? I was wondering if I have to listen to events that get originated from the creationComplete of the newly added component the first time, or I can simply use the enter_state and exit_state to co-ordinate per your input.
Logged
puremvc
Global Moderator
Hero Member
Posts: 2871
Re: handling mx:state view creation and view re-activation in mvc
«
Reply #4 on:
December 29, 2008, 05:30:29 »
I would not have a mediator act on the flex state change events as a way of doing this. The reason for that is that you heap a bunch of responsibility on the mediator for understanding the internals of the view component or application undergoing the state transition.
For instance, if the application adds 3 mediated children and removes 2 on a given transition from state x to state y, the mediator (or a triggered command) must know which mediators to remove and which to add. And that goes for every state to every other state.
On the other hand if you follow the approach I outlined, then it is a simple problem of mapping a component class to the proper mediator. And for removal the view component removed during a flex state change notifies its own mediator to remove itself, QED. (Otherwise you'd also need to track which mediators to remove on a state change, retrieve them, and tell them to null their reference to the view component and remove the mediator.)
-=Cliff>
Logged
Pages: [
1
]
« previous
next »
Stack Overflow
GitHub
Linked In
Google Plus
Twitter
Powered by SMF 2.0.15
|
SMF © 2006-2007, Simple Machines LLC
|
Content © 2006-2018, Futurescale, Inc.
Loading...