Forums: Flash:

long title, i know.....

So, as you know I've struggled with a 'process' for AS3 and how it seems like everyone is doing their own thing versus how we all developed in AS2 (actions layer, first frame, external swfs into levels kind of things). I thought maybe we at 12s could loosely define a standards process. I'm just thinking out loud but if we all contributed, it would help me for sure and I don't know if I have anything to add or not but here's my start and it includes the Flash IDE......

New Flash document in the IDE and immediately assign it a Document Class to define Stage align and scale modes.

Make a new MovieClip (timeline or in the Document Class) and name it _root or Root so you have a base timeline to work with. Assign it a Class and build your Initializations there and assign it a Controller and Model (I'm assuming the Root would be the View then).


...just thinking out loud...if this is dumb remove it. I just thought we could all help define a better less-scrambled process.

Ok this is my current approach it is probably non standard?

For simple stuff I have a two Swf structure, this is so that i can compile the two swf's independently, it all comes down to making best use of application domain keeping the initial load small to get something on the screen fast and allows me to switch code between haxe or as3 and allows designers to adjust final graphics easily and change layout.


1) Flash IDE layout/graphics/assets

My current process is to create a assets swf with a 'layout' linkage movieclip.
I then layout assets and give them linkages but they all inherit off MovieClip or Sprite (so that I can compile seperately ) and apart from stage names of sub symbols and MovieClip button labels and animation stops this Movie does not have code, or a defined document class apart from code flash will auto generate.



2) Flex SDK / HaXe mostly just code and some graphics used in loader.

