what data type to use?

[joshchernoff]

I'm making a project that will include a index class "main document class" that will makes a catalog from a catalog class that will hold a group of items from a items class. Each item that the catalog class makes will have a number of properties such as "name, ID, color, type, date and so ... ". The catalog class will show as a list of thumbnails on the stage, each thumbnail will have properties of that item in the catalog with events.

Simply put if you don't already know I'm making a catalog but, what data type should I use for the items that will be visible on stage with a image and a lot of properties? Sprite, movieClip or may even just a plain old object?

I really want to make this a stricter OOP project so that I may utilize AS3's stronger points. That and I 'm really new to this so I think I better learn it now.

[Dazzer]

My style always uses Sprites.

Don't ask me why I choose them though. Maybe its just easier to type than MovieClip.

[joshchernoff]

My style always uses Sprites.

Don't ask me why I choose them though. Maybe its just easier to type than MovieClip.
well I'm thinking along the lines of memory usage, I know that sprite will use less memory because it's from what I'v been told it's a simplified movieclip with out a time line. But since I plan to use events like MOUSE_OVER and clicks and so on pluss, I want to add a image of the thumbnail and have this show on the stage I don't know that a sprite will cut it.

[Dazzer]

It will. :)

Mouse over events are all inherited from the DisplayObject class.

[senocular]

document classes have to be at least a Sprite - a Sprite or any subclass of Sprite. If you're using more than one frame on the timeline or have any code on the timeline, you'll have to use MovieClip. Otherwise, you can use Sprite - and it'd be better to use Sprite since it is a lighter class... well, Sprite or your custom subclass of Sprite (which is more likely).

Also mouse events are inherited from InteractiveObject, not DisplayObject. Sprites have interactivity associated with them, things like Shapes, do not. Shapes are like sprites in that they're like MovieClips with no frames, but they are unlike Sprites in that you cant interact with them using the mouse or keyboard. Shapes do, however, have the enterFrame event which is inherited from DisplayObject :)

[Rezmason]

You might want to make two classes– a simple class that stores the information and a reference to an image, and a class that extends Sprite that can read the first class and display the proper image. That way, when you make new objects to store information, they'll be more lightweight and won't involve the display list; also, this would allow you to recycle the Sprite-based class, reusing it when the information it represented is no longer on the screen. All that can help improve your memory usage.

[joshchernoff]

http://gfxcomplex.com/images/idea.jpghere's the simplest way I can put it for what I'm doing.
Any ideas would be a help.

I like the idea of having some type of holder like

Rezmason said
"a simple class that stores the information"

[Dazzer]

have you ever heard of MVC patterns?
I think that's what you might be looking for.(or what rezmason was referring to)

http://en.wikipedia.org/wiki/Model-view-controller

Basically your display objects are just that. for display. You'll probably have a more advanced Sprite that you'll use as a button (create a textfield for text, together with background and call it MenuButton) This is your VIEW.

Create another class (non displayobject). This class will query the recordset. And store the infomation. This is the model. This class does not interact with your View in any way. Could call this "DBQUery".

Then now your application will create this DBQuery class, perform the query, figure out how many records there are, then create the number of "MenuButton"s . Make them all nice and shiny with nice scrolley thingies and zoom effects. Or whatever you want. That's the Controller.

AS3 is definitely suitable for design patterns nowadays, where as AS2 was rather lacking in that respect.

[joshchernoff]

@Dazzer-

I thought MVC's was just a way to give a visual conception, just as I did in my example. I'm trying to under stand what you think I should do. Do you think I should make and place buttons on the stage then make a class to interact with them. Or do what I was trying to do, have the class make and place all the objects on the stage?

then there is also this idea of having two objects. One being the data and the other being the the object the end user interacts with. How would that be better then having the object that the end user interacts with hold the data?

By the way sorry that I don't under stand you all the way, I am new to this stricter way of coding so thanks for helping me out.

[Dazzer]

Oh you don't have to make your buttons a new class... But in most cases I would do that. Just to give it more functionality. Like dynamic text, animation, button events etc. You don't have to place the objects on the stage either. You can do it using actionscript if you like.

With your 2nd question, the point of MVC is separating the user from the data. They user does not need to know ALL the data (in most cases, you wouldn't want them to know all the data either). Separating View and Model means that the user never needs to know what is in the data. Just whatever is requested, and what you allow the user to see.