NOTE: I forgot to say that in the EventManager in the component framework
can do it;

https://github.com/Gamua/Starling-Framework/blob/master/starling/src/starling/events/EventDispatcher.as

See the method invokeEvent(), line 140. In a way, this makes the need for a
subclassed Event obsolete, the data IS the payload which can be a primitive
value or vo/struct class.

The client knows what it needs.

Mike

On Tue, May 19, 2015 at 6:17 AM, Michael Schmalle <teotigraphix...@gmail.com
> wrote:

> Alex, consider the following, I use this all the time for composite
> components that have /mediators/controllers listening to them;
>
> public class GridGroup extends FeathersControl
> {
>     public static const EVENT_SELECTED_INDEX_CHANGE:String =
> "selectedIndexChange";
>
>     private var _selectedIndex:int = -1;
>
>     public function get selectedIndex():int
>     {
>         return _selectedIndex;
>     }
>
>     public function set selectedIndex(value:int):void
>     {
>         if (_selectedIndex == value)
>             return;
>         _selectedIndex = value;
>         dispatchEventWith(EVENT_SELECTED_INDEX_CHANGE, true,
> _selectedIndex);
>     }
> }
>
> A Starling robot legs Mediator example;
>
> public class MasterScreenMediator extends CausticImportMediator
> {
>     private var view:MasterScreen;
>
>     public function MasterScreenMediator()
>     {
>     }
>
>     override public function preRegister():void
>     {
>         super.preRegister();
>
>         addViewListener(GridGroup.EVENT_SELECTED_INDEX_CHANGE,
> view_selectedIndexChangeHandler);
>     }
>
>     override public function setViewComponent(viewComponent:Object):void
>     {
>         super.setViewComponent(viewComponent);
>         view = MasterScreen(viewComponent);
>     }
>
>     override public function preRemove():void
>     {
>         super.preRemove();
>     }
>
>     private function view_selectedIndexChangeHandler(event:Event,
> selectedIndex:int):void
>     {
>         trace("Selected index " + selectedIndex);
>     }
> }
>
> It's so clean, the point is having that extra mechanism of the 'data'
> property working within the EventManger when it calls event handlers.
>
> Mike
>
>
>
> On Tue, May 19, 2015 at 5:56 AM, Michael Schmalle <
> teotigraphix...@gmail.com> wrote:
>
>> Eh yeah, excuse my ignorance about the gcc.
>>
>> Anyway the pool in Starling is for the Event class not getting
>> instantiated all the time(EventManager).
>>
>> I keep forgetting to extend my scope to javascript impl.
>>
>> I'll be honest, I have spent the last week studying the code and stuff,
>> the javascript part still hasn't fully clicked in my head. I completely
>> understand the FlexJS composition framework now and how to make components
>> BUT, where and how the javascript line is, is still bugging the crap out of
>> my head(imagine fog).
>>
>> Maybe that wiki page on how you deal with layout that you said you were
>> going to write might help me "get it". Let me know when you have that up.
>>
>> Mike
>>
>>
>> On Mon, May 18, 2015 at 7:23 PM, Alex Harui <aha...@adobe.com> wrote:
>>
>>>
>>>
>>> On 5/18/15, 3:24 PM, "Michael Schmalle" <teotigraphix...@gmail.com>
>>> wrote:
>>> >I love the way Feathers and Starling do events, they use an Event pool
>>> for
>>> >one and have the data field on Event.
>>> >
>>> >So in my apps, you usually just had a class called MyEventType which has
>>> >the constants tagged onto it. The;
>>> >
>>> >dispatchWithEvent(MyEventType.FOO_EVENT, true, myDataObject);
>>> >
>>> >Where the second parameter is bubbles.
>>> >
>>> >This works great, they even added functionality where the callback could
>>> >receive the data in the second argument.
>>> >
>>> >What do you think about Event object pooling?
>>>
>>> I haven’t looked into it, but I didn’t get from your explanation what the
>>> “pool” is.  On the JS side the component set we are writing is leveraging
>>> Google Closure Library’s events and I would imagine that anyone’s JS code
>>> is going to leverage the browser’s native events, so IMO, anything we do
>>> on the AS side should mirror that.
>>>
>>> On the other hand, lots of events in Flex don’t really need the full DOM
>>> Event capability so I am open to having two event systems if folks think
>>> they can handle it.
>>>
>>> -Alex
>>>
>>>
>>
>

Reply via email to