Re: [Flashcoders] MVC style Correction

[Ross Sclafani]

thanks, its just how i do MVC

it really get interesting when you follow a mitosis development pattern... You 
start with one model, controller, and view, add features to each in parallel, 
and as each class gets too big, you break them out into subcontrollers, 
submodels, and subviews. Then sub-sub. My projects have a triple-tree structure 
branching out from the core model, controller, and view classes

finer granularity as you reach further in, and always broken into M, V, and C:

Models contain properties only. they dispatch a CHANGE Event every time one of 
their properties change,.

Views display properties of the model. they listen for the CHANGE Event, and 
update their appearance with the new values stored in the model every time it 
changes.

Controllers manipulate properties of the model. Whether trigger by event 
handlers in the views, or internal timers or network activity, any command that 
sets any value of any property of the model is placed in a controller. 
Controllers might use other controllers to trigger changes in submodels outside 
its subdomain

the project starts off very compact, then grows with its functionality as 
required, always growing out from the center so you never paint yourself into a 
corner

then later to optimize, you can get specific about which submodel a particular 
view is listening to, in turn limiting the number of change events it receives 
to those actually represented in the view.

all subcontrollers hold a reference to the root controller, so it is easy to 
target any node on the controller tree from anywhere inside of it.

same with the model tree. some submodel properties can emit the CHANGE Event 
only on a local level, and not send the event up the hierarchy, isolating the 
scope of view updates

An MVC Example

FLVPlayback is an interesting MVC  component:

it holds a NetStream as a model of the video

it holds a Video as a view of the Video

It acts as controller to set the model in motion by connecting it to a stream

the ui is also a view of the video: the percent elapsed is represented n the 
scrub bar, ther is a play button while paused, a pause button while playing, 
then there are the time readouts..

if the video its playing, 
the user clicks pause in the view, 
it tells the controller to pause the stream in the model, 
which notifies the views, so the Video is paused, and  pause button becomes a 
play button.

thats how i do MVC. 
data is stored in mvc.models, 
data is displayed in mvc.views, and 
data is manipulated in mvc.controllers.


Ross P. Sclafani
design / technology / creative

http://ross.sclafani.net
http://www.twitter.com/rosssclafani
http://www.linkedin.com/in/rosssclafani
[347] 204.5714

On Feb 26, 2012, at 11:09 PM, Karl DeSaulniers wrote:

> BTW Ross, I thought your example was great.
> 
> Karl DeSaulniers
> Design Drumm
> http://designdrumm.com
> 
> ___
> 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] MVC style Correction

[Karl DeSaulniers]

BTW Ross, I thought your example was great.

On Feb 26, 2012, at 9:51 PM, Karl DeSaulniers wrote:

I have not created any MVC (I don't think) per se, so I am no  
authoritarian by any means.
It just seems that when coding a paradigm, you want to keep it  
simple as possible so as to not confuse yourself or the paradigm.
I would tend to agree that a controller should do just that...  
control.
a view should be used to display and to send updates back to the  
controller depending on the user interaction.
the model just sits there and gives and takes data, formating it for  
the view maybe or sending back errors for the controller.
I think that if your model is as simple and streamlined as possible,  
it makes the job of the controller and view much easier.

the controller is definitely the hardest worker of the three.

I think also, that if you make your model aware of the others, it  
tends to start memory leaks.

a plague of most smart phone apps and flash websites today.

Kind of like a production artist trying to do art direction without  
telling the art director. Gets kinda messy.

It can be done, but you may end up refunding the client.

Open for thoughts..

Best,
Karl


On Feb 26, 2012, at 8:36 PM, Paul Andrews wrote:


On 27/02/2012 01:45, Karl DeSaulniers wrote:
So is the basic construct to choose between a controller or  
multiple adaptors?

It seems (to me) that a combination of the two is overkill.
If you cant fit everything your trying to do within a MVC or MVA  
style pattern, your coding it wrong.

Not setting flame, just inquiring. :)

Karl


I'm with you Karl.

I see models as a repository of data, modified by controllers, read  
by views.


It's not necessary for controllers to have intimate knowledge of  
models, all that is required is that there is some kind of  
interface/contract by which a controller can read and modify the  
data therein. I don't see the automatic need for any adaptor.


It may be that one model has a different interface/contract to  
another, so a controller designed for one model could use an  
adaptor as an intermediary to another, but that is not what I  
understand as the core concept of MVC.


Views updating models? No, not at all - they are simply reflections  
of the data model to the user, not something that modifies it. They  
only know about the data they show to the user, they don't modify  
it. The controls on a view message the controller, which may then  
alter the data in the model as a result, which then causes the view  
to update.


