Home → Robotlegs 1 →

Is this an ok approach (how I'm notifying another view when Tree is changed) - plus general dispatch question

Admin Functions

• Remove

rickcr

14 Feb, 2010 07:11 PM

Pardon if this is very basic (pretty new to Flex/AS/RIA development - experienced in the web java world.)...

I have a Tree on a Panel and when any part of the Tree changes (click event, whatever) a different view needs to be notified. I'm currently handling it like this:

//TreePanel view mxml <mx:Tree id="myTreeNav" ....

 change="dispatchEvent(new PromptTreeEvent(PromptTreeEvent.TREE_CHANGED, Tree(event.target).selectedItem as XML))"

//in TreePanel mediator: //on register eventMap.mapListener(treePanel, PromptTreeEvent.TREE_CHANGED, onPromptTreeChange);
//handler private function onPromptTreeChange(event:PromptTreeEvent):void {

dispatch(new PromptTreeEvent(PromptTreeEvent.TREE_CHANGED, event.xmlNode));

}

Couple questions...

1) Is the above approach ok? It seems sort of odd to just have my mediator acting as a proxy in a sense to just turn around and dispatch the same event? By default it doesn't look like it's easy to dispatch a Framework event directly from the view (although from another forum post here I heard it's possible if you really wanted.)

2) is there a reason why I can't turn around and dispatch the same event in my handler instead of having to make an identical new instance of the Event? I thought i'd just be able to do the following (but it didn't work):
//in mediator handler private function onPromptTreeChange(event:PromptTreeEvent):void {

dispatch(event);

}

1. Support Staff 2 Posted by Shaun Smith on 14 Feb, 2010 07:42 PM

   

   In order to re-dispatch an event in AS3 you have to override the Event's clone() method. Once you've done that, you can easily re-dispatch in your Mediator like so:

   eventMap.mapListener( treePanel, PromptTreeEvent.TREE_CHANGED, dispatch );
   

   Admin Functions

   • Remove

2. 3 Posted by squeedee on 15 Feb, 2010 09:09 PM

   

   I'll reitterate what I mentioned in IRC for the benefit of all.

   My style preference here is not to hand view-component events around on the bus, but in fact to 'decode' the intent.

   Assume: We have MyTreeView and MyTreeMediator

   If clicking the tree 'Selects a group' or 'Selects an item' or 'Begins an edit' within the system, I would do the following:

   • In MyTreeMediator, listen to MyTreeView for some component event (view.tree.addEventListener(MouseEvent.Click) etc)
   • When I handle the component event, dispatch a sensible event: ItemEvent.SELECT_ITEM or GroupEvent.SELECT_GROUP or ItemEvent.EDIT
   • Map those more meaningful events to commands.
   • Make those commands update model, such as ItemSelectionModel.edit(event.item).
   • Have models emit useful events: ItemSelectionEvent.EDITING or ItemSelectionEvent.SELECTED
   • Listen for those events in other viewMediators.

   I know this sounds verbose, but you're way ahead of the game if you follow this approach. You are now modelling IN your domain model, not your views.

   Admin Functions

   • Split
   • Remove

3. 4 Posted by squeedee on 15 Feb, 2010 11:05 PM

   

   Rick, In IRC you asked:

   [10:46] <+rickcr> so ican call dispatch A dispathc B dispatch C
   [10:47] <+rickcr> but the event handlers can all spin separate in tiem can't they?
   [10:48] <+rickcr> for example each could start a loop and they'd all be running
   [10:51] <+rickcr> so each could be acting on your singleton model in those loops.
   [10:51] <+rickcr> just need to be conscious not a big deal.
   

   Please be aware that this is not how actionscript works. the following code:

   dispatch(new EventA(EventA.THING));
   dispatch(new EventB(EventB.THING));
   dispatch(new EventC(EventC.THING));
   

   Is completely synchronous. All Handlers of EventA.THING will be run, synchronously, before any handler for EventB. There is no threading here.

   Event's are an easy way to handle asynchronous actions. They are not themselves asynchronous.

   Admin Functions

   • Split
   • Remove

4. Till Schneidereit closed this discussion on 02 Mar, 2010 12:46 PM.

Comments are currently closed for this discussion. You can start a new one.