RE: [Flashcoders] Events can be tedious, general thoughts on best practice?
Oops, maybe not quiet yet
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: zaterdag 27 maart 2010 19:08
To: 'Flash Coders List'
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
Hi Colin,
Thanks!
I am into AS 3.0 so I will try to "rebuild" it.
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of
co...@moock.org
Sent: zaterdag 27 maart 2010 19:01
To: Flash Coders List
Subject: Re: [Flashcoders] Events can be tedious, general thoughts on best
practice?
hey cor,
i'm guessing jason's example is modern ActionScript 3.0, but if you're
looking for a range of examples, here's one in ActionScript 2.0, showing
how to implement a clock using mvc:
http://www.moock.org/lectures/mvc/
other than little syntactic details, the only aspect of the code that is
obviously outdated is the "Observer" pattern implementation. in
ActionScript 3.0, you'd use events rather than "Observer" to send
updates from the model to the view(s), but the example is pretty much
still applicable otherwise. it might even make an interesting study
project to update it to ActionScript 3.0.
have fun!
colin
Cor wrote:
> Thanks Jason,
>
> I understand the theory, but have a problem creating a MVC myself.
> I don't want to use other frameworks, I want to learn to OOP in Flash and
> how to create an MVC from scratch.
> I am really looking for some simple, but completely working examples.
>
> Regards
> Cor
>
>
> -Original Message-
> From: flashcoders-boun...@chattyfig.figleaf.com
> [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
> Jason
> Sent: vrijdag 26 maart 2010 17:04
> To: Flash Coders List
> Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
> practice?
>
> In basic MVC, the controller listens to both the model and view for
events.
> Since Flash doesn't have data binding like Flex has, the model might
> dispatch an event when a value changes, and the controller would then tell
> the view how to change and might send a value to it. Also, the view might
> dispatch an event that the controller would be listening for, and the
> controller might then tell another view or the model (or both) to change.
> So the controller controls the view and the model, but the controller does
> not get controlled.
>
> In more advanced patterns and frameworks, you have things like commands
> (like in Cairngorm), façades, proxies etc. to also facilitate these
> communications.
>
>
> Jason Merrill
>
> Bank of America Global Learning
> Learning & Performance Solutions
>
> Join the Bank of America Flash Platform Community and visit our
> Instructional Technology Design Blog
> (note: these are for Bank of America employees only)
>
>
>
>
>
>
> -----Original Message-----
> From: flashcoders-boun...@chattyfig.figleaf.com
> [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
> Sent: Friday, March 26, 2010 11:41 AM
> To: 'Flash Coders List'
> Subject: RE: [Flashcoders] Events can be tedious,general thoughts on best
> practice?
>
> Thanks Jason,
> I am still investigating/trying to learn the MVC pattern and I noticed the
> same handling as far as the model aspect.
> So if you can elaborate on that too, it is highly appreciated.
>
> Kind regards,
>
> Cor
>
> -----Original Message-
> From: flashcoders-boun...@chattyfig.figleaf.com
> [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
> Jason
> Sent: vrijdag 26 maart 2010 16:10
> To: Flash Coders List
> Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
> practice?
>
> I missed the beginning of this thread somehow, but FWIW, FlashDevelop
> has an Add > New Event menu option in the project pane when you right
> click on a package folder which makes creating custom events a snap.
> All you really have to do is enter the static event constants you want
> the event to have and you're done. When you select this option, it
> auto-generates a file with this in it:
>
> package events
> {
> import flash.events.Event;
>
> /**
>* ...
>* @author Jason Merrill
>*/
> public class NewEvent extends Event
> {
>
> public function NewEvent(type:String,
> bubbles:Boolean=false, cancelable:Boolean=false)
> {
> super(type, bubbles, cancelable);
&
RE: [Flashcoders] Events can be tedious, general thoughts on best practice?
Hi Colin,
Thanks!
I am into AS 3.0 so I will try to "rebuild" it.
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of
co...@moock.org
Sent: zaterdag 27 maart 2010 19:01
To: Flash Coders List
Subject: Re: [Flashcoders] Events can be tedious, general thoughts on best
practice?
hey cor,
i'm guessing jason's example is modern ActionScript 3.0, but if you're
looking for a range of examples, here's one in ActionScript 2.0, showing
how to implement a clock using mvc:
http://www.moock.org/lectures/mvc/
other than little syntactic details, the only aspect of the code that is
obviously outdated is the "Observer" pattern implementation. in
ActionScript 3.0, you'd use events rather than "Observer" to send
updates from the model to the view(s), but the example is pretty much
still applicable otherwise. it might even make an interesting study
project to update it to ActionScript 3.0.
have fun!
colin
Cor wrote:
> Thanks Jason,
>
> I understand the theory, but have a problem creating a MVC myself.
> I don't want to use other frameworks, I want to learn to OOP in Flash and
> how to create an MVC from scratch.
> I am really looking for some simple, but completely working examples.
>
> Regards
> Cor
>
>
> -Original Message-
> From: flashcoders-boun...@chattyfig.figleaf.com
> [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
> Jason
> Sent: vrijdag 26 maart 2010 17:04
> To: Flash Coders List
> Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
> practice?
>
> In basic MVC, the controller listens to both the model and view for
events.
> Since Flash doesn't have data binding like Flex has, the model might
> dispatch an event when a value changes, and the controller would then tell
> the view how to change and might send a value to it. Also, the view might
> dispatch an event that the controller would be listening for, and the
> controller might then tell another view or the model (or both) to change.
> So the controller controls the view and the model, but the controller does
> not get controlled.
>
> In more advanced patterns and frameworks, you have things like commands
> (like in Cairngorm), façades, proxies etc. to also facilitate these
> communications.
>
>
> Jason Merrill
>
> Bank of America Global Learning
> Learning & Performance Solutions
>
> Join the Bank of America Flash Platform Community and visit our
> Instructional Technology Design Blog
> (note: these are for Bank of America employees only)
>
>
>
>
>
>
> -Original Message-----
> From: flashcoders-boun...@chattyfig.figleaf.com
> [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
> Sent: Friday, March 26, 2010 11:41 AM
> To: 'Flash Coders List'
> Subject: RE: [Flashcoders] Events can be tedious,general thoughts on best
> practice?
>
> Thanks Jason,
> I am still investigating/trying to learn the MVC pattern and I noticed the
> same handling as far as the model aspect.
> So if you can elaborate on that too, it is highly appreciated.
>
> Kind regards,
>
> Cor
>
> -----Original Message-
> From: flashcoders-boun...@chattyfig.figleaf.com
> [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
> Jason
> Sent: vrijdag 26 maart 2010 16:10
> To: Flash Coders List
> Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
> practice?
>
> I missed the beginning of this thread somehow, but FWIW, FlashDevelop
> has an Add > New Event menu option in the project pane when you right
> click on a package folder which makes creating custom events a snap.
> All you really have to do is enter the static event constants you want
> the event to have and you're done. When you select this option, it
> auto-generates a file with this in it:
>
> package events
> {
> import flash.events.Event;
>
> /**
>* ...
>* @author Jason Merrill
>*/
> public class NewEvent extends Event
> {
>
> public function NewEvent(type:String,
> bubbles:Boolean=false, cancelable:Boolean=false)
> {
> super(type, bubbles, cancelable);
>
> }
>
> public override function clone():Event
> {
> return new NewEvent(type, bubbles, cancelable);
> }
>
> public override function toString():String
>
Re: [Flashcoders] Events can be tedious, general thoughts on best practice?
hey cor,
i'm guessing jason's example is modern ActionScript 3.0, but if you're
looking for a range of examples, here's one in ActionScript 2.0, showing
how to implement a clock using mvc:
http://www.moock.org/lectures/mvc/
other than little syntactic details, the only aspect of the code that is
obviously outdated is the "Observer" pattern implementation. in
ActionScript 3.0, you'd use events rather than "Observer" to send
updates from the model to the view(s), but the example is pretty much
still applicable otherwise. it might even make an interesting study
project to update it to ActionScript 3.0.
have fun!
colin
Cor wrote:
Thanks Jason,
I understand the theory, but have a problem creating a MVC myself.
I don't want to use other frameworks, I want to learn to OOP in Flash and
how to create an MVC from scratch.
I am really looking for some simple, but completely working examples.
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 17:04
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
In basic MVC, the controller listens to both the model and view for events.
Since Flash doesn't have data binding like Flex has, the model might
dispatch an event when a value changes, and the controller would then tell
the view how to change and might send a value to it. Also, the view might
dispatch an event that the controller would be listening for, and the
controller might then tell another view or the model (or both) to change.
So the controller controls the view and the model, but the controller does
not get controlled.
In more advanced patterns and frameworks, you have things like commands
(like in Cairngorm), façades, proxies etc. to also facilitate these
communications.
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Friday, March 26, 2010 11:41 AM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] Events can be tedious,general thoughts on best
practice?
Thanks Jason,
I am still investigating/trying to learn the MVC pattern and I noticed the
same handling as far as the model aspect.
So if you can elaborate on that too, it is highly appreciated.
Kind regards,
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 16:10
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
I missed the beginning of this thread somehow, but FWIW, FlashDevelop
has an Add > New Event menu option in the project pane when you right
click on a package folder which makes creating custom events a snap.
All you really have to do is enter the static event constants you want
the event to have and you're done. When you select this option, it
auto-generates a file with this in it:
package events
{
import flash.events.Event;
/**
* ...
* @author Jason Merrill
*/
public class NewEvent extends Event
{
public function NewEvent(type:String,
bubbles:Boolean=false, cancelable:Boolean=false)
{
super(type, bubbles, cancelable);
}
public override function clone():Event
{
return new NewEvent(type, bubbles, cancelable);
}
public override function toString():String
{
return formatToString("NewEvent", "type",
"bubbles", "cancelable", "eventPhase");
}
}
}
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
___
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
Flashcode
Re: [Flashcoders] Events can be tedious, general thoughts on best practice?
jason's been doing it for a lot longer than me but mine is basically the following: var model:Model = new Model(); var controller1:Controller = new Controller(model); var controller2:Controller = new Controller(model); var view1:View = new View(model, controller1); var view2:View = new View(model, controller1); var view3:View = new View(model, controller2); var view4:View = new View(model, controller2); every class will save the references passed into them as class properties. The views delegate their actions to their controllers which update the model which fires events to update the views. Common view types should use common controllers to avoid duplicating functionality code from one controller to the next. The more traditional mvc will use singleton models and controllers and the controllers will keep a list of registered views and update them (so the view will call some kind of register() method on the controller) or the views will simply listen to the controller to update themselves On 26 March 2010 16:25, Cor wrote: > WOW, thanks Jason. > You're the best! > This will keep me of the street for some time. :-) > > Thanks again, I appreciate this very much!!! > > Grateful regards > Cor > > -Original Message- > From: flashcoders-boun...@chattyfig.figleaf.com > [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill, > Jason > Sent: vrijdag 26 maart 2010 17:20 > To: Flash Coders List > Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best > practice? > > Hi Cor, > > I'm sending you a very basic MVC template I wrote offlist. You can start > building off that if you like. I can't send you any actual projects I am > working on obviously. > > > Jason Merrill > > Bank of America Global Learning > Learning & Performance Solutions > > Join the Bank of America Flash Platform Community and visit our > Instructional Technology Design Blog > (note: these are for Bank of America employees only) > > > > > > > -Original Message- > From: flashcoders-boun...@chattyfig.figleaf.com > [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor > Sent: Friday, March 26, 2010 12:11 PM > To: 'Flash Coders List' > Subject: RE: [Flashcoders] Events can be tedious,general thoughts on best > practice? > > Thanks Jason, > > I understand the theory, but have a problem creating a MVC myself. > I don't want to use other frameworks, I want to learn to OOP in Flash and > how to create an MVC from scratch. > I am really looking for some simple, but completely working examples. > > Regards > Cor > > > -Original Message- > From: flashcoders-boun...@chattyfig.figleaf.com > [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill, > Jason > Sent: vrijdag 26 maart 2010 17:04 > To: Flash Coders List > Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best > practice? > > In basic MVC, the controller listens to both the model and view for events. > Since Flash doesn't have data binding like Flex has, the model might > dispatch an event when a value changes, and the controller would then tell > the view how to change and might send a value to it. Also, the view might > dispatch an event that the controller would be listening for, and the > controller might then tell another view or the model (or both) to change. > So the controller controls the view and the model, but the controller does > not get controlled. > > In more advanced patterns and frameworks, you have things like commands > (like in Cairngorm), façades, proxies etc. to also facilitate these > communications. > > > Jason Merrill > > Bank of America Global Learning > Learning & Performance Solutions > > Join the Bank of America Flash Platform Community and visit our > Instructional Technology Design Blog > (note: these are for Bank of America employees only) > > > > > > > -Original Message- > From: flashcoders-boun...@chattyfig.figleaf.com > [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor > Sent: Friday, March 26, 2010 11:41 AM > To: 'Flash Coders List' > Subject: RE: [Flashcoders] Events can be tedious,general thoughts on best > practice? > > Thanks Jason, > I am still investigating/trying to learn the MVC pattern and I noticed the > same handling as far as the model aspect. > So if you can elaborate on that too, it is highly appreciated. > > Kind regards, > > Cor > > -Original Message- > From: flashcoders-boun...@chattyfig.figleaf.com > [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill, > Jason > Se
RE: [Flashcoders] Events can be tedious, general thoughts on best practice?
Sure - I didn't have time to fill it in with any examples, so it doesn't "do"
anything yet, but if I have time I could do that. So ask me off list if you
have questions on using it. Felt bad I said I would send you something a while
back and never had time to get around to it.
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our Instructional
Technology Design Blog
(note: these are for Bank of America employees only)
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Friday, March 26, 2010 12:26 PM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] Events can be tedious,general thoughts on best
practice?
WOW, thanks Jason.
You're the best!
This will keep me of the street for some time. :-)
Thanks again, I appreciate this very much!!!
Grateful regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 17:20
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
Hi Cor,
I'm sending you a very basic MVC template I wrote offlist. You can start
building off that if you like. I can't send you any actual projects I am
working on obviously.
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Friday, March 26, 2010 12:11 PM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] Events can be tedious,general thoughts on best
practice?
Thanks Jason,
I understand the theory, but have a problem creating a MVC myself.
I don't want to use other frameworks, I want to learn to OOP in Flash and
how to create an MVC from scratch.
I am really looking for some simple, but completely working examples.
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 17:04
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
In basic MVC, the controller listens to both the model and view for events.
Since Flash doesn't have data binding like Flex has, the model might
dispatch an event when a value changes, and the controller would then tell
the view how to change and might send a value to it. Also, the view might
dispatch an event that the controller would be listening for, and the
controller might then tell another view or the model (or both) to change.
So the controller controls the view and the model, but the controller does
not get controlled.
In more advanced patterns and frameworks, you have things like commands
(like in Cairngorm), façades, proxies etc. to also facilitate these
communications.
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Friday, March 26, 2010 11:41 AM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] Events can be tedious,general thoughts on best
practice?
Thanks Jason,
I am still investigating/trying to learn the MVC pattern and I noticed the
same handling as far as the model aspect.
So if you can elaborate on that too, it is highly appreciated.
Kind regards,
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 16:10
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
I missed the beginning of this thread somehow, but FWIW, FlashDevelop
has an Add > New Event menu option in the project pane when you right
click on a package folder which makes creating custom events a snap.
All you really have to do is enter the static event constants you want
the event to have and you're done. When you select this option, it
auto-generates a file with this in it:
package events
{
import flash.events.Event;
/**
* ...
* @author Jason Merrill
*/
public class NewEvent extends Event
RE: [Flashcoders] Events can be tedious, general thoughts on best practice?
WOW, thanks Jason.
You're the best!
This will keep me of the street for some time. :-)
Thanks again, I appreciate this very much!!!
Grateful regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 17:20
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
Hi Cor,
I'm sending you a very basic MVC template I wrote offlist. You can start
building off that if you like. I can't send you any actual projects I am
working on obviously.
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Friday, March 26, 2010 12:11 PM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] Events can be tedious,general thoughts on best
practice?
Thanks Jason,
I understand the theory, but have a problem creating a MVC myself.
I don't want to use other frameworks, I want to learn to OOP in Flash and
how to create an MVC from scratch.
I am really looking for some simple, but completely working examples.
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 17:04
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
In basic MVC, the controller listens to both the model and view for events.
Since Flash doesn't have data binding like Flex has, the model might
dispatch an event when a value changes, and the controller would then tell
the view how to change and might send a value to it. Also, the view might
dispatch an event that the controller would be listening for, and the
controller might then tell another view or the model (or both) to change.
So the controller controls the view and the model, but the controller does
not get controlled.
In more advanced patterns and frameworks, you have things like commands
(like in Cairngorm), façades, proxies etc. to also facilitate these
communications.
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Friday, March 26, 2010 11:41 AM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] Events can be tedious,general thoughts on best
practice?
Thanks Jason,
I am still investigating/trying to learn the MVC pattern and I noticed the
same handling as far as the model aspect.
So if you can elaborate on that too, it is highly appreciated.
Kind regards,
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 16:10
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
I missed the beginning of this thread somehow, but FWIW, FlashDevelop
has an Add > New Event menu option in the project pane when you right
click on a package folder which makes creating custom events a snap.
All you really have to do is enter the static event constants you want
the event to have and you're done. When you select this option, it
auto-generates a file with this in it:
package events
{
import flash.events.Event;
/**
* ...
* @author Jason Merrill
*/
public class NewEvent extends Event
{
public function NewEvent(type:String,
bubbles:Boolean=false, cancelable:Boolean=false)
{
super(type, bubbles, cancelable);
}
public override function clone():Event
{
return new NewEvent(type, bubbles, cancelable);
}
public override function toString():String
{
return formatToString("NewEvent", "type",
"bubbles", "cancelable", "eventPhase");
}
}
}
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platfor
RE: [Flashcoders] Events can be tedious, general thoughts on best practice?
Hi Cor,
I'm sending you a very basic MVC template I wrote offlist. You can start
building off that if you like. I can't send you any actual projects I am
working on obviously.
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our Instructional
Technology Design Blog
(note: these are for Bank of America employees only)
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Friday, March 26, 2010 12:11 PM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] Events can be tedious,general thoughts on best
practice?
Thanks Jason,
I understand the theory, but have a problem creating a MVC myself.
I don't want to use other frameworks, I want to learn to OOP in Flash and
how to create an MVC from scratch.
I am really looking for some simple, but completely working examples.
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 17:04
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
In basic MVC, the controller listens to both the model and view for events.
Since Flash doesn't have data binding like Flex has, the model might
dispatch an event when a value changes, and the controller would then tell
the view how to change and might send a value to it. Also, the view might
dispatch an event that the controller would be listening for, and the
controller might then tell another view or the model (or both) to change.
So the controller controls the view and the model, but the controller does
not get controlled.
In more advanced patterns and frameworks, you have things like commands
(like in Cairngorm), façades, proxies etc. to also facilitate these
communications.
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Friday, March 26, 2010 11:41 AM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] Events can be tedious,general thoughts on best
practice?
Thanks Jason,
I am still investigating/trying to learn the MVC pattern and I noticed the
same handling as far as the model aspect.
So if you can elaborate on that too, it is highly appreciated.
Kind regards,
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 16:10
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
I missed the beginning of this thread somehow, but FWIW, FlashDevelop
has an Add > New Event menu option in the project pane when you right
click on a package folder which makes creating custom events a snap.
All you really have to do is enter the static event constants you want
the event to have and you're done. When you select this option, it
auto-generates a file with this in it:
package events
{
import flash.events.Event;
/**
* ...
* @author Jason Merrill
*/
public class NewEvent extends Event
{
public function NewEvent(type:String,
bubbles:Boolean=false, cancelable:Boolean=false)
{
super(type, bubbles, cancelable);
}
public override function clone():Event
{
return new NewEvent(type, bubbles, cancelable);
}
public override function toString():String
{
return formatToString("NewEvent", "type",
"bubbles", "cancelable", "eventPhase");
}
}
}
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
___
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
_
Re: [Flashcoders] Events can be tedious, general thoughts on best practice?
www.lynda.com/home/DisplayCourse.aspx?lpk2=759
Chapter 4
Nathan Mynarcik
Interactive Web Developer
nat...@mynarcik.com
254.749.2525
www.mynarcik.com
-Original Message-
From: "Cor"
Date: Fri, 26 Mar 2010 17:10:34
To: 'Flash Coders List'
Subject: RE: [Flashcoders] Events can be tedious,
general thoughts on best practice?
Thanks Jason,
I understand the theory, but have a problem creating a MVC myself.
I don't want to use other frameworks, I want to learn to OOP in Flash and
how to create an MVC from scratch.
I am really looking for some simple, but completely working examples.
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 17:04
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
In basic MVC, the controller listens to both the model and view for events.
Since Flash doesn't have data binding like Flex has, the model might
dispatch an event when a value changes, and the controller would then tell
the view how to change and might send a value to it. Also, the view might
dispatch an event that the controller would be listening for, and the
controller might then tell another view or the model (or both) to change.
So the controller controls the view and the model, but the controller does
not get controlled.
In more advanced patterns and frameworks, you have things like commands
(like in Cairngorm), façades, proxies etc. to also facilitate these
communications.
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Friday, March 26, 2010 11:41 AM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] Events can be tedious,general thoughts on best
practice?
Thanks Jason,
I am still investigating/trying to learn the MVC pattern and I noticed the
same handling as far as the model aspect.
So if you can elaborate on that too, it is highly appreciated.
Kind regards,
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 16:10
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
I missed the beginning of this thread somehow, but FWIW, FlashDevelop
has an Add > New Event menu option in the project pane when you right
click on a package folder which makes creating custom events a snap.
All you really have to do is enter the static event constants you want
the event to have and you're done. When you select this option, it
auto-generates a file with this in it:
package events
{
import flash.events.Event;
/**
* ...
* @author Jason Merrill
*/
public class NewEvent extends Event
{
public function NewEvent(type:String,
bubbles:Boolean=false, cancelable:Boolean=false)
{
super(type, bubbles, cancelable);
}
public override function clone():Event
{
return new NewEvent(type, bubbles, cancelable);
}
public override function toString():String
{
return formatToString("NewEvent", "type",
"bubbles", "cancelable", "eventPhase");
}
}
}
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
___
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.
Gecon
RE: [Flashcoders] Events can be tedious, general thoughts on best practice?
Thanks Jason,
I understand the theory, but have a problem creating a MVC myself.
I don't want to use other frameworks, I want to learn to OOP in Flash and
how to create an MVC from scratch.
I am really looking for some simple, but completely working examples.
Regards
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 17:04
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
In basic MVC, the controller listens to both the model and view for events.
Since Flash doesn't have data binding like Flex has, the model might
dispatch an event when a value changes, and the controller would then tell
the view how to change and might send a value to it. Also, the view might
dispatch an event that the controller would be listening for, and the
controller might then tell another view or the model (or both) to change.
So the controller controls the view and the model, but the controller does
not get controlled.
In more advanced patterns and frameworks, you have things like commands
(like in Cairngorm), façades, proxies etc. to also facilitate these
communications.
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Friday, March 26, 2010 11:41 AM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] Events can be tedious,general thoughts on best
practice?
Thanks Jason,
I am still investigating/trying to learn the MVC pattern and I noticed the
same handling as far as the model aspect.
So if you can elaborate on that too, it is highly appreciated.
Kind regards,
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 16:10
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
I missed the beginning of this thread somehow, but FWIW, FlashDevelop
has an Add > New Event menu option in the project pane when you right
click on a package folder which makes creating custom events a snap.
All you really have to do is enter the static event constants you want
the event to have and you're done. When you select this option, it
auto-generates a file with this in it:
package events
{
import flash.events.Event;
/**
* ...
* @author Jason Merrill
*/
public class NewEvent extends Event
{
public function NewEvent(type:String,
bubbles:Boolean=false, cancelable:Boolean=false)
{
super(type, bubbles, cancelable);
}
public override function clone():Event
{
return new NewEvent(type, bubbles, cancelable);
}
public override function toString():String
{
return formatToString("NewEvent", "type",
"bubbles", "cancelable", "eventPhase");
}
}
}
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
___
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
RE: [Flashcoders] Events can be tedious, general thoughts on best practice?
In basic MVC, the controller listens to both the model and view for events.
Since Flash doesn't have data binding like Flex has, the model might dispatch
an event when a value changes, and the controller would then tell the view how
to change and might send a value to it. Also, the view might dispatch an event
that the controller would be listening for, and the controller might then tell
another view or the model (or both) to change. So the controller controls the
view and the model, but the controller does not get controlled.
In more advanced patterns and frameworks, you have things like commands (like
in Cairngorm), façades, proxies etc. to also facilitate these communications.
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our Instructional
Technology Design Blog
(note: these are for Bank of America employees only)
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Cor
Sent: Friday, March 26, 2010 11:41 AM
To: 'Flash Coders List'
Subject: RE: [Flashcoders] Events can be tedious,general thoughts on best
practice?
Thanks Jason,
I am still investigating/trying to learn the MVC pattern and I noticed the
same handling as far as the model aspect.
So if you can elaborate on that too, it is highly appreciated.
Kind regards,
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 16:10
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
I missed the beginning of this thread somehow, but FWIW, FlashDevelop
has an Add > New Event menu option in the project pane when you right
click on a package folder which makes creating custom events a snap.
All you really have to do is enter the static event constants you want
the event to have and you're done. When you select this option, it
auto-generates a file with this in it:
package events
{
import flash.events.Event;
/**
* ...
* @author Jason Merrill
*/
public class NewEvent extends Event
{
public function NewEvent(type:String,
bubbles:Boolean=false, cancelable:Boolean=false)
{
super(type, bubbles, cancelable);
}
public override function clone():Event
{
return new NewEvent(type, bubbles, cancelable);
}
public override function toString():String
{
return formatToString("NewEvent", "type",
"bubbles", "cancelable", "eventPhase");
}
}
}
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
___
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
Re: [Flashcoders] Events can be tedious, general thoughts on best practice?
flashdevelops templates are an awesome way to speed up coding, especially as
you can update them (i add headings for constants, properties, constructor,
methods, handlers and accessors / mutators into mine so that i can easily
find everything within a class
a
On 26 March 2010 15:40, Cor wrote:
> Thanks Jason,
> I am still investigating/trying to learn the MVC pattern and I noticed the
> same handling as far as the model aspect.
> So if you can elaborate on that too, it is highly appreciated.
>
> Kind regards,
>
> Cor
>
> -Original Message-
> From: flashcoders-boun...@chattyfig.figleaf.com
> [mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
> Jason
> Sent: vrijdag 26 maart 2010 16:10
> To: Flash Coders List
> Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
> practice?
>
> I missed the beginning of this thread somehow, but FWIW, FlashDevelop
> has an Add > New Event menu option in the project pane when you right
> click on a package folder which makes creating custom events a snap.
> All you really have to do is enter the static event constants you want
> the event to have and you're done. When you select this option, it
> auto-generates a file with this in it:
>
> package events
> {
>import flash.events.Event;
>
>/**
> * ...
> * @author Jason Merrill
> */
>public class NewEvent extends Event
>{
>
>public function NewEvent(type:String,
> bubbles:Boolean=false, cancelable:Boolean=false)
>{
>super(type, bubbles, cancelable);
>
>}
>
>public override function clone():Event
>{
>return new NewEvent(type, bubbles, cancelable);
>}
>
>public override function toString():String
>{
>return formatToString("NewEvent", "type",
> "bubbles", "cancelable", "eventPhase");
>}
>
>}
>
> }
>
>
> Jason Merrill
>
> Bank of America Global Learning
> Learning & Performance Solutions
>
> Join the Bank of America Flash Platform Community and visit our
> Instructional Technology Design Blog
> (note: these are for Bank of America employees only)
>
>
>
>
> ___
> 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
RE: [Flashcoders] Events can be tedious, general thoughts on best practice?
Thanks Jason,
I am still investigating/trying to learn the MVC pattern and I noticed the
same handling as far as the model aspect.
So if you can elaborate on that too, it is highly appreciated.
Kind regards,
Cor
-Original Message-
From: flashcoders-boun...@chattyfig.figleaf.com
[mailto:flashcoders-boun...@chattyfig.figleaf.com] On Behalf Of Merrill,
Jason
Sent: vrijdag 26 maart 2010 16:10
To: Flash Coders List
Subject: RE: [Flashcoders] Events can be tedious, general thoughts on best
practice?
I missed the beginning of this thread somehow, but FWIW, FlashDevelop
has an Add > New Event menu option in the project pane when you right
click on a package folder which makes creating custom events a snap.
All you really have to do is enter the static event constants you want
the event to have and you're done. When you select this option, it
auto-generates a file with this in it:
package events
{
import flash.events.Event;
/**
* ...
* @author Jason Merrill
*/
public class NewEvent extends Event
{
public function NewEvent(type:String,
bubbles:Boolean=false, cancelable:Boolean=false)
{
super(type, bubbles, cancelable);
}
public override function clone():Event
{
return new NewEvent(type, bubbles, cancelable);
}
public override function toString():String
{
return formatToString("NewEvent", "type",
"bubbles", "cancelable", "eventPhase");
}
}
}
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
___
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
RE: [Flashcoders] Events can be tedious, general thoughts on best practice?
I missed the beginning of this thread somehow, but FWIW, FlashDevelop
has an Add > New Event menu option in the project pane when you right
click on a package folder which makes creating custom events a snap.
All you really have to do is enter the static event constants you want
the event to have and you're done. When you select this option, it
auto-generates a file with this in it:
package events
{
import flash.events.Event;
/**
* ...
* @author Jason Merrill
*/
public class NewEvent extends Event
{
public function NewEvent(type:String,
bubbles:Boolean=false, cancelable:Boolean=false)
{
super(type, bubbles, cancelable);
}
public override function clone():Event
{
return new NewEvent(type, bubbles, cancelable);
}
public override function toString():String
{
return formatToString("NewEvent", "type",
"bubbles", "cancelable", "eventPhase");
}
}
}
Jason Merrill
Bank of America Global Learning
Learning & Performance Solutions
Join the Bank of America Flash Platform Community and visit our
Instructional Technology Design Blog
(note: these are for Bank of America employees only)
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] Events can be tedious, general thoughts on best practice?
have fun
On 26 March 2010 13:39, Cor 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 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 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
> > > > wo
RE: [Flashcoders] Events can be tedious, general thoughts on best practice?
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 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 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
> > wrote:
> > >
> > >> On Wed, Mar 24, 2010 at 7:03 PM, Taka Kojima
> 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 flexi
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 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 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
> > wrote:
> > >
> > >> On Wed, Mar 24, 2010 at 7:03 PM, Taka Kojima
> 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 c
RE: [Flashcoders] Events can be tedious, general thoughts on best practice?
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 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 > wrote: > > > >> On Wed, Mar 24, 2010 at 7:03 PM, Taka Kojima 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
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 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 > wrote: > > > >> On Wed, Mar 24, 2010 at 7:03 PM, Taka Kojima 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
Re: [Flashcoders] Events can be tedious, general thoughts on best practice?
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 wrote: > >> On Wed, Mar 24, 2010 at 7:03 PM, Taka Kojima 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
Re: [Flashcoders] Events can be tedious, general thoughts on best practice?
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 wrote: > On Wed, Mar 24, 2010 at 7:03 PM, Taka Kojima 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
Re: [Flashcoders] Events can be tedious, general thoughts on best practice?
On Wed, Mar 24, 2010 at 7:03 PM, Taka Kojima 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
