Finally, FAME!
I finally found some more time to play with FAME and got Flashout working (thanks to Alex's tip on using the -clean option to make Eclipse see the plugin on my Windows machine.) Skimming through Carlos Rovira's excellent introduction to FAME (Towards Open Source Flash Development) was very helpful but I did notice something in the test code that I would do differently.
In the article, the sample document class Test looks like this:
class Test { private var scopeRef:MovieClip; function Test(scope:MovieClip) { scopeRef = scope; // --- Creates a 'tf' TextField size 100x600 at pos 100, 100 scopeRef.createTextField("tf", 0, 100, 100, 800, 600); // --- Write some text into it scopeRef.tf.text = "Hello FlashWeek!!!!"; } // --- Main Entry Point static function main() { var test:Test = new Test(_root); } }
The static main function (the entry point) instantiates the Test class' constructor and passes a reference to _root, which the Test instance uses when creating the text field. I would do this a little differently, like this:
class Test extends MovieClip { private var tf:TextField; function Test(scope:MovieClip) { // Redefine scope this = scope; // Creates a TextField sized 100x600 at pos 100, 100 createTextField("tf", 0, 100, 100, 800, 600); // Write some text into it tf.text = "Hello FlashWeek!!!!"; } // Main Entry Point static function main() { var test:Test = new Test(_root); } }
The nice thing about this doing things this way is that your Test class actually does extend MovieClip and you retain the ability to define your stage elements as members of your class and thus take advantage of compile-time error checking.
By the way, FAME *is* very cool indeed!
Comments
Look at the picture below the code to see what I mean... TRACE rocks!
http://www.jessewarden.com/archives/2005/05/fame_chronicles_1.html
by JesterXL on 2005-05-13 01:31:07
Good to see you trying and enjoying FAME. I like your new approach to application init code too. Although I think both approachs are welcome as not always we need to inherith from MovieClip and make our application mc-dependent in each application view.
I think both are good practices and you must apply each one depending on your application's necessity.
by Carlos Rovira on 2005-05-13 08:21:38
@Carlos: Regarding not making views inherit from MovieClip -- I can't think of any scenario where a view (in a Flash application) would not inherit from MovieClip (even if it extends, say, UIObject or some other form class, those would extend MovieClip, no?) Am I missing a potential use case?
by Aral Balkan on 2005-05-13 10:59:56
I used this sort of approach in my MXDU 2003 flash GIS application and I'm currently toying with it as the basis of a lightweight UI framework (yet another one).
You asked for a potential use case where a view wouldn't extend MovieClip. In my toy framework there is only one symbol containing a bounds rectangle and each view instance "has-a" reference to an instance of the symbol on the stage.
The view classes aren't movie clips - movie clips are specific to things on the stage of a Flash application, the views are more abstract and represent rectangular areas we can draw on and receive user interactions through - the methods and events might be the same or similar to a movie clip but the implementation of the methods could change - examples might include publishing the drawing commands to / accepting click and change events from an FCS stream (Flash VNC anyone?) or implementing an Excel-like "freeze panes" scroll view where one view is rendered on four movie clips with independant masks and scroll positions.
So, while most Flash application views will be movie clips, it doesn't have to be the case all the time, in fact there is a fairly rich vein of possibilities to explore when you consider separating the two.
by robin on 2005-05-14 05:38:15
Thanks for the use cases -- I can definitely see how it would be useful to use composition to add a level of abstraction in the manner you described -- I'm just not sure whether the reference to the symbol you described belongs in your view or in your controller. eg. When you mention publishing drawing commands to or accepting click events from FCS -- that sounds very much like business logic to me. What you do with these (eg. updating the presentation as a result of click events from FCS) are definitely view-related.
by Aral Balkan on 2005-05-14 10:28:34
type error MovieClip should be XMLExposer2 at line >>> this = scope
João Carlos
by joão carlos on 2006-02-16 18:09:25
type error MovieClip should be Test
at line >>> this = scope
by João Carlos on 2006-02-16 18:10:37
by Aral Balkan on 2006-02-18 23:09:50
In other words:
ASDT + Ant (The A is overloaded) :)
MTASC
Eclipse
Swfmill
Viva AMES!
by Aral Balkan on 2006-02-18 23:10:57
by Josh on 2009-07-26 16:10:38