I create a flex or haxe project, the main class waits for some sort of asset management loading class to be ready (to have finished loading in XML (or XML's) wrapped as a model (s) and the asset swf wrapped easily to add assets to stage based on positions. The main class throws a loader bar on screen.

The main instance when basic assets and XML have loaded, passes the assets that are wrapped as an asset helper and the model which can query the XML to my main controller. So the main is fairly sparse/generic it basically waits for stuff and then passes them to the main controller.

When the main controller starts it has graphics and xml content, some images maybe loaded on the fly but everything else is wrapped nicely ready for it.

The main controller sets up the views or subcontrollers passing the relevant model data and the relevant visual structures adding stuff to stage as needed. The main controller has some of the main nav logic or delegates it to a helper.
The main controller to some extents sets up the main depth aspects of the whole movie so the views only worry about substructure which are mostly done in the graphic assets already, and the views also deal with button logic etc.. They are a composite structure so I don't often have a class per MovieClip/Sprite its just OOP overkill often and I find it take too much time and actually makes harder. For instance if there a set of Movies/tabs they are would be dynamically generated in the view based on the model info passed, or a drop down or papervision image wall they would be passed some visual assets to display and handle button interaction and then just pass back to the main controller when something has happened.

So the main controller handles interactions between the various views, although sometimes a view will contain subviews or have a subcontroller to hold visual logic, often views only have setup info of more generic sort of components.

So its a bit like MVC but more practical and specific, with a lot of generic classes to help with some of the more generic aspects.


I have not used it on many projects I have found that really for 3D I need something like the Flash IDE swf but am yet to resolve a solution.


My approach is OOP does follow a practical approach to a rough MCV, it makes best use of flash for asset layout, separates code and graphics to a greater extent than most people seem to in that I use Composite and rarely extend Sprites or MovieClips instead I often extend EventDispatcher. I do not create a class per MovieClip/Sprite as I have found for visual development this 'java' style approach is often overkill and makes it harder to develop rapidly.

Use my approach with caution as it probably will not suit the current Java mentality and maybe labeled bad by code heads, but I feel it is more akin to dynamic oop and traditional flash, I particularly like that I can switch my code base easily to haXe. To extend the principle it would be nice to be able to switch the graphic swf wrapper to instead help with say javascript elements in the form of CSS or... but I have not worked that out yet, I know switching Sprites in Sandy can be done in the compiler class so it might not be as mad as it sounds.

Cheers sorry a bit long and I am sure as a picture it makes more sense!

My main worry about AS3 is garbage collection it all seems a bit hazy and I would really like to feel I had a good understanding of how to handle it, mostly I try to hide rather than delete but with larger structures you have to kill some.

wow....

I like #1 but I'm not sure I fully understand it. Is it al your MCs in one .swf that you use code to pull from and reposition in other timelines later?

I create a 'layout' linkage movie(s) once it has loaded, it has various movieclips in, I then collate the linkageId's so I have an object of all the visible classes so that I can create them as needed for dynamic layouts and I also have an object that collect the instance names thier linkage and positions. So it becomes fairly trivial laying out structures, I effectively can add Movies by instance name with position or by class where ever in my structure I need or tween them to position. A designer can later tweek graphics and positions without recompiling or touching the code. A project manager can do the same with the text. Often formats will be set by the way the designer sets up the textfield but you can load css in really depends. Movies in the layout can contain whole view movieclip structures or just a graphic, its really left to what works at the time. The important thing is that you could rearrange or reskin a site easily.

I am looking at running through an example with haXe as a tut but would be interested it putting code to content/design if you have something?, otherwise I guess it will be like a video page, a photo page a contact page and a home page and a other text page or something, maybe a 3d page all flowing between each other prob just with pencil sketch design but would be good to put it to something real but needs to be something I can release all source for so if you have a cheap skate client that doesn't mind being part of a tutorial!

Later I could add an admin part for uploading content.

thanks for the clarification.....will look into doing that once I get a better handle on my own thoughts.

So, I've run into a block on my thoughts already.

I have a Document class that sets the Stage properties and I have a MainTimeline MC that I add by code. But it HAS to be a MovieClip and cannot extend EventDispatcher to work as a Controller...meaning I need to add a new Controller class UNDER MainTimeline and then the graphic elements become children of the Controller and NOT the MainTimeline. I'm so confused by the multiple levels of code needed for such a simple Button talking to Controller to run a function from another Class or MC.

So, now I'm left with:
Document Class
-- MainTimeline
------Controller
----------View
-------------Button
-------------MovieClip
----------Model
Since you need classes for all these too, how do you keep track mentally of where your code is once the project grows? There's going to be a lot more Buttons and a lot more MCs in a real project let alone a test of OOP processes.

And if Controller is handling the Events, does everything have to be View.MovieClip for the visual? MovieClip would certainly be easier.

Originally posted by: Storm
...But it HAS to be a MovieClip and cannot extend EventDispatcher to work as a Controller...

got nothing to add to the topic.. but just wanted to say that if your class extends from MovieClip, you can dispatch events anyway without needing EventDispatcher. Just sayin'

The main class is normally always a MovieClip/Sprite, but you can pass it as a reference to a controller, I really feel that it helps to separate timeline and classes/instances it is a common mistake to treat the structures as the same/interchangeable, you can and people do.. but it restricts your code.

My approach to OOP is to package complex thoughts... If something is complex or messy it is made into a method or a class and I can just deal in simpler stuff.

For instance I think application domains are messy so I have a class that wraps loading and then just choose if I want a separate or same domain loading and if I want to load an array of images well that's messy so I let another class extend my simple loader.

Class (I really mean instance) construction is often in terms of use and time of use.. but depth construction is in terms of what is on top that is why it is often better to construct a lot of the depth structure prior to creating a view, which may never actually be needed, but you don't want to be reordering depths all the time as most of the time you can fix depths for all time.

Extending MovieClip really can make life easy but it also easily ties timeline structures to class structures and instance communication can be complex and heavy; if you have to travel up and down a chain of visual arrangement objects, when often the arrangement objects are just to allow silly things like easier offset rotation etc...

For me a view takes charge of a group of MovieClips and textfields, the view deals with all the visual logic... I pass an event up to a controller if it is a state change, but how the view changes is delt with at the view level, my views only provide info for other things to change.

Does that help... in other words any view in my approach normally has

var _scope: Sprite;

which is set on construction or it may have several MovieClips passed to it, but creating a new view does not actually dictate creation of a Sprite/MovieClip.

By trying to partition thoughts and simplify the interface to them and to limit there influence on other parts/thoughts... it can be easier to create complex code without getting lost?

There is a hugh difference between clever code and cleverly simple code, the second is more worthwhile if code can still be kept suitably generic.

ok, that all helps..thanks.

I honestly must confess I think my problems lie in the fact that I'm using the IDE and FlashDevelop. I like to draw. I enjoy it and I like animating, so I make my MCs and put them on stage but when I write my class codes I run into reference errors all over the place and I think that's where my problems lie. i can't call functions from or to controllers or from or to other MCs and I'm beginning to think all of my frustrations come from having a MC on stage and then having to rereference it on the class only to have it conflict with namespaces. Maybe I can actually do AS3 just fine but getting frustrated because of the IDE. Yes, I know I can turn off Strict and Instance name preferences but then I don't learn exactly what I'm doing.

I built my Video Player class in AS3 over a year ago and it is fully skinnable and fully functional but when I try to build modules and sites nothing works right. I need a better standardized process and maybe code-only is where I have to go. I hate to give up actually laying things out on stage though....it's what I do best!

well I'm no OOP expert, but I would say that the class that is controlling an MC on the stage shouldn't be trying to call functions on other MCs or on its parent MC - it should be dispatching events that get caught higher up that then generate the function call. Of course it can call methods on its child objects though.

And I know what you mean about referencing stuff on the stage in the code... it is a pain and always seems like you're coupling up things that should be separate (e.g. the class code needs to know how you've set up the MC on the stage with all its children and so on to be able to control them).

I also work in the IDE and FlashDev.

I just finished a project where I thought, fuck it, let's go oldskool on this one (it was worth less than an XDUD project). So I used AS3, but put almost all the code on the timeline in keyframes... but frankly doing it that way turned out to be as frustrating as coding it up in classes. At least I could lay most of it out on the stage though Hopefully I'll never have to maintain it...

I'm still reading new articles where people are confusing timeline = procedural and .as files = oop. Just because it's in a class doesn't make it OOP!! OMG people are getting so confused and just confusing others.

DBM, see...... if you could "draw" that out in a interactive design document I'd fucking love that. I got confused with this: "dispatching events that get caught higher up"

So the eventHandlers are in a class ABOVE the controller but other methods can be in the children?

So the "Controller" is communicating to people above him? That's requiring knowledge of their functionality and will require a parent or root reference would it not? That's where I get confused because all articles are the same....use a controller to send events to the view and model, but no one breaks it down for us visual people. Most show V and M below C but then they break their own OOP rules to run a function somewhere else (procedural).

But I know you're completely right here:
"controlling an MC on the stage shouldn't be trying to call functions on other MCs or on its parent MC - it should be dispatching events"

And I find that's even more limiting because somehow Flash isn't democratic anymore.....it's totalitarian....you have to send an event to a controller and he will dispatch the message and parameters onwards for you. YOU CANNOT TALK TO THE OTHER MOVIE CLIPS!! OFF TO THE GULAG FOR YOU!!

lol

[edit]
slightly unrelated but this article was a better read for me than ANY of the "OOP in AS3" articles out there. This article lays it all out and takes concept to reality and explains the purpose (the why) for the breakdown.

inst.eecs.berkeley.edu/~cs162/sp07/Nachos/chess.shtml

yeah you know I think you're getting too hung up on this quest for the purest OOP


I don't follow the MVC pattern, nor any other pattern really, other than build on what I've done before.

I'll try to explain what I meant quickly with all that dispatch event business...

imagine you have a panel, for like a "Are you sure?" prompt - this panel could be controlled by a class. The panel would contain two buttons, Yes and No. The buttons don't know anything about the panel they're in, they just dispatch events like MouseEvent.CLICK when appropriate. The class controlling the panel listens for those events and acts on them.

Or imagine a list of 3 radio buttons - what's your favourite colour? Radio buttons for Red Blue and Yellow. Each of the radio buttons doesn't know anything about the other two - but when they dispatch their CLICK event the container they're in must make sure the other two buttons are OFF. E.g. I click Red, so Yellow and Blue must be turned off -but does the Red button need to know about the Yellow and Blue buttons for that to happen? No, the container can handle that.

It's not Flash being totalitarian - it's OOP Send us a postcard from the Gulag.

Perfect...going visual for me. Awesome.

BUT.....(yeah I'm a dumbass...treat me as such)
"The class controlling the panel listens for those events and acts on them."

The program has to do more than make one decision. So, clicking the Yes or No button actually leads to, let's pretend, 3 other things.....it closes the panel, reloads the program to Screen 1, and then posts the Welcome / Start Here page again and this is where I get mad at the articles. I understand that Panel listens for Buttons Events. Oh I can handle that. So, Panel can close itself. Big deal. That works fine. But now Panel has to tell Main movie to go to Screen 1 and Main has to load the Welcome Start Page again. (ok bad example here I'm painting myself into a corner because Main should always be in charge of the Welcome Screen.....but pretend I gave a better example!)

Should Yes be allowed to know more about the program it is in? It can do so much more than just tell Panel that it got clicked and let Panel decide something just to pass another message onto Main (based on who sent the message Yes or No) who passes another message on to blah blah. Yes can most certainly say:

Panel.close
Main.gotoScreen1
Welcome.reappear

(caveat: those are not technical programming terms hahahaha)

Too many function handlers being written all waiting around for a message and I fail to see how that helps minimize memory usage. Nor does that help make alterations to the program when the client changes their mind 8 million times. "Button does what? OH, now you want the button NOT to do that?" ok, go find button code. Change. Done.

Anyway, I'm getting off track.

So, for me to find a good system I would like one Controller or one Controller per Section in the case of a large app. Where is Panel from the Controller? Right under it meaning Controller called "new Panel()"? that's what I'm not getting because if Controller doesn't know who Panel is, you end up putting in multiple references all over the place so everyone can listen to Panel's event. (or am I wrong there?)

you're wrong here

Let's say there's a Yes button in a Confirm Panel in a Screen in an Application. OK?

Application calls new Screen()
Screen calls new Panel()
Panel calls new Button()

So the button gets clicked....

> It dispatches its MouseEvent.CLICK event
> The panel hears this, and knows that this means it has to first dispatch an event itself, then close itself.
> Panel dispatches CustomPanelEvent.CONFIRMED (I just invented that event, you can do the same)
> The Screen hears the CustomPanelEvent.CONFIRMED from the panel and knows that this means that the user has confirmed whatever the panel was suggesting, so it now does whatever it has to, which will very likely mean that it has to dispatch an event that the Application can hear. Maybe the Screen also has to close itself, or draw something new or whatever.
> The Application hears the event from the Screen - maybe it now knows that it should send a message to another Screen to show itself.

So you can't have buttons that know anything about screens, or even panels - much less know about screens that they're not even in (as in, close the screen I'm in, open this other screen).
Also note that this means that, for instance, the Screen doesn't know anything about the Buttons in the Panels, and the Application doesn't know anything about the Panels in the Screens. You notice I called the event that the panel dispatches CustomPanelEvent.CONFIRMED and not CustomPanelEvent.OK_BUTTON_CLICKED? That's because the Screen doesn't care how the Panel was confirmed - in this case the OK button was clicked, but it could have happened by some other means.

You have to delegate stuff to the right objects. It can get confusing with these events, to be honest I'm not fluent enough yet to have much of a method going on, but that's pretty much how I understand it.

See I know your right and it was very well explained. Thank you. I honestly would like to find a better way where one Controller can pass all those messages on so that OOP can be the advantageous thing they keep saying. If you're building 3 messaging structures for one event (User said Yes) then you could potentially have 3 things to change when client changes their mind. It no longer takes advantage of the advantages OOP defendants proclaim as advantages.

You've got messages climbing ladders when one Event should be appropriate and this is what no one is helping me learn. I am yet to be convinced OOP is the way for Flash unless you have full control over all decision making on the project such as how EA makes games or how Microsoft makes Word as an example.

I'm still not getting the advantages as a philosophy and as a time-saving work structure.

Personally, I thank you for teaching me what you know. I wish I grasped it even at the level you do. I'm a horrible programmer mentally so I've made some pretty wicked fucking complicated Flash apps for Honda and other clients and the only place I've used OOP in any way that made sense to me in my head was my AS3 Video Player. AS3 there was fucking awesome and helped immensely. Everywhere else it seems a nightmare to change and write code. And every wicked piece of Flash I have made over the years has had minimal code. I looked at other people's Flash code and I'm like "you probably could have done that in 65 lines of code versus your 185" so if I'm now writing 215 in AS3 I get right choked. And that's where my mental block is coming from.

So, what I ask is this from everyone......

I'm going to redo a current AS3 project from scratch and I want all y'all to guide me and make my decisions. I will listen and not bitch about 215 lines of code. Give me a day or two to outline the project and then help me switch my designer brain over...PLEASE. And I believe that in this process we can start finding a standard. I'd like to incorporate JLM's method but it's beyond me right now, so hopefully he's willing to help.

Project (I will update this as I think of things)

Honda/Acura dealer training (no specific "secret auto company" stuff revealed)
User's log in a .NET system. Session information passed by JS to Flash as FlashVars.
I load FlashVars, build user information, pass parameters back to .NET, retrieve XML to get a list of course that person needs to take, display that list in custom graphical layout.....NO COMPONENTS. All Components built by me..even drop downs. I'm a designer remember.

Process:
Flash IDE - New Document
FlashDevelop - New Project (Flash IDE)
FD - New Class | Document.as
IDE - Document Class = Document.as

Document takes care of alignment, default stage parameters, etc.

IDE
- new MovieClip | UserInformation
--- displays name and job code (eg Sales Consultant)
- new MovieClip | CourseScroller
--- loads new MC | CourseList which displays the courses (using new MC | CourseMC)
- new MC | JobCodeSelector grabs JobCode from UserInformation and lists all jobs the person may have and makes Drop Down List (new Component)

FD
- new Class CourseScroller - has scroll code
- new Class CourseList - displays the courses by repeating CourseMC vertically
- new Class JobCodeSelector - displays jobs and allows user to switch between his multiple jobs.

JobCodeSelector also has one button at the bottom of the list always visible allowing the user to go to a screen to see ALL JOB CODES for dealer personnel. They can select any job on that screen, return to the main screen and their name is still there, but the list is now for the Job Code and not for the user.

So, should a new Controller be declared at the top in Document.as to handle all events? Or is it too difficult to handle all the MCs messaging?

What would your approach be? Keep in mind every MC needs a display because everything is custom graphics and can't just load a Component through code, so there's LOTs of switching with the IDE and FD and instance names on stage become a nightmare to reference. Should there be a FlashVars Class just to call the params from the loaderInfo object or best in Document? etc etc tec How do you approach the thought processes here?

note: there is other stuff like Search function, Information Panels, Course and Test Buttons, etc. I'm giving general stuff for planning only.

See I know your right and it was very well explained. Thank you. I honestly would like to find a better way where one Controller can pass all those messages on so that OOP can be the advantageous thing they keep saying. If you're building 3 messaging structures for one event (User said Yes) then you could potentially have 3 things to change when client changes their mind. It no longer takes advantage of the advantages OOP defendants proclaim as advantages.

no I don't think that's true - What would you have to change if the client wanted the button to say Ok instead of Yes? Just the text on the button. What if they the user to confirm by typing YES into a textfield instead of clicking the Yes button (contrived I know) - you change the panel and the button, but the event the Panel dispatches is still CustomPanelEvent.CONFIRMED and that's what the Screen listens for - the Screen wouldn't have to change at all. Maybe you can think of a situation where you'd have to change all 3 classes and their events?

Also remember that the classes for Panel and Screen would likely be extended from generic Panel and Screen classes - these generic classes would define how the panel can close for instance, and the screen would do similar. So although you have 10 different panels, they all close the same way and that code is only written once in the generic Panel class definition.

My advice to you would be to create decent OOP classes for the smaller parts of your app, and nt worry so much about making the main document classes all proper OOP - you could even write it on the timeline. That way you get some practice writing smaller, easier to conceive and manage classes, and once you're more comfortable with it then you can move on to making the whole beast OOP.

Sorry, I haven't really got time to go thru your project with you though. Oh but I just read this line from you and want to respond:

So, should a new Controller be declared at the top in Document.as to handle all events? Or is it too difficult to handle all the MCs messaging?

No - why does the top level object have to know about and listen for all the events that may be happening at the lower levels? In my App/Screen/Panel/Button example - does the App have to know when the Button is clicked? No. And it shouldn't know - because that would imply that the App has knowledge of the inner workings of the Screen, and in turn of the Panel - all the App knows about are the events that the Screen(s) can dispatch, that it can listen for, and also the public methods that are available on the Screens. All the other stuff is in the "black-box" that is the Screen object.

This is where OOP is helpful - because if you have to change how a Panel works in a Screen, the App doesn't have to change AT ALL - because the Screen handles it all.

Storm

Not a big one for all written specs.. here is what I would probably cobble together from project managers/designers before I would code/layout the flash so if you can create them then I will put it together as a final sources. Theoretically you can swap my implementations of views out if you already have code for them, I doubt I will be doing perfect views. Anyway here is what I would need being lazy


SPEC REQUIREMENTS:
1) Can you post some dummy XML, enough to actually test and look good in any tests would be ideal!
2) Can you post a single screenshot (from above it looks like a single page?) showing a layout with some annotation relating it to the XML, details of button states, functional notes, text formatting, fonts etc...
3) dummy FlashVars might be useful (feel free to create the html!)


