Model-Glue and URL consistency

April 21, 2006 · 7 Comments

Someone asked on the Model-Glue mailing list how to keep deal with keeping event handler names and URLs in views consistent, i.e., if they change an event handler name, how can they avoid having to change the string wherever it appears in links in their views. Fusebox has long had a convention to deal with this known as XFAs - eXit FuseActions. The idea is to abstract the actual fuseaction name into a variable. You specify all the exit points for a view as XFAs in the XML and refer to the variable in the view instead of hard-coding the fuseaction name. If you need to change the control flow - or the fuseaction name - you just change the XFA in the XML file and your views all pick that up. Often Fuseboxers set common XFA values in the prefuseaction for the circuit or the global preprocess fuseaction for the application, making it very simple to manage exit points. You can do something similar in Model-Glue by using the value tag on an include:

Your view can refer to the exit point as a variable when building the URL like this:

Note that Model-Glue creates the myself event value automatically from the defaultTemplate and eventValue settings in the <config> section of your ModelGlue.xml file. This abstracts even the file name and event key out of your views and is good practice. Again, something borrowed from Fusebox conventions (although Fusebox does not do this automatically - it's just a common convention). If you want to set exit points globally in Model-Glue, you could make them settings in the <config> section and then have a listener for onQueueComplete which pulled all xe.* settings and added them to the event (view state).

View count: 255

Tags: coldfusion · modelglue

7 responses so far ↓

1 Raymond Camden // Apr 21, 2006 at 11:13 AM

Thanks for sharing this Sean. I have to say though I can't imagine needing to change an event name. It seems like something that wouldn't normally change. What the event may do under the hood, sure, but the actual name? Do people find those change often?
2 Sean Corfield // Apr 21, 2006 at 1:26 PM

Yes, I've changed (public) event names as part of refactoring an application (to improve naming - to assist in maintenance). But you're right that it doesn't happen very often. The most likely reason for needing XFAs (or XEs in Model-Glue - eXit Events) is when you need to change the flow of control in an application - which I've had happen more times than I can remember over the years!
3 Jason // Apr 24, 2006 at 11:00 AM

The other reason it makes sense, I think, is in long-term maintainability. For an application designed by a programmer who's no longer with the company, it helps new programmers debug if they can look to the controller to see

* all the includes
* all the method calls
* all the display files / elements
* and all the exits (where does this link to? post to? cancel to?)

Just another set of signs that can be added to the roadmap key, whether M-G's config.xml or Fusebox's circuit.xml.
4 Matt Stefan // Jun 23, 2006 at 7:31 AM

I have a situation where I need to use multiple exit points. I have one dropdown that selects a database item. I then have multiple buttons that each perform a separate action such as edit/delete/view of the data item selected. Is there a way with Model glue to handle this (one form element collecting for multiple potential actions)?
5 Jason // Jun 23, 2006 at 7:44 AM

Matt,

With M-G, your best bet may be using JavaScript on each button to reset the form's "action" parameter to the XE that corresponds to that button.

onclick="this.form.action = '#buttonXEvalue#'; return this.form.submit();"

or something along those lines.
6 Will Wilson // Mar 2, 2009 at 1:44 PM

3 years late, but all the same...

I wouldn't say the point of defining global XE's is in case they change (although this can be helpful at times), but rather that you can define them in one place and use them across the site.

Sean, do you have a code example for this? I noticed on the ModelGlue docs that <config> is now "largely unused in Model-Glue 2.0+". Is there a reason for this? A better alternative perhaps?
7 Sean Corfield // Mar 2, 2009 at 2:40 PM

@Will, ColdSpring has pretty much obviated the need for <config> within MG itself.

An Architect's View

CFML, Clojure, Software Design, Frameworks and more...