Model-Glue 3 ("Gesture"): Under development now!
I've just kicked off development of what is to become Model-Glue 3.0. It's not going to be anything exciting for a while: the first big milestone is to re-implement the core event bus with unit tests and more flexible (interface driven) design.
My mission for Model-Glue 3.0 is this: it's going to be a framework that you barely notice is there. Model-Glue 1.0 did this, in respect to other frameworks of it's day. It's time to up the bar and find new ways to make life easier.
Key focuses of Model-Glue 3.0 will be:
* Decreasing developer effort through what will be known as "event types" and generation of common workflows.
* Implicit inclusion of UDF libraries through what will be known as "helpers"
* Better support for building modular applications
* Increasing flexibility with even more interface-driven portions of the framework
* Increased plug-in points (onSessionStart, onSessionEnd, onDevelopmentRequestStart)
As soon as something usable is available, I'll flip the anon-access switch on the repository to read-only to make a "bleeding edge" release available. The first public code is likely to be not fully reverse compatible and to not have any ORM support.
XML is the main thing i notice when using MG, it's good to learn clean MVC but becomes a headache in complex apps, CFML is just so much more expressive and flexible.
How about automatically injecting viewstate into the view?
The other feature i would love to see is security as an integral part of the framework... security belongs and lives mostly at the controller's level and that's MG land....
No, really, that's huge. I came up with some great XML includes in MG 2 so that I could write my apps as a config that did nothing but include modules, which each had their own configs. The local apps then had the ability to extend any one of the modules or even just views locally. Nice stuff, but way too much time breaking up and re-assembling XML files, which really are flat and inefficient compared to DB calls in CFML. In MG 1, I had mod'd the XMLConfigurationLoader (or whatever it was called) to read all my config.xml settings out of the database instead of the XML, and then I built a quick management UI so that the app could be re-configured from its own admin tools, which rocked. Never had the time to retrofit that over my MG 2 work, but I would love to see a switch built in where I could toggle a given app or module between a) live off the XML or b) live off the DB. Something like that in conjunction with built-in structures for natively handling module app design would be awesome!
The whole thing is actually focused around the concept of "modules"...basically, an app fresh off the app skeleton will just be an app that loads an xml-based module from config/ModelGlue.xml.
I'm not 100% of the mechanics yet, but you'll be able to add / manage loaded modules (probably just through a controller at a new plug-in point) by creating an implementation of IModelGlueModuleLoader that basically has a load(framework) method, where "framework" has all of the necessary methods to add/remove/etc. event handlers, controllers, and settings.
In other words, someone could write a standard DB scheme for defining a Model-Glue app or define a standard for directory-based definition of an app structure, implement a loader for it, and off you go. I'm going to give a crack at the XML-less version before 3.0 is out, but I'd leave the DB implementation up to people.
Love it. When I DB'd the MG 1 config, I basically had the CRUD structures for event handlers, controllers, and all the child settings of each. What I didn't have was that load(framework) object with the ability to inject / alter as an add / manage loaded module, so I like that direction. I agree, too, that leaving the DB schema up to the developer is sweet, because certainly there are those who prefer their flavor of DB and there are those that prefer the XML configs.
I continue to enjoy watching M-G get both more flexible AND more streamlined at the same time. So glad there are people with the theoretical bent, like you, that take the time to work through excellent framework solutions like this. Keep it up!
@zac,
Security is such a big one, and it permeates all layers of an application: the UI needs to capture credentials and needs to be aware of features to hide/show/disable based on rights, the controller needs to be aware of what objects / methods can even be consumed / triggered by rights, and the model has to know both who is accessing the data and what that user is permitted to access (in particular, what data can the current user *change*?). I've tried the approach of having a base class for all my data services that abstracted the user tests across database calls, and that interacts with an abstracted session system, somewhat like the ADO.NET approach, but there may be a more generic approach that could be at least a skeleton framework within M-G. Maybe?
"event types", that sounds interesting.
"helpers" sound great, but with MG:U or 1 it is so easy to pass UDFLib objects around... heck your the smart one.
I'm excited.
@zac: Have you seen http://eventguard.riaforge.org yet?
http://www.promgowndress.com
http://www.1stpromdress.com
http://www.prom-dress-gown.com
http://www.oilpaintings-art.com
http://www.oilpaintingsmaster.com
http://www.9lover.com
Andrzej Filipowicz
Still life Artist, still life art
http://www.andrzejfilipowicz.com
STILL LIFE PAINTING
http://www.life.e-phils.com