Just adjust your generic project to the state where it looks/feels different from real as long as its interesting enough to make a full example, screenshot can be a pencil sketch, in fact that might be better, but just a jpeg no fla, helps if it looks sweet.

If there is enough info Ill throw something up (prob in haXe/flashIDE as my as3 classes have been used commercially so simpler to keep the code independent and it would be nice to put on the haXe wiki if its any good), then others can laugh point and change it round to their approach and fix bugs etc... As I said I think my approach works well but I am sure it can be refined and argued over.

I am happy to put in effort in as long as it can be made into an opensource example.

But if you don't have time I not overly bothered.. I got my new film camera today really excited.. so later I will want to play.. and started learning blender for 3D its cool I can extrude cubes today.. dinosaurs tomorrow, yer going to get with video and 3d, code gets boring after awhile.

Blender fucking rocks. You'll love it. I designed my whole house in it before I ever built it. I hate that everyone thought I bought some 3D home design program at Staples. Fuckers! Anyway, Blender is sweet. I especially like the controls in the interface. Works brilliantly once you get used to it.


Thanks. I'd have to make a "fake" project to open source anything because of who I work for. They're not the best advocates for openness in technology. Secretive is prevalent here. When Acura built their new design centre, we were allowed in for one day to see it and it would be closed forever after that point.

