Interesting take - thank you for your feedback. I don't think I would have
considered something like that. I think FB4 will like this approach as well.

Eric

On Fri, Apr 23, 2010 at 3:52 PM, Merrill, Jason <
jason.merr...@bankofamerica.com> wrote:

> In my opinion, instead of anonymous objects with values that are not
> typecast, it's best to create ValueObjects (VOs, also called Data Transfer
> Objects or DTOs) - which are basically simple classes that have no
> constructor, no methods at all (maybe a getter or setter if you prefer) -
> just a class to store public properties.  So for those, I would write a VO
> class like this:
>
> package
> {
>        class MyVO
>        {
>                public var id:int;
>                public var name:String;
>                public var group:Number;
>        }
> }
>
> (you can also set default values this way if you like). If you end up
> writing functions in your VO classes, you're doing something wrong and
> missing the point of VOs.
>
> Then, all you have to do is create them:
>
> var myVO:MyVO = new MyVO();
> myVO.id = 4;
> myVO.name = "foo";
> myVOP.group = 7;
>
> Throw those into an array and you're set.  You can pass VOs through events,
> manage them in the model, have your other classes accept VOs, whatever. It's
> what Cairngorm and other design patterns use to move groups of related data
> around inside an application. This also allows for code completion on your
> VO in apps like Flexbuilder and FlashDevelop. What I typically do is load in
> XML data and create VOs from that (in my Model class) to use in my app.  I
> wouldn't recommend using XML calls throughout your app, because then your
> app relies on XML and it's structure.  With VOs, the data source can change
> (say you switch from XML to a Webservice) and your app doesn't break.  All
> you have to do is change the parsing of the data into VOs in your model.
>
>
> 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 Eric E. Dolecki
> Sent: Friday, April 23, 2010 3:22 PM
> To: Flash Coders List
> Subject: [Flashcoders] Quick question about dynamic groupings
>
> Hey all,
>
> I am beginning the authoring a class to manage objects dynamically. The
> main functionality is to group/ungroup the objects. I was thinking of
> starting out by having each object be it's own group.
>
> [{id:1, name:"foo", group:1}, {id:2, name:"bar", group:2}, {id:3,
> name:"mustaine", group:3}];
>
> And then be able to move them in and out of group objects in the class & be
> able to report them back to another class, etc.
>
> Is this the best way to handle it - would internal XML be better, or is an
> array of objects that gets manipulated around a better solution?
>
> Eric
> _______________________________________________
> 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
>



-- 
http://ericd.net
Interactive design and development
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Reply via email to