I had an idea for a flash framework, and while I’m not fully there yet, the first of proof concepts at TriMM are very promising. It solves a lot of the problems I can think of up till now, so I’m curious to see where this will go.

Design patterns were clear enough, but their implementation is often less than straightforward. Take an MVC pattern. Have you ever found one straightforward implementation? Instead of 100k hits on google all with a slightly different twist? The same patterns that should make it easier to communicate with your coworkers come back to haunt you, since responsibilities in classes are slightly differently allocated than you are used to, mediators are called controllers, and everything is untyped or abstracted away for the sake of ’simplicity’ etc…

The ideas I’m currently having are in blueprint phase including an almost working example as well. Just a quick overview of the design goals that are being met by the current state of the framework:

• the ability to quickly put a mock application together, ie put a few views together and cycle through them with a spacebar
• the ability to automate as much as possible of the tedious parts of programming, such as generating most of the interface element creation/setting, type checking and initialization
• the ability to have a logical division of labour, eg we have an interface guy, a service guy, a datamodelling guy and an integration guy. We could add more such as a debugging guy etc. They shouldn’t be getting in each other’s way, and shouldn’t be influenced by each others work too much
• the ability to cleanly separate your application in different parts with low coupling, without losing type safety
• the ability to program without fear of making errors, knowing the framework would help you to prevent them
• the ability to have a polymorph yet type checked eventing mechanism
• the ability to start simple, ie register any handler for an event and not just mediator, controllers or commands but anything you wish
• the ability to use static fields as unique identifiers without fearing MyClass.MYFIELD1 and MyClass.MYFIELD2 would point to the same value, obscuring hard to find bugs
• the ability to take the simple application and refactor it as you please
• application wide access to parts central to the application, while maintaining type safety, without resorting to singletons
• zero singletons, including an easy way to create mock objects for unit testing
• no need for model, view or service locators
• the ability to attach the events you like and have the rest show an ‘not implemented message’ so the user interface is always responsive
• clear documentation on why the framework does things the way it does
• as2 and timeline independence
• the ability to follow the flow of the application easily, and with that the ability to centralize related functionality in single classes.

This may seem like a lot, but everything is geared towards an easy yet solid implementation without you having to constantly wonder who implements what and trying to discover the flow through your application. Lots of it might seem abstract now without a concrete example, but that will change soon.

The design goals that are not met yet but will be in the future:

• solid use of reflection to facilitate errorhandling and logging. Errors and logstatements will include classnames, methodnames, caller info, argument info etc, all without you having to concern yourself about it
• in application visualisation of the events being fired from source to destination (eg as an alpha map overlaying your application)
• and more…

This entry was posted on Monday, November 12th, 2007 at 10:03 pm and is filed under AS2, Flash, Framework. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.