It's a simple project and it works as is. My quest for "perfect OOP" comes from my wanting to understand everything and always doing everything at a high level. If you're just doing things to get them done I feel life to be unrewarding operating that way, so for me, I admit, I get frustrated by people hack and slash approaches and calling them OOP when in reality, shit we did in AS2 was way more OOP even without classes! That's my inner demon..now you know. I have to do it as perfectly as I can...otherwise I'm lying in job interviews when I say "I do everything OOP."

DBM:
"why does the top level object have to know about and listen for all the events that may be happening at the lower levels?"

Because it's democratic non-hierarchical. Why can't a button tell 8 MCs what to do? That is what made Flash fun!!! And if all of a sudden button needed to do 12 things, find button, write 4 more lines of code (or less) and BAM....DONE. Easy Peasy! Change to button functionality is easy, so I hate the "OOP allows easier code changes" BS.

I guess my problem is I think of MCs as people in a world. Programmers now want to tell me that poor lil button man should NOT be telling screen man what to do. Have button man tell controller man to wait....listen....then run and tell screen man to do his thing. We wonder why communication in enterprise fails...because this is how many businesses operate. Flash was fun and democratic. "Hey Screen Man, Button Guy here. No, I'm new ...old button guy was let go by the client. Hey, can you now pop up your welcome screen again when I say "YES" that would be great because when you do that I'm also going to have App Man grab the new data too at the same time.

