> Only the root level ciruits file is called. The only file
> called down the tree are fbx_settings and fbx_switch.
Maybe I just don't understand what you're trying to accomplish still...
> Disturbing about the MX though.
My solution (I haven't actually had to replace a switch statement yet, but I
do this already and if I had to fix one, this is how I'd do it), is to use a
dynamic include:
<!--- massage the path as a measure of hack-proofing --->
<cfset pathvar = listfirst(fusebox.fuseaction,"/\")>
<cfif refind("^..._.*$",pathvar)>
<!--- don't allow users to reference include files directly --->
<!--- some cf apps already use this bit --->
<cfabort>
</cfif>
<cfset abspath = getcirectoryfrompath(getcurrenttemplatepath())
& fusebox.fuseaction & .cfm">
<cfif fileexists(abspath)>
<cfinclude template="#fusebox.fuseaction#.cfm">
<cfelse>
<cfoutput>
This is the fbx_switch --
I don't understand #fusebox.fuseaction#.
</cfoutput>
</cfif>
This forces the CF Server to use its equivalent of cfinclude where the
cfinclude tag appears rather than bundling the include into the java class
for the current template. You do have to remember that you can't use
fuseactions with the pattern of 3 characters followed by an underscore like
"top_hat" etc. because that's the same pattern for the include files that
you don't want people to access directly.
s. isaac dealey 954-776-0046
new epoch http://www.turnkey.to
lead architect, tapestry cms http://products.turnkey.to
tapestry api is opensource http://www.turnkey.to/tapi
certified advanced coldfusion 5 developer
http://www.macromedia.com/v1/handlers/index.cfm?ID=21816
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Behalf Of S. Isaac Dealey
> Sent: Friday, February 28, 2003 6:34 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Fusebox 3 question on fbx_fusebox_XXXX
>> Thanks for your response.
>> Not sure what IIRC means?
> if I remember correctly
>> The circuits file handles creating the
>> circuit-to-directory mapping structure.
>> The real heart is that fbx_Fusebox_XXX file-set. I
>> loathe to change that
>> behavior.
> Right, that's why I was saying you were probably going to
> feel like placing
> code to alter the attributes.fuseaction variable there. I
> was just saying
> that in order to change the attributes.fuseaction variable
> and have it then
> also affect the fusebox.fuseaction variable you'd have to
> do it higher up in
> the FB flow control architecture than say the fbx_settings
> files. That being
> the case, the only places where that can potentially be
> done are in the
> fbx_circuits.cfm or in the fbx_fusebox_xxx files which Hal
> and the rest of
> the FB authority recommend not changing (and which you say
> yourself you're
> loathe to change).
>> An observation about FB3: There is resonable
>> user-documentation, but no
>> analyst documentation. Thus some of the design intents
>> can
>> be lost. The
>> nice thing is I can easily change how it works, but the
>> danger is I don't
>> know why it was built that way.
> Yea, that's always a concern.
> I don't use FB for my own development -- I use the
> attributes trick so that
> I can call certain base templates as custom tags if it'll
> help, and I use an
> equivalent of the fuseaction variable and the fbx_switch
> that's more dynamic
> (actually just dynamic includes). Speaking of which --
> apparently a few
> people have run into problems with migrating FB2/3
> applications to CF MX as
> a result of the 64k method limitation of the underlying
> Java engine.
> Apparently when MX generates a java class for a new
> template, it puts
> everything in a single method, so if you've got a
> switch-case in the
> template it'll examine all those includes and include the
> contents of all
> those included files in the generated Java code. So even
> if your switch case
> statement only has 2 cases like <cfswitch
> expression="#fusebox.fuseaction#"><cfcase
> value="a"><cfinclude
> template="a.cfm"></cfcase><cfcase value="b"><cfinclude
> template="b"></cfcase></cfswitch> you could still exceed
> the 64k limit if
> the CF Server generates more than 64k of combined Java
> code from a.cfm and
> b.cfm (i.e. between them, not per file).
>> I have been using FB for CF and PHP for a while.
>> Generally
>> I am pleased with
>> the integration ease. Most of what I end up building
>> rarely needs that MVC
>> overhead so the hub-n-spoke fusebox ideas is OK.
>> I have posted this on the fusebox.org forums site, but I
>> usually have to
>> troubles asking the correct question the first time.
> I've never needed to ask them anything myself.
> s. isaac dealey 954-776-0046
> new epoch http://www.turnkey.to
> lead architect, tapestry cms http://products.turnkey.to
> tapestry api is opensource http://www.turnkey.to/tapi
> certified advanced coldfusion 5 developer
> http://www.macromedia.com/v1/handlers/index.cfm?ID=21816
> -----------------------------------------------
> To post, send email to [EMAIL PROTECTED]
> To unsubscribe:
> Send UNSUBSCRIBE to [EMAIL PROTECTED]
> To subscribe / unsubscribe: http://www.dfwcfug.org
> -----------------------------------------------
> To post, send email to [EMAIL PROTECTED]
> To unsubscribe:
> Send UNSUBSCRIBE to [EMAIL PROTECTED]
> To subscribe / unsubscribe: http://www.dfwcfug.org
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe:
Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
