DIY Frameworks

Ive just been reading all the hype on the mxna list at the moment about Peter Bells comments on why frameworks suck. His comments really arent that frameworks suck, just that if you dot know how to use them properly or you dont understand the theory on why they work they way they do. ie. OO and patterns, you are better off building you own framework.

I liked sean corfield's comments about 'public,protected and private' programmers in regards to frameworks. Its true that there are framework builders, framework power users and just plain old users. I dont agree with Peter however that we should all go out and become DIY framework designers, but i do agree that using a tool you dont understand can cause more trouble than its worth.

Internally where i work we have gone down the path of building our own framework. However I did also just build a CMS using Model-Glue so I have perspectives from both sides of the coin. In my experience in using MG i found that i really liked its front-controlelr aspects (building composite views, event listeners, and all requests routed via index.cfm), but i had no real use for ColdSpring or Reactor. My solution was to just forget about those features and used the ones i found usefull and that saved me time. Trying to educate the team about front-controllers was hard enough, so i left the battle of ioc for another day.

As for Reactor, whilst I do like it as a framework we already have our own ORM framework we have been building for some time. So rather than ditching all that work just because the framework points me in that direction we stuck with what we knew.

The other issue i encounterd was educating the team about tracing the form submit process via the XML config file. They were all very familar with having all their processing code for each form at the top of the CFM template and explaining that you need to:
1. look in the xml file for that event
2. check what broadcasts / messages existed on that event
3. look for the listeners to that message
4. check the cfc of that listener for that message function
5. check what beans/daos it was creating / using to save the contents of the form.

..was a quite a problem. Most of their reactions were along the lines 'why can all this be just in the page, why do i have to look through so many files to find what i want'.

while pulling my hair out that i cant convince a programmer to the value of MVC architectures. I tried to do a couple of things to soften the blow of the transition from spaghetti to MVC:

• make the xml config file less important. If a page submits to index.cfm?event=insertUser i make sure i have a controller called userController.cfc and i have an event listener called insertUser. It seemed to make it alot easier for someone not familar with ModelGlue.xml
• in one instance i could not for the life of me get it across the routing all page request via a centrallised index.cfm was a good idea. so i came up with my own poor-man's mg framework.
• each form submits to itself.
• at the top of the form include a controller.cfm
• controller.cfm creates the eqivalent of an MG controller object where page.cfm?event= maps to objController.() eg.
  page.cfm?event=insertUser == objController.insertUser()

i guess its a bit like the presentation i saw at MXDU from Robin Hilliard about a framework you have when you dont have a framework.

So yes i agree using frameworks can paint you into a corner at times if you dont understand them. However DIY frameworks are alot of work, but you can minimise them by

• borrowing parts of other frameworks
• building cut-down imitiations of existing frameworks