CEO App Man appears...
"You can't do that. please read operations manual page AS3 that states buttons must only send out memos.....no talking directly to other members. You will use Controller Memos for all communication.

(keep in mind my degree is Political Philosophy (and my brain is unique on this planet) so it's how I think of projects)

------
Honestly, I don't need/want anyone to do my work. I think JLM's idea is cool and I'd love to learn what he does with Haxe, but I'd like to know that we in the Flash community are now using and teaching similar processes such as what we used to have....Use the 'actions' layer....use onClipEvent(load) for init data. All of sudden we have no agreed processes.

The reason I wanted to start at the top Document was an attempt to generally build a process of how people could agree to start documents. I know how to build classes and load the XML and do the little things. I just hate doing it that way because I'm writing way more code. The objective of this exercise is "how can we start using the gloriousness of FD with the limitations of the IDE but benefiting from the stage and drawing things and still make true OOP? Right now, the only way I know true OOP is only write in FD and use no custom graphics (except with calling swc files). THIS IS what I want to correct. We're going to end up making Flash pretty boring if all the great apps are Flex component RIAs. I draw something on the stage, give it an instance name, make a class for it (linkage), and then Flash gets confused with the reference. So, it only works if I don't put it on the stage.

So, DBM how many Controllers do you envision for the limited scope of my example project and where are they brought in? And do they get to know anything about each other? is there a MV&C just for loading the XML? Is there another MV&C for the Job Codes Selection? etc etc...this is what I don't get and I really want to understand through an example. I'd love a tutorial that started with "Here's the problem as dictated by the client. Our app must do......blah blah, so our approach was to create 3 controllers, one view, and 2 model classes. Controller Class 1....name it...blahblah....blah blah..."

I learned a lot from that Chess example. Most other AS3/OOP tutorials say this..."OOP allows minimal code changes and maximizes code reuseability/ Use OOP for all Flash projects and your life will be happy. Using MVC you can have one controller for each view and model." Yeah, fucking great. But you've still said nothing to help teach Flash AS3 OOP. You've only reiterated OOP Marketing ideals dumbasses. Now help work with other Flashers to help develop a best standards.

JLM, I will do the specs today and get something going on this. I decided yesterday to change the design, so we can probably safely use the old thing as an interface sketch. I'll format some XML with some fake course data and some FlashVars we'll need to test everything.

Oh, final note....I found demonster's debugger yesterday and that sure helps me out because I am only allowed to develop in .NET and IE on IIS servers, with .NET handling log-ins so I was never allowed to use trace statements in any of my real projects because I could never test in the IDE. That debugger works well for trace statements even in the browser.
demonsterdebugger.com/

like I said before I don't use the MVC pattern so I don't really know what you mean when you say "Controller" so I can't answer that question.

Didn't that article you posted recently say that the MVC pattern wasn't good OOP anyway?

Originally posted by: Storm
DBM:
"why does the top level object have to know about and listen for all the events that may be happening at the lower levels?"

Because it's democratic non-hierarchical. Why can't a button tell 8 MCs what to do? That is what made Flash fun!!! And if all of a sudden button needed to do 12 things, find button, write 4 more lines of code (or less) and BAM....DONE. Easy Peasy! Change to button functionality is easy, so I hate the "OOP allows easier code changes" BS.

Now this I find interesting - you want your buttons to control how your application works now? How is that "OOP"? Your app has to know how it works, and its subordinates - the panels and buttons etc - don't need to know. And they shouldn't get involved either - because once you start spreading your app logic code throughout your subordinate objects, you'll find it a lot harder to make changes to how that logic works.
You say that it's easy to add 4 lines of code to the button class to make it do 4 more things when it's clicked - it's just as easy to add those 4 lines of code to the App class that get run when it hears the event that means the button has been clicked.

Like I tried to say before, it's all about learning how to delegate tasks to the most appropriate objects. This is why I think you should start small and work your way up to doing the whole project in OOP. Stick your app logic code on the timeline for now - do it procedurally - and create some classes that you can use to do simpler jobs that make sense to delegate out.

Controller is the Guy who listens then passes on the commands based upon the event.

I guess my writing sounds hypocritical. What I meant was "how can I switch to OOP in a simple way? Otherwise I'm just going to keep making my buttons do everything." It wasn't a Do Both situation.

"you should start small and work your way up to doing the whole project in OOP"

Done that. Done it lots. Continue to do that. I hate every second of it and I honestly (while being somewhat intelligent) still fail to see any benefit to it when simple things such as place an instance on the stage pisses the Class compiler off because even though it's named the same it says you can't reference it, so then you have to do MovieClip(root) as MovieClip blah blah blah.

ok, I'll say it again......I'm prepared to use my lack of programming skills to be the dummy in helping us 12sers find a better process for both side of the brains (that was the idea of this thread). But can we not just make this about me and my current project? I liked where you were going in the beginning "well, I have found THIS XYZ process the best" and then explain why...."because it allows me to have all button Yes-based events in one Controlling class called Controller that extends EventDispatcher and every subordinate MC uses BroadcastEvent to trigger that function. That way when the client ....blah blah" So me an example....I'd LOVE that!! When you say it, please show me how you do it. Show me your code.

This is what I hope to gain from this to the Flash community. I don't believe I'm doing OOP right. I'm doing OOP sometimes and sometimes not, but every time it feels like absolute crap. I want to poke my fucking eyes out. So, this is not about me. This is about WHY we do what we do to make things better but following true OOP along the way, so that when others read this months from now, we have a Best Use practice. Right now everyone is doing things so many stupid ways and calling it OOP. I'm doing the same as them Classes, Events, throwing in a procedural call to make something else work....but the difference is I refuse to call it OOP. It's kind of OOP. I want Flash (if it's going to be OOP) to bloody well be OOP or stop calling it OOP.

