Dec 4 2007

Model-Glue 3 ("Gesture"): Under development now!

Posted by Joe Rinehart at 4:31 PM
23 comments - Categories: Model-Glue

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.

Comments

Michael Long wrote on 12/04/07 7:24 PM

If your looking to make things easier, I'd also go with "zero-configuration" whenever possible. On initialization the system should be able to pull the names of events, handlers, views, or whatever right out of the appropriate directory without having to redefine them yet again in a xml configuration file.

Michael Long wrote on 12/04/07 7:25 PM

BTW, your blog software doesn't like valid gmail addresses like abc+xyz@gmail.com. "+" is not an invalid character.

zac spitzer wrote on 12/05/07 2:19 AM

here here on the XML-less request! Keep the existing stuff, but allow a controller definition to be auto generated via an autowire="true" in the XML definition.

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....

Jason wrote on 12/05/07 8:05 AM

"Better support for building modular applications" ftw!

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!

shimju david wrote on 12/05/07 8:46 AM

Seemless AJAX integration is what Iam looking forward in MG V3.0.

Joe Rinehart wrote on 12/05/07 8:52 AM

@michael, zac, and Jason:

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.

Rachel Maxim wrote on 12/05/07 9:23 AM

Sounds great. Making it simpler to include UDF libraries - or just giving them a "place" in the framework will be great. I'm all for xml-less configuration too. Very exciting!

Jason wrote on 12/05/07 9:24 AM

@Joe,

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?

John Allen wrote on 12/05/07 11:03 AM

All of these features sound terrific.

"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.

Mark Drew wrote on 12/05/07 11:17 AM

Thanks JOE! I start delivering all the Action Packs and you go off and start a new version! Pah!

@zac: Have you seen http://eventguard.riaforge.org yet?

wedding dress wrote on 01/21/08 9:31 AM

http://www.fashionbridalgown.com
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

Still life Artist wrote on 01/24/08 3:48 PM

So please try to keep up the great work all the time. Greetings
Andrzej Filipowicz
Still life Artist, still life art
http://www.andrzejfilipowicz.com
STILL LIFE PAINTING
http://www.life.e-phils.com