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