MVC, in it's core is a control loop in a single direction. Control  
inputs change->Controller modifies Model-> View shows updated model  
changes.


People embellish the core model as they wish, but really the basic  
MVC pattern is simple and does not require adaptors.


There could be adaptors, there could be multiple models, there  
could be views encapsulating their own mini-MVC. MVC can be  
extended and made more complex, but the basic principle is very  
simple.

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders


Karl DeSaulniers
Design Drumm
http://designdrumm.com

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders


Karl DeSaulniers
Design Drumm
http://designdrumm.com

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] MVC style Correction

[Karl DeSaulniers]

I have not created any MVC (I don't think) per se, so I am no  
authoritarian by any means.
It just seems that when coding a paradigm, you want to keep it simple  
as possible so as to not confuse yourself or the paradigm.

I would tend to agree that a controller should do just that... control.
a view should be used to display and to send updates back to the  
controller depending on the user interaction.
the model just sits there and gives and takes data, formating it for  
the view maybe or sending back errors for the controller.
I think that if your model is as simple and streamlined as possible,  
it makes the job of the controller and view much easier.

the controller is definitely the hardest worker of the three.

I think also, that if you make your model aware of the others, it  
tends to start memory leaks.

a plague of most smart phone apps and flash websites today.

Kind of like a production artist trying to do art direction without  
telling the art director. Gets kinda messy.

It can be done, but you may end up refunding the client.

Open for thoughts..

Best,
Karl


On Feb 26, 2012, at 8:36 PM, Paul Andrews wrote:


On 27/02/2012 01:45, Karl DeSaulniers wrote:
So is the basic construct to choose between a controller or  
multiple adaptors?

It seems (to me) that a combination of the two is overkill.
If you cant fit everything your trying to do within a MVC or MVA  
style pattern, your coding it wrong.

Not setting flame, just inquiring. :)

Karl


I'm with you Karl.

I see models as a repository of data, modified by controllers, read  
by views.


It's not necessary for controllers to have intimate knowledge of  
models, all that is required is that there is some kind of interface/ 
contract by which a controller can read and modify the data therein.  
I don't see the automatic need for any adaptor.


It may be that one model has a different interface/contract to  
another, so a controller designed for one model could use an adaptor  
as an intermediary to another, but that is not what I understand as  
the core concept of MVC.


Views updating models? No, not at all - they are simply reflections  
of the data model to the user, not something that modifies it. They  
only know about the data they show to the user, they don't modify  
it. The controls on a view message the controller, which may then  
alter the data in the model as a result, which then causes the view  
to update.


MVC, in it's core is a control loop in a single direction. Control  
inputs change->Controller modifies Model-> View shows updated model  
changes.


People embellish the core model as they wish, but really the basic  
MVC pattern is simple and does not require adaptors.


There could be adaptors, there could be multiple models, there could  
be views encapsulating their own mini-MVC. MVC can be extended and  
made more complex, but the basic principle is very simple.

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders


Karl DeSaulniers
Design Drumm
http://designdrumm.com

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] MVC style Correction

[Paul Andrews]

On 27/02/2012 01:45, Karl DeSaulniers wrote:
So is the basic construct to choose between a controller or multiple 
adaptors?

It seems (to me) that a combination of the two is overkill.
If you cant fit everything your trying to do within a MVC or MVA style 
pattern, your coding it wrong.

Not setting flame, just inquiring. :)

Karl


I'm with you Karl.

I see models as a repository of data, modified by controllers, read by 
views.


It's not necessary for controllers to have intimate knowledge of models, 
all that is required is that there is some kind of interface/contract by 
which a controller can read and modify the data therein. I don't see the 
automatic need for any adaptor.


It may be that one model has a different interface/contract to another, 
so a controller designed for one model could use an adaptor as an 
intermediary to another, but that is not what I understand as the core 
concept of MVC.


Views updating models? No, not at all - they are simply reflections of 
the data model to the user, not something that modifies it. They only 
know about the data they show to the user, they don't modify it. The 
controls on a view message the controller, which may then alter the data 
in the model as a result, which then causes the view to update.


MVC, in it's core is a control loop in a single direction. Control 
inputs change->Controller modifies Model-> View shows updated model changes.


People embellish the core model as they wish, but really the basic MVC 
pattern is simple and does not require adaptors.


There could be adaptors, there could be multiple models, there could be 
views encapsulating their own mini-MVC. MVC can be extended and made 
more complex, but the basic principle is very simple.

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] MVC style Correction

[Karl DeSaulniers]

So is the basic construct to choose between a controller or multiple  
adaptors?

It seems (to me) that a combination of the two is overkill.
If you cant fit everything your trying to do within a MVC or MVA style  
pattern, your coding it wrong.

Not setting flame, just inquiring. :)

Karl


On Feb 26, 2012, at 7:38 PM, Kevin Newman wrote:

I would say an adapter class is part of the controller, and it's ok  
for the controller to know about the formats of both the model and  
the view - it's job is to translate, and facilitate model data into  
generic view data (and back), even if all it does is setup a  
delegate, like an adapter.


Many times that's honestly overkill - you might be able to get away  
with just taking a list of some stuff from the model, creating  
another list of view data, and copy the subset of data it needs  
(title, description, and id for one example) in a full list. It's  
often easier to do it this way. Other times, you might start from  
MVC, but your view isn't really all that generic (be careful if you  
find yourself here a lot, you might be spinning your wheels), so why  
not just pass a reference to the model, and skip all the API  
wrangling, adapters, etc. I consider it like optimizing my time, vs.  
optimizing the machine's time.


But other times, there will be too much data to copy around, or you  
just wouldn't want to alloc all that memory just for duplicated  
data, cause that's slow on some hardware (or might use up more  
battery life, if you want to be kind to your users). That's where  
adapters comes in, to basically stream and wrap a subset of the full  
list of model data to the view as needed through an API, rather than  
all at once in a giant copy.


The real problem seems to be that patterns are descriptive, more  
than prescriptive. So as implementations change, ideas tend to  
diverge, and sometimes differing patterns might even get described  
by other names. Maybe I've been describing MVA for example:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93adapter

Use what works, and doesn't drive you mad. That's what I say. :-)

Kevin N.

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders


Karl DeSaulniers
Design Drumm
http://designdrumm.com

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] MVC style Correction

[Kevin Newman]

I would say an adapter class is part of the controller, and it's ok for 
the controller to know about the formats of both the model and the view 
- it's job is to translate, and facilitate model data into generic view 
data (and back), even if all it does is setup a delegate, like an adapter.


Many times that's honestly overkill - you might be able to get away with 
just taking a list of some stuff from the model, creating another list 
of view data, and copy the subset of data it needs (title, description, 
and id for one example) in a full list. It's often easier to do it this 
way. Other times, you might start from MVC, but your view isn't really 
all that generic (be careful if you find yourself here a lot, you might 
be spinning your wheels), so why not just pass a reference to the model, 
and skip all the API wrangling, adapters, etc. I consider it like 
optimizing my time, vs. optimizing the machine's time.


But other times, there will be too much data to copy around, or you just 
wouldn't want to alloc all that memory just for duplicated data, cause 
that's slow on some hardware (or might use up more battery life, if you 
want to be kind to your users). That's where adapters comes in, to 
basically stream and wrap a subset of the full list of model data to the 
view as needed through an API, rather than all at once in a giant copy.


The real problem seems to be that patterns are descriptive, more than 
prescriptive. So as implementations change, ideas tend to diverge, and 
sometimes differing patterns might even get described by other names. 
Maybe I've been describing MVA for example:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93adapter

Use what works, and doesn't drive you mad. That's what I say. :-)

Kevin N.

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] Importing A Button or Other Component Dynamically With Pure AS 3

[Henrik Andersson]

Please don't tell us what the error is.
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

[Flashcoders] Importing A Button or Other Component Dynamically With Pure AS 3

[ITSCO]

Hello Actionscript Experts,
 
 
Scenario: I have a shared library *.swf file with most of my  assets.  It 
is loaded after the main  introductory *.swf file is already loaded. I then 
call from the Shared Library  file the needed assets. 
Appears that this scenario of importing assets works great with all  my 
custom ones (Sprite, MovieClip, Bitmap, etc).  However, when trying to do the 
same with  any of the components like Button, Datgrid..etc, I get an  error. 
Right now it appears, the component must be stored in the library  of the 
main introductory file, and be linked, which thereby makes this  introductory 
file large. 
Any idea and/or solution/comments will be appreciated.  
Thanks, 
Dan
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] MVC style Correction

[tom rhodes]

i've done stuff with my own informal model, view and controller separation.
i've done things with pureMVC and now i've done a couple of things with
robotlegs. i much prefer robotlegs, it's made me think of a lot of things
differently, has reduced the size of my classes and i think enforces a
better separation of the different tasks in your application which helps
with code re-use.

On 26 February 2012 18:20, John McCormack  wrote:

