pure as3 vs frame script..

[lsatdown]

Im am getting to grips with AS3 and classes, but am struggling on where to start on a project now. There are so many ways of building a site:

pure as3, all classes and objects in library
objects in library, script on frames

What is the best solution to working out which way to start a project?

[lordofduct]

This is a topic brought up about 3 times a day here on these forums. The general concensus is that you basically just do what feels right to you. Over time you'll find your niche and figure out ways to properly manage your code in your own style.

You might also want to check out some books and the sort.

[lsatdown]

I know and im still stuck!!
I have o'reilly learning actionscript 3.0 book which has been helpful. What i'm trying to get at is how to you approach a project.
For example, I read somewhere that you should look at your design and plan out classes that you need to write first, then go through each one.
Do you need classes for everything?

The main reason why I ask, is I did a tutorial on a xml drop down menu, simple enough. Although this has taken 4 external .as files!? Seems a bit of an overkill to me?

[ASWC]

Choose how you want to do it and then be organized! That's all.

[theclincher]

Well, like they said, do what you like.

Personally, I hated developing with AS2 and frame/object actions. That made me abandon flash until AS3 came out. I fell in love.

I only use .fla files to import stuff into the library and set the stage dimensions. Otherwise, it is just blank. I use .as/classes for everything.

Of course, I'm coming from a more programmer-oriented background.

The OReilly AS3 book by Moock (or whatever) is EXCELLENT. (I skipped the part on namespaces though.)

[fentunfont]

to throw in my 2cents,

i love frame scripts for simple, trivial things. for example, if i want a button to turn blue when clicked, frame scripts all the way.

as soon as it becomes even slightly complex however, i ran away screaming.

frame scripts quickly become quite unmanageable however they are great for doing minor stuff that just isnt going to change and is specific to the graphics you are playing with (also specific to the current implementation of what you are doing)

[BernzSed]

to throw in my 2cents,

i love frame scripts for simple, trivial things. for example, if i want a button to turn blue when clicked, frame scripts all the way.

as soon as it becomes even slightly complex however, i ran away screaming.

frame scripts quickly become quite unmanageable however they are great for doing minor stuff that just isnt going to change and is specific to the graphics you are playing with (also specific to the current implementation of what you are doing)
Agree with that.


If you think your code would make more sense in an external class, then do it. If it's easier, quicker, and simpler just to put your code on a frame, then do that.

Whatever you do, try to avoid spreading your code all over the FLA. That's what makes it unmanageable. The nice thing about keeping code in external files is that it's all in one place. You don't have to spend your time tracking down all kinds of renegade code all over the place.

The other half is also true; don't put code in external classes if it doesn't need it. You'll end up with spaghetti code referencing all kinds of external classes you only use once. For the sake of simplicity, it's better to put some stuff on frames.

Usually, I put stuff that only gets used once on frames in the FLA. Everything else goes in external classes.

[creynders]

As all the others have said: whatever floats your boat.
I mix and mingle, although 99.99% of the time I do not touch framescripts.
A question I ask myself if I need to decide whether I should write code in frames:
Is the code solely timeline dependent?
If it is, I write it in the frame.
This means: gotoAndStops, gotoAndPlays etc.
From the moment the movieclip needs to interact with the user OR with other objects I take the code out of the frame. To me the idea is that an animation is the same as any other non-interactive asset, so any non-interactive code can be placed on the frame.