So, this isn’t an official release, but more of a call for feedback. I just finished a first-draft of a new MVC framework for Flex that I’m calling Glue.
Links
Library Example
Code Snippet
-
Design Goals
I started out with several specific goals in mind. I’ve been trying to think of how the perfect MVC framework ought to behave, and have designed Glue accordingly. I’m directly responding to the wonderful Mate framework and a few others I’ve used.
Coupling - Glue allows you to specify pieces of your app without them having any coupling to each other. Many frameworks have coupling in one direction (views know about controllers), or some, like Mate, have a map that defines all the coupling in the app (the map knows about everything, but each piece is completely encapsulated). Glue works like Mate in this sense.
Cohesion - The idea is that you put all the glue for a particular component in one place. For example, for a view, you would put injectors and event handlers in one place in the glue map. This has been an issue in every MVC framework I’ve used.
Autocomplete and Strong Typing - Mate’s introduction of the Map to tie things together was brilliant, but it gave up strong typing. Glue has strong typing throughout the map (warning: serious magic involved), except on one side of the injectors, where it uses runtime typing (it will throw an error if it can’t inject).
No overhead - Of course, there’s some overhead, but Glue doesn’t require you to create any custom events or extend any framework classes. You just define your pieces and glue them together in one file. You can use separate glue maps if you want, but you don’t have to.
Controllers Everywhere - Best practice is to call a controller function on a user action. The controller can then decide what to do with it. Controllers can observe other controllers, can inject to each other, and views can observe controllers. This super-flexible approach means you can code your app logic however you want without any technical limitations. You can also create multiple controllers that wrap the same data to create several views of that data.
Super Selectors - If you need more control than matching all views of one type, you can use the match attribute of <Glue/> to match any view by css selector. See here for details.
Other Features
- Dependency Injection
- Laziness - you can encapsulate views, or not.
Future Development
- Figuring out best practices for model adapting. I’m going to encourage creating view-level models, and coming up with a good way to convert between offshore models.
- Best practices for defining the glues - not sure if the current approach is the best. See the example and comments above for details.
Anyway, check out the source for the example and tell me what you think. There are good comments in MainGlue.mxml. I’m very open for ideas at this point, but I think I’ve captured the essence of what I was trying to accomplish.
Do you see any major flaws in the approach or goals? Please be as critical as you can. There may also be things I need to explain better. Post comments here or in the google group
3 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.
I am certainly not in a position to evaluate frameworks, however, I can say that I am picking up the example and and the style very quickly. I also really like bifff (reminds me of back to the future). Would like to help where I can if you decide to continue this framework.
The best thing you can do right now is to join the google groups for Bifff and Glue (links below), and then use them in a project. A production environment will either make or break a framework. So yeah, join up, try to use them, and ask questions in the google groups.
http://groups.google.com/group/glue-framework
http://groups.google.com/group/bifff
Damned if I know what an offshore model is, but it sounds like a great framework, Sean. I’m getting an introduction from the co-workers as I type