> Thanks Henrik,
>
> I guess things are much simpler if all parts know enough about the data
> format to be able to do what they need to do. I think I was imagining
> things more complicated than they need be.
>
> Thanks Ben, this was interesting...
> http://www.slideshare.net/**RichardLord/application-**
> frameworks-the-good-the-bad-**the-ugly
>
> Robotlegs has good press. I wonder what people on this list prefer?
>
> John
>
>
> On 26/02/2012 14:07, Henrik Andersson wrote:
>
>> John McCormack skriver:
>>
>>> Kevin mentions...
>>> "...need to transform the format to fit the view, you would do that in
>>> the controller"
>>>
>>> Henrik mentions...
>>> "The data changing should be done in an adapter that the controller puts
>>> in between the model and the view."
>>>
>>> So the problems arise because the data that isn't quite what the model
>>> stores, or isn't quite what the views use.
>>>
>>> At the same time the controller shouldn't know about requirements of the
>>> model and views, but in this world of isolation and 'not knowing' about
>>> other things we need adapters that do know the details of other parties.
>>>
>>> Do all systems need adapters that convert data into the appropriate
>>> format?
>>>
>>>  It is fine for the controller to know the identity of the formats
>> involved. But understanding them is probably overkill.
>>
>> A well designed system will often have situations where the view and
>> model use the same format, meaning that there is no need for any adapter.
>>
>> __**_
>> 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] MVC style Correction

[John McCormack]

Thanks Henrik,

I guess things are much simpler if all parts know enough about the data 
format to be able to do what they need to do. I think I was imagining 
things more complicated than they need be.


Thanks Ben, this was interesting...
http://www.slideshare.net/RichardLord/application-frameworks-the-good-the-bad-the-ugly

Robotlegs has good press. I wonder what people on this list prefer?

John

On 26/02/2012 14:07, Henrik Andersson wrote:

John McCormack skriver:

Kevin mentions...
"...need to transform the format to fit the view, you would do that in
the controller"

Henrik mentions...
"The data changing should be done in an adapter that the controller puts
in between the model and the view."

So the problems arise because the data that isn't quite what the model
stores, or isn't quite what the views use.

At the same time the controller shouldn't know about requirements of the
model and views, but in this world of isolation and 'not knowing' about
other things we need adapters that do know the details of other parties.

Do all systems need adapters that convert data into the appropriate format?


It is fine for the controller to know the identity of the formats
involved. But understanding them is probably overkill.

A well designed system will often have situations where the view and
model use the same format, meaning that there is no need for any adapter.

___
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] MVC style Correction

[Henrik Andersson]

John McCormack skriver:
> Kevin mentions...
> "...need to transform the format to fit the view, you would do that in
> the controller"
> 
> Henrik mentions...
> "The data changing should be done in an adapter that the controller puts
> in between the model and the view."
> 
> So the problems arise because the data that isn't quite what the model
> stores, or isn't quite what the views use.
> 
> At the same time the controller shouldn't know about requirements of the
> model and views, but in this world of isolation and 'not knowing' about
> other things we need adapters that do know the details of other parties.
> 
> Do all systems need adapters that convert data into the appropriate format?
> 

It is fine for the controller to know the identity of the formats
involved. But understanding them is probably overkill.

A well designed system will often have situations where the view and
model use the same format, meaning that there is no need for any adapter.

___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Re: [Flashcoders] MVC style Correction

[John McCormack]

Kevin mentions...
"...need to transform the format to fit the view, you would do that in 
the controller"


Henrik mentions...
"The data changing should be done in an adapter that the controller puts 
in between the model and the view."


So the problems arise because the data that isn't quite what the model 
stores, or isn't quite what the views use.


At the same time the controller shouldn't know about requirements of the 
model and views, but in this world of isolation and 'not knowing' about 
other things we need adapters that do know the details of other parties.


Do all systems need adapters that convert data into the appropriate format?

John

On 26/02/2012 04:13, Karl DeSaulniers wrote:
Why the extra step? Shouldn't the controller be that adaptor that is 
already between the model and the view?

It's a MVC not a MVAC?? :)

Karl


On Feb 25, 2012, at 7:44 PM, Henrik Andersson wrote:


Kevin Newman skriver:

On 2/25/2012 8:00 PM, Paul Andrews wrote:

Who is then?


The model - but it depends on what you really mean by manipulate - if
you are storing it (such as in a database) to be retrieved by the model
at a later time, the model should do it. If you are channeling the data
to a generic view, and need to transform the format to fit the view, 
you

would do that in the controller.

Kevin N.



I disagree. The data changing should be done in an adapter that the
controller puts in between the model and the view.
___
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders


Karl DeSaulniers
Design Drumm
http://designdrumm.com

___
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