incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michel Boudreau <michelboudr...@gmail.com>
Subject Re: Flex - lightweight event handling
Date Mon, 16 Jan 2012 23:02:08 GMT
Frankly, I would prefer not even think about a new event mechanism right
now before fixing all other bugs and having all Spark components.  Plus,
the simple fact that people won't be able to upgrade easily is a huge
problem that isn't being mentioned here.  I say that we stay the course for
now until the codebase is stable, then we can start to address these issues.

M

On Mon, Jan 16, 2012 at 5:48 PM, Rick Winscot <rick.winscot@gmail.com>wrote:

> Response inline...
>
>
> On Monday, January 16, 2012 at 5:19 PM, Michel Boudreau wrote:
>
> > I don't really see the reason to have Signals added to Flex, especially
> if
> > it's already possible to just add it as a separate library. We can't
> >
> >
>
> Performance is a _very_ good reason. Adopting it into the framework means
> better maintenance, visibility, and interoperability.
> > change the fact that Events are use for the UI and we'd want that because
> > of the bubbling/capturing. Last I checked, this cannot be achieved with
> >
> >
>
> NativeSignal ( yes it can be done - it's optional )
> > Signals. I understand that signals is faster for application messaging,
> > but Parsley solved this problem easily by simply using a custom
> dispatcher
> > which does class type checking instead of even string checking. In the
> > end, the "events" being used are simple final classes (called messaging
> > classes) that don't extend Event. I prefer this approach because of the
> >
> >
>
> Class type-checking === coupling. This can drastically reduce your miles
> per gallon in app development and can pigeon-hole you into heavy
> dependency. If you're working with modules, creating plug-ins, etc. you're
> going to want to ditch that school of thought pretty quick.
> > fact that you can have inheriting messaging which works very well with
> the
> > message handlers.
> >
> Heavy hierarchies is part of the problem...
>
> >
> > M
> >
> > On Mon, Jan 16, 2012 at 4:57 PM, Aladin Scott <aladin@centrepede.com(mailto:
> aladin@centrepede.com)> wrote:
> >
> > > I second that, AS3 Signals is awesome. I haven't used native events to
> > > communicate outside of a parent class since using Signals.
> > >
> > > Aladin Scott
> > >
> > > On Mon, Jan 16, 2012 at 9:39 PM, Rick Winscot <rick.winscot@gmail.com(mailto:
> rick.winscot@gmail.com)
> > > > wrote:
> > >
> > >
> > > > With regard to Signals vs. Events... Rob provides a bridge called a
> > > > "NativeSignal." To Quote from his blog ---
> > > >
> > > >
> > > > Why not use EventDispatcher for the actual dispatching but wrap it
> in a
> > > > Signal facade?
> > > >
> > > > Presenting the NativeSignal class, which lets you have your cake and
> eat
> > > > it too. Take any EventDispatcher, e.g. Sprite. Create a NativeSignal
> that
> > > > targets an event of the dispatcher:
> > > >
> > > > // in a subclass:
> > > > click = new NativeSignal(this, 'click', MouseEvent);
> > > > // or decorating an instance:
> > > > click = new NativeSignal(theDispatcher, 'click', MouseEvent);
> > > >
> > > > Enjoy the Signal APIs and features.
> > > >
> > > > Dispatch from the NativeSignal or the EventDispatcher. Both use
> Flash's
> > > > native dispatchEvent(). If you're hesitant to put your trust in new
> > > > dispatching code, or you want to keep your EventDispatcher options
> open,
> > > > this is the gateway drug for you. You don't have to give up
> anything. All
> > > > the native functionality stays, and the ISignal interface can be
> piped in
> > > > like frosting, wherever you like. Doesn't that sound delicious?
> > > >
> > > >
> > > > What of Signal performance?
> > > >
> > > > http://alecmce.com/as3/events-and-signals-performance-tests
> > > >
> > > > The above charts are a little old - Rob has made a few commits since
> that
> > > > have added another 30 - 40% improvement.
> > > >
> > > > The primary takeaway is that Flash Events for UI interaction are ok
> ( a
> > > > necessary evil? ) but are a very poor choice for inter-application
> > > > communication. Efficiency in communication becomes more and more
> > > >
> > >
> > > important
> > > > as the size of the application increases.
> > > >
> > > > --
> > > > Rick Winscot
> > > >
> > > >
> > > > On Monday, January 16, 2012 at 4:17 PM, Omar Gonzalez wrote:
> > > >
> > > > > I'd definitely be interesting in exploring this idea. I had a lot
> of
> > > > > internal debating with myself over whether to use native Event
> objects
> > > > >
> > > >
> > > >
> > >
> > > or
> > > > > as3-signals when I wrote my MongoAS3 library. I ultimately chose
> > > >
> > >
> > > signals
> > > > > because I enjoy their ease of use and payload type-checking runtime
> > > >
> > > > errors.
> > > > >
> > > > > -omar
> >
> >
> >
> > --
> > Michel Boudreau
> >
> > "If at first you don't succeed, use a bigger hammer." - Unofficial motto
> of
> > the Royal Electrical and Mechanical Engineers
> >
> >
>
>
>


-- 
Michel Boudreau

"If at first you don't succeed, use a bigger hammer." - Unofficial motto of
the Royal Electrical and Mechanical Engineers

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message