This tutorial covers one approach to Haxe flash development and is certainly not by any means the recommended, but contains one possible workflow that you may want to try, some flash developers may consider using composite views wrong and prefer inheritance, but this tutorial argues that there are good reasons to consider composite views in flash.
Many design agencies are familiar with flash IDE and so using Flash IDE for creating Assets makes a lot of sense, since Flash is easy for already skilled designers to use, currently swfmill is maybe not designer orientated!
In AS3 and Haxe it is common for microsites to have a small preloader that loads XML and graphics assets at runtime. One problem traditionally with creating graphics in flash is that classes are often linked to classes via there linkageID, this can feel very much like the old days of flash5 and putting code wherever. Another problem with creating grapics in flash is that with AS3 when you load flash movies containing graphics, you want the code to run it the same application domain as your logic code. Code is relatively speaking normally a fairly small part of a typical flash project so it is probably acceptable to mostly put all logic code in the preloader (there are more complex approches where you can separate it but for this tutorial the simpler approach suffices ).
To load graphics layouts/movies into your code movie so that all code runs in the same application domain seamlessly, synchronization is required. That is to say, everytime there is any change in either code or graphics all movies will need recompiling, this does not really allow separation of design and dev assets and is very time consuming especially if you have to use a flash compiler, and makes development with multiple people more difficult.
So for both AS3 and Haxe another approach seems logical. Native flash classes are defined below the Application Domain, and their definition between swf's is always the same. When loading a movie that only uses native flash classes we no longer have to worry about compilation synchronization. So rather than creating view classes via inheritance it makes sense to properly separate symbols and code, only linking linkageID to Native classes. Now it can be argued that wrapping a Sprite's in a View is a waste as it requires more work, but it does allow much better separation of design and code and reduces development compile time. Sometimes a view using this composite approach might be more than one spite. The common sprite inheritance that many flash developers use tends to forces java over fine graining of classes and is not as suited to visual RIA, and really slows rapid development. With a composite class you can create a view that may use several assets without resorting to infinite classes.
So having explained the reasoning for this workflow, it is time to look at practicalities and see how this approach looks in the field.
While several graphics movies can be used, typically one is fine. The main advantage of using the flash IDE is visual layout.
- Create a "Layout" linkage movie. The purpose of this movie is to define the layout of your application, using different layers and folders we can organise the visual layout of different parts of the application.
- Create symbols that will be attached in Haxe.
For instance if we want to create a close button on a popup panel, we can position it on the screen inside Layout and define labeled frames _up, _over, _down states for the Movie symbol, even though we are just using display.MovieClip in the inheritance rather than a custom class we can still set this symbol as a MovieClip button in Haxe, and it will automatically use its visual button states with out any listener assignment. Further our Haxe code can be designed to grab the symbols position in relation to Layout so that we are using Flash IDE to arrange symbols rather than code.
It can be a good idea to have atleast a loose framework. The approach here is roughly based around MVC but some terms are probably abused, if you have ideas for better terminology or extension/fine tune they would be welcome. Here is an overview of some of the principle classes.
- Starts Haxe movie
- Waits for assets to load ( shows preloader ) and then starts the principle Controller passing it the loaded Models. Models refer to a Library Instance and a XML Model. Model in this tutorial may not fit with traditional use, it is used to refer to assets wrapped for easy consumption access by the controller or sub-controllers or views.
- Controls loading of assets and return a custom event or has methods to access wrapped assets as models when loaded.
- This class will extend a more generic XML loading class adding XML specfic parsing.
- It has getters for the model allowing other classes to be given information in more useful structures, like a list or titles for a tab controller.
- Abstracts XML structure into a Model of useful data.
- This class extends a more generic Swf loader.
- It has getters to simplify positioning and wrapping of symbols in views or layout by views/controllers.
- The controller, is created by the main class when most external data and assets are loaded and passed to it. It is responsible for the main application logic.
- The controller creates views often passing them visual structures constructed from the Library_Model, and specific data from the model.
- These are classes that wrap visual interface details and control symbols that form the interface.
- Sometimes the symbols will be constructed in the controller to allow simplier control of depth organisation in the main controller other times the Library_Model will be passed to them and somewhere to construct themselves.
- View recieve data from the controller, such at text labels, the controller provides these from the model and has no knowledge of the XML structure they originally came from..
- Views typically extend EventDispatcher.
- Sometimes views are complex or consist of many and it makes sense to remove some logic detail from the main controller and put some logic in a subcontroller, for instance it might be suitable to split an application into pages and have a sub controller for each page.
In terms of implementation and example code, your free to vary the concepts of this work flow. Code will be added but it really is dependent on the communities response, it is fairly clear there are advantages to this approach but details may needed more consideration before posting code.