I also used MVC as an example because that's what EVERYONE is calling OOP and is right now the closest agreement we have in Flash to a new AS3 standard way of working. I feel that we've lost a lot of standards in Flash where we used to be able to just jump into other people's work. Good luck doing that now with all the different ways we have now.

"Well, it's kind of OOP here. But then I did this. No, we are a true OOP Flash agency. Only OOP. But yeah I confess I do this. Blah Blah."

I don't agree that MVC is the best either. I'm trying to speak the common language of right now in OOP Flash and whether you like it or not it's MVC.

If programmers (people with brains completely the opposite of mine) want to promote OOP for Flash and get Flash people working with them, they need to be WAY better communicators and also understand where Flash came from and that designers already had ANSWERS and PROCESSES for all the concerns they have (code reusage, file sizes, memory management, whatever). We're prepared to switch, but if they can't agree on a best process, then people like me might as well just go back to the timeline because I can and add Classes where I want (because I do), but it doesn't help me work with other programmers or write properly for if I quit or get hit by a bus. I'm beginning to think programmers never care about any of that. Designers always have (not all) but I can open anyone's AS2 project and know it in 5 minutes because we all agreed on how to build them.

Part of the reason though is because they all use Flex. Shit it's way easier to develop in than Flash and isn't even real programming. Everything's there for them. But for us "devigners" trying to draw graphics and write code and bring them all together in the IDE just ain't working.

ah maybe I give up on this idea to be the ones to start a good process