I don't think that it makes sense to categorise every class in terms of
the MVC trinity.
Classes that implement the MVC pattern, sure, but not everything else.
There's no need to put a sound processing class within the view class
hierachy, even if the view uses it to play audio from the model. It
would make it harder to see the actual classes involved in implementing
views. A given class could be used inside a view and also in a controller.
On 27/02/2012 21:19, Mattheis, Erik (MIN-WSW) wrote:
I've been putting all my class files in one of three folders, model, view,
controller. I'm mostly concerned with making the code as easy to understand as
possible.
Where would you expect transfer object class - a class that just defines a set
of values to pass as a group?
Where would you expect a custom event class?
Where would you put a class that reads from and writes to the file system?
Air.File has methods that produce UI elements. What are benefits/drawbacks to
writing the extra code to get File.browseForOpen() somewhere in the View?
What about a class that holds string values to display ion dialog boxes, on
buttons, etc? Is that part of the view or should it be defined in the model?
_ _ _
Erik Mattheis | Weber Shandwick
P: (952) 346.6610
M: (612) 377.2272
_______________________________________________
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
