Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at cf.Objective() 2011 (Minneapolis, MN) with: Barney Boisvert

My First Experience With Model Glue

By Ben Nadel on
Tags: ColdFusion

So, there was this emergency at work yesterday where I had to quickly jump into a Model-Glue project and make some edits. I have never done any Model-Glue work before, so I didn't expect it to be obvious, but it was much more unclear than I thought it would be. I think part of the problem was that the site ALSO uses ISAPI_Rewrite for IIS. So, all the URLs were being translated to the event model during an intermediary step. This of course, made looking at the source code for the rendered Forms useless.

What really irked me though was that the code for displaying the form and the code for processing the form were in two completely different places. Not even in parallel directories! I understand, and value, the separating of the display and the process (view and controller???), but why would they be in different places?

Now, I am not saying that this is "best practices" for Model-Glue. For all I know, this is a bastardization of the standard. All I am saying is that even if I understand the whole XML config file, it still seems silly to so distantly separate such tightly related code.

Now, I am also not trying to get flamed here. By self-admittance, I don't know Model-Glue, so maybe there is perfect reasoning behind this. Just wanted to share my first experience. And, also, I have seen stuff like this in other frameworks, like FuseBox that had different folders for actions, views, and query files. Again, WHY separate these? They already have different naming conventions which differentiate them. I guess my standard for organization is very different from other peoples. To each his own (I am NOT saying mine is better... just saying it is better for me).

Tweet This Deep thoughts by @BenNadel - My First Experience With Model Glue Thanks my man — you rock the party that rocks the body!


Reader Comments

So what would you suggest for framework-ing a site? I don't want to reinvent the wheel and if there has been work done on solving basic problems I want to be able to learn from that.

Is there anything that takes the tedious stuff out of CF development? I'm thinking rails esque type frameworks.

Or do you just have your own setup that you reuse for every project?

Reply to this Comment

I've heard such comments from people before for various conventions. It has really just come down to jumping into code out of the blue to do something quickly, without any documentation of the conventions or application architecture. Lack of documentation is often more the issue than the actual conventions IMO.

Reply to this Comment

Unfortunately, if an approach is more maintainable for large projects, it is because of better separation of concerns which typically means that there is a greater learning curve.

Most frameworks will separate views (form display) from controllers (which typically do the first stage of form processing - with the model then taking the well formed data and validating and saving it).

I actually have the concept of custom data types so I do have cfcs which in a VERY non-MVC way have methods for returning a rendered field and methods for turning a given form field into the appropriate value to pass to the model. One piece of the custom data type is called by the view as part of my form scaffolding and the other by the controller as part of my base object controller. It is non-standard, but I've found it works well for me.

Reply to this Comment

I don't think there's anything wrong with you not liking the way things are done. I personally had a look at Model Glue and other than the fact I'm not a fan of XML, I just didn't find it intuitive, it just didn't click like for example Rails did. Same thing with Mach-II. So I didn't spend much time forcing myself to use them, I just got on with building my own thing, something that is intuitive to me and allows me to maximize my productivity. It's a work in progress. However, I do use Reactor for the model side, because that framework did click and I was happy working with it.

Reply to this Comment

@Dan C.,

I am not advising for or against Model Glue. I simply don't have the experience with it to give any kind of valid argument. In my own personal programming, I have a home-grown frame work which is a kind of mutated FuseBox with much less functionality.

@Dan. R, Milk,

I agree. No matter what framework anyone uses, jumping into a project without no prior understanding, explanation, or documentation is just going to be a "no-no".

@Pete,

I am completey for the separation of views and controller logic (as much as I understand it). What I was most against in this scenario was the sheer distance between the related files. The parent directories of each of the respective files seemed to have no logical relation. That is what irked me.

I have seen "related" mentality in FuseBox, which I also cannot deal with. I have seen "display" folders that have a hundred different "view" files, most of which are not related to each other. Then there will be an "action" folder that has hundred of "controller" files that are not related to each other... so then you have this situation where two or three files that actually are related take way too much mental overhead to pull together (or maybe that's just me!).

And then there is the redundant naming convention! This irks me more than most things (I think I have ranted to you about this before, so please disregard)... either choose a FILE naming convention OR a DIRECTORY naming convention. There is no need for both. If you have a "displays" folder, there is no need to have within it files that ALSO start with "dsp"... this is completely redundant.

The file-naming convention would be perfect for group related files in the same directory, ex:

dsp_form.cfm
act_form.cfm
qry_form.cfm

But the problem is, this seems to get messed up somewhere along the line....

OK, I don't want to turn this into a rant. Sorry about that, I will stop. I am just all jazzed up because I am about to start watching the new (continued) season of The Shield!!!!!!

Reply to this Comment

I recently started looking at Model-Glue as well because I am evaluating the frameworks to see if they would help out with a quite sizable project I am about to start. Initially, from the documentation, the files are separated simply because it would extend the mindset of separation of presentation and logic. I think it is a way of tricking your mind into thinking separation. I have not tried this but you could possibly have the files anywhere if you configure it right in the xml. I am not sure about this since I have not gotten through the quick start tutorial thus far.

I have adopted, as most people it seems, a naming convention that mirrors early Fusebox and logically group all files that are related to one business task in a folder. As you said, much easier for code management!

Reply to this Comment

The reason for separation of model and view files is typically to maximize (and reinforce the idea of) modularity. If model files (actions, queries, etc.) are completely modular and grouped into their own categories and subcategories, it can allow for much more code reuse within large applications. Controllers can then chose from a wide array of available model components to use together with the (typically more page-specific) view files.

Reply to this Comment

Agree with Steve. Re-use/DRY is one of the main benefits of separation/modularity: the more you de-couple the better, and that includes physical files. A single CFC might process several forms in different display files. You can't place your one CFC next to each display file in that case without Repeating Yourself (ie duplicating the cfc).

To take it even further, a single model (i.e. folder/package of CFCs or .cfms) can be used as the backend for 2 different applications/websites/interfaces, eg admin and public versions, or Html and Flex front-ends.

Think of it like database normalisation: it's 1-many: you physically separate out the 1 into its own table (folder) so that the many can link to it without having to include and maintain a copy of the data in their own table (folder).

Reply to this Comment

You've got a point about the dsp file naming convention though, Ben. Not really necessary if the view/display folder only contains dsp templates.

Reply to this Comment

I am sure I will get there eventually (understanding)... my heifer of a brain is just extremely stubborn when it comes to this whole MVC thing.

Reply to this Comment

"You've got a point about the dsp file naming convention though, Ben. Not really necessary if the view/display folder only contains dsp templates."

I dunno. I like the "dsp" prefix, as it ensures consistency with other types for which you require a prefix, and allows you to easily see at a glance that developers followed the conventions and didn't place any actions, queries, media, etc. inside the view/display folders.

Reply to this Comment

Steve, like you I'm a long-time Fuseboxer, but for the last few years my models have been entirely CFC-based, so no more act or qry templates. The only .cfm files left are those in the View and as Ben says having them all start with dsp is redundant. I've just tried removing the prefix from the templates in one of my View folders and I like it: shorter and clearer.

If you still use act/qry files then yes the dsp distinction is important, but I'm sure you'll agree CFCs are a far better way of implementing the Model in FB, as in the other frameworks.

Reply to this Comment

Julian, I'm actually fairly new to web development, and in particular ColdFusion. I haven't yet shifted to CFC-based designs, but I agree it's definitely the way I should be heading.

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.