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
