in my mvc setup, i use a set of public static constants for event types on the model object and dispatch(new Event(ModelObject.CUSTOM_EVENT_TYPE)); when the listening object receives it, it goes and retrieves the data from a public variable / accessor on the model.
There are plenty of reasons to use custom events but they're not necessary for every event situation even without using the Signals object a On 26 March 2010 09:54, Mark Burvill <m...@antifuzz.com> wrote: > Signals gets a big plus from me. Takes a lot of the donkey-work out of > setting up custom events. > > > On 24 Mar 2010, at 22:21, Taka Kojima wrote: > > > You bring up some valid points, however some of them are irrelevant for > this > > example, i.e. multiple listeners. > > > > I could be a minority, but I don't think I am when I say that I have > never > > used multiple listeners for when I load in an XML file. > > > > Secondly, if I were to implement events for this XMLLoader class, I would > > most likely write a custom event class, which is even more work and I > don't > > feel like it is necessary. > > > > The reason I say I'd write a custom event class is, let's say I wanted to > > implement caching into my XMLLoader class, I can't use the Event.COMPLETE > > event anymore as the second time I make the request it won't even call a > > URLLoader, as it's reading from an array/dictionary/vector stored in the > > class to grab the content. > > > > I totally agree with you on the familiarity/consistency point, it makes > > working with others a lot easier. > > > > The other option is as3-signals, which I'm looking into and looks rather > > promising. > > > > > > On Wed, Mar 24, 2010 at 1:02 PM, Mark Winterhalder <mar...@gmail.com> > wrote: > > > >> On Wed, Mar 24, 2010 at 7:03 PM, Taka Kojima <t...@gigafied.com> wrote: > >>> I'm curious as to other people's thoughts on > >>> this in terms of good/bad practice and what the pros/cons to this > >> approach > >>> might be. > >> > >> My thoughts are that it's OK for the very common cases which don't > >> need the flexibility of events. > >> > >> Advantages of events: > >> > >> * multiple listeners > >> * one listener for multiple targets/types > >> * progress events etc. > >> * you'll have events all over your project anyway, period. > >> * it's what other coders are familiar with > >> > >> The last one's important if other devs /might/ have to work with your > >> code. For this it will only take me a minute to look up "that strange > >> loader class I don't know", but if you use too many of those it adds > >> up, and at some point I won't want to play with you no more. > >> > >> Personally, I'll stick with events, and I don't mind them at all. > >> _______________________________________________ > >> Flashcoders mailing list > >> Flashcoders@chattyfig.figleaf.com > >> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > >> > > _______________________________________________ > > Flashcoders mailing list > > Flashcoders@chattyfig.figleaf.com > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > _______________________________________________ > Flashcoders mailing list > Flashcoders@chattyfig.figleaf.com > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
