I think the benfit of URL files only appears when you put the cflocations
after an act_file in the index.cfm, not the actual fuse itself.
I think we all agree that the only way out of a dsp_file is through an exit
point embedded in that file - links and form actions, etc are executed from
within that dsp page. When app logic encounters a dsp_page, it should be the
last one in the cfcase, so the program flow stops inside the dsp_page
(forget about bodycontent and onrequestend).
Here's an example code:
<cfcase value="display">
<cfset xfa1="blah">
<cfset xfa2="blah2">
<cfinclude template="dsp_page.cfm">
</cfcase>
We can all agree that the program flow ends in dsp_page.cfm - the user gets
to determine which exit point to take.
Some people (indcluding me and JQT) argue that act_files should be treated
the same way - a given fuse should pass action from itself, not just end and
let the index.cfm take control. The act_file contains the cflocation logic
in it, and the fuse determines which exit point to use, similar to the
dsp_file above.
Here's an example code:
<cfcase value="action">
<cfset xfa1="blah">
<cfset xfa2="blah2">
<cfinclude template="act_page.cfm">
</cfcase>
Other people like to cflocate after the action file finishes, which they
claim allows more reuse of code, because the action file doesn't always exit
to the same point. They treat action and display fuses fundamentally
differently. This is the technique that was presented in the Fusebox book.
Here's an example code:
<cfcase value="action">
<cfinclude template="act_page.cfm">
<cflocation url="blah">
</cfcase>
Or straight from the book, using url_files:
<cfcase value="action">
<cfinclude template="act_page.cfm">
<cfinclude template="url_page.cfm">
</cfcase>
Those astute programmers out there might recognize an implication of
embedding the cflocationing in the action file being that you cannot call
multiple action files in a row because the first action page included would
transfer control away from that fuseaction and the other fuses would never
get called:
<cfcase value="action2">
<cfset xfa1="blah">
<cfset xfa2="blah">
<cfinclude template="act_page1.cfm">
<cfinclude template="act_page2.cfm">
<cfinclude template="act_page3.cfm">
</cfcase>
But this can be easily overcome by checking for the existence of xfa's in
the fuse before cflocationing, and only providing xfa's to fuses that you
want to be able to cflocate out of:
<cfcase value="action2">
<cfinclude template="act_page1.cfm">
<cfinclude template="act_page2.cfm">
<cfset xfa1="blah">
<cfset xfa2="blah">
<cfinclude template="act_page3.cfm">
</cfcase>
Inside act_page1.cfm, act_page2.cfm and act_page3.cfm above, you would place
conditional logic around the entire xfa cflocation code block at the end of
the fuse, asking IF xfas have been defined, and if so, go ahead and run the
logic to determine where to go and then go there.
This final code example and techinque does not use url_files, allows maximum
reuse of action files, and still provides index.cfm as a roadmap to the
application.
Now, why should we use action files again?
NAT
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
