have fun On 26 March 2010 13:39, Cor <c...@chello.nl> wrote:
> Thank you!! > I will start playing with this. > > Regards > Cor > > -----Original Message----- > From: flashcoders-boun...@chattyfig.figleaf.com > [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of allandt > bik-elliott (thefieldcomic.com) > Sent: vrijdag 26 maart 2010 13:30 > To: Flash Coders List > Subject: Re: [Flashcoders] Events can be tedious, general thoughts on best > practice? > > example model > > package > { > import flash.events.EventDispatcher; > > public class SiteModel extends EventDispatcher > > { > > public static const PAGE_CHANGE : String = "pageChange"; > public static const LOAD_UPDATE : String = "loadUpdate"; > > public var sPageName : String; > public var nLoadPercent : Number; > > public function SiteModel() > {} > > public function sendPageChange():void > { > dispatchEvent(new Event(SiteModel.PAGE_CHANGE)); > } > > public function sendLoadUpdate():void > { > dispatchEvent(new Event(SiteModel.LOAD_UPDATE)); > } > } > } > > set the data in one class: > private function changePage():void > { > model.sPageName = "newPageName"; > model.sendPageChange(); > } > > or to update load percentages: > Loader.contentLoaderInfo.addEventListener(ProgressEvent.PROGRESS, > handleProgress); > > private function handleProgress(e: ProgressEvent):void > { > model.nLoadPercent = Math.round(e.bytesLoaded / e.bytesTotal * 100); > model. sendLoadUpdate(); > } > > to get the data from another class: > > model.addEventListener(SiteModel.PAGE_CHANGE, handlePageChange); > model.addEventListener(SiteModel. LOAD_UPDATE, handleLoadUpdate); > > public function handlePageChange(e:Event):void > { > var newPageName:String = model.sPageName; > } > > public function handleLoadUpdate(e:Event):void > { > var loadedPercent:String = model. nLoadPercent; > } > > > > > On 26 March 2010 10:19, Cor <c...@chello.nl> wrote: > > > Could you describe a little working example how to do this? > > > > Regards > > Cor > > > > -----Original Message----- > > From: flashcoders-boun...@chattyfig.figleaf.com > > [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of allandt > > bik-elliott (thefieldcomic.com) > > Sent: vrijdag 26 maart 2010 11:07 > > To: Flash Coders List > > Subject: Re: [Flashcoders] Events can be tedious, general thoughts on > best > > practice? > > > > 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 > > Geen virus gevonden in het binnenkomende-bericht. > > Gecontroleerd door AVG - www.avg.com > > Versie: 9.0.791 / Virusdatabase: 271.1.1/2770 - datum van uitgifte: > > 03/25/10 > > 21:50:00 > > > > _______________________________________________ > > Flashcoders mailing list > > Flashcoders@chattyfig.figleaf.com > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > > On 26 March 2010 10:19, Cor <c...@chello.nl> wrote: > > > Could you describe a little working example how to do this? > > > > Regards > > Cor > > > > -----Original Message----- > > From: flashcoders-boun...@chattyfig.figleaf.com > > [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of allandt > > bik-elliott (thefieldcomic.com) > > Sent: vrijdag 26 maart 2010 11:07 > > To: Flash Coders List > > Subject: Re: [Flashcoders] Events can be tedious, general thoughts on > best > > practice? > > > > 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 > > Geen virus gevonden in het binnenkomende-bericht. > > Gecontroleerd door AVG - www.avg.com > > Versie: 9.0.791 / Virusdatabase: 271.1.1/2770 - datum van uitgifte: > > 03/25/10 > > 21:50:00 > > > > _______________________________________________ > > 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 > Geen virus gevonden in het binnenkomende-bericht. > Gecontroleerd door AVG - www.avg.com > Versie: 9.0.791 / Virusdatabase: 271.1.1/2770 - datum van uitgifte: > 03/25/10 > 21:50:00 > > _______________________________________________ > 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
