Hey Ben,
> Yes, I'm using CFBODYCONTENT. I don't need to see the code, the
> recommendation was enough...so I pass a parameter that nulls the
> request.footerfile and request.headfile and it works like a charm.
make sure you're using the version of BODYCONTENT that treats
headerfile/footerfile as lists. That way, given the example you cited much
earlier in this thread, you can have each sub-circuit add its own code. Also
remember that as you go deeper you Append to the headerfile but you Prepend
to the footer file.
>
> In Addtion, I'll change my <cfdefaultfuseaction> to a CFMODULE that just
> recalls the default fuse to avoid the duplication/update problems if I
ever
> change the default fuse, I always had to update the cfdefaultfuseaciton as
> well. Annoying at best.
>
hmm, this is a stylistic issue. however, having said that, i think default
should be left to catching an unknown fuseaction error, rather than the true
default fuseaction. You may also find it useful if you believe this to use
Circuits.cfm for the default fuseactions since it represents a single spot
from which each circuit is defined. You can always override the values this
way from any point
> Is there a rule as to where you using the request. scope to define
> variables? I assume in the local circuits you use attributes scope and
> request is only used for global variables?
if you're using XFB then there aren'y really any "local" circuits since
everything goes through the top-level index.cfm
Therefore no app_locals.cfm gerts used, just one for globals. In standard FB
it's app_globals.cfm , and in XFB it's MyGlobals.cfm
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
