Viewing By Entry / Main
April 21, 2006
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:

<include template="myView.cfm">
<value name="xe.home" value="welcome"/>
</include>
Your view can refer to the exit point as a variable when building the URL like this:
<a href="#viewState.getValue('myself')##viewState.getValue('xe.home')#">some link text</a>
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).

Comments

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?


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!


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.


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)?


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.


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?


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


Post Your Comments
Name:
Email Address:
Comments
*** Please note that all comments require moderation so it may be some time before your comment posts to this blog! ***
Remember My Information:
 



Hosting provided by