My First Experience With Model Glue
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).
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?
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.
Working with someone's code is a big trouble. Your post is just proved it
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.
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.
@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!!!!!!
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!
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.
That being said, I don't know anything about Model Glue. I do use FuseBox a fair amount, though
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).
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 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.
"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.
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.
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.
Sorry, thought you were a different Steve.