But why?
John, *you* devised the fusebox API variables. Isn't this exactly the situation for
which #fusebox.rootpath# is
intended, ie for calling common pieces of code from whatever circuit you happen to be
in at the time?
Tom, the decision about whether a certain piece of code should be a fuse or a
fuseaction should not be dependent on
whether it is going to be used by multiple circuits. If it's a fuse, then leave it as
a fuse, and use <cfinclude> to
call it. It simple, it's quick, it's efficient, it's completely standard, it's common
practice.
If it's a fuseaction, the put it anywhere you like, and use <cfmodule> or FuseQ if you
find that easier.
FuseQ may, as advertised, solve a whole lot of problems that Fusebox developers
commonly face. But this situation is
not a problem, it is a perfectly well-understood and well-handled situation that
standard FB3 (as written by John et al)
copes with brilliantly.
The rush by FB3's authors to marginalise the basic FB3 core is a little puzzling.
Slow down, slow down.
LeeBB
----- Original Message -----
From: John Quarto-vonTivadar <[EMAIL PROTECTED]>
> Hi Tom,
>
> with FuseQ, this would be easy. Put you query(s) in separate circuit --
> obviously is you use a MVC design pattern you would be doing this anyway --
> and then if you were going to display some of the info in the query:
>
> <cfset AddToQ('myquerycircuit.myQuery')>
> <cfset AddToQ('myDSPcircuit.myDSP')>
>
> 2 lines of code, no CFMODULE overhead.
>
> If you're not using MVC, you're still ok with using a separate circuit for
> queries without having to use CFMODULE to get to them, here's a variation if
> you were using the query and then going to do something with the query in a
> few ACT fuses:
>
> <cfset AddToQ('myquerycircuit.myQuery')>
> <cfset AddToQ('#fusebox.thiscircuit#.myACT1')>
> <cfset AddToQ('#fusebox.thiscircuit#.myACT2')>
>
>
> Note that in version 3.00.20 of the Techspedition core you'll be able to put
> your queries circuit out of the web root altogether for an additional level
> of security
>
> ----- Original Message -----
> From: "Tom Schreck" <[EMAIL PROTECTED]>
>
> I've tried using cfmodule to call a query from a centralized location,
> but my query was picking up Attribute values that are present at the
> time of the call to the cfmodule, but were not passed into the cfmodule.
> Here's a snippet on how I structure my queries:
>
>
> <cfparam name="Attribute.numVariableID" default="0">
>
>
> <cfquery>
> SELECT * from TableName
> WHERE 0=0
> <cfif Attribute.numVariableID GT 0>
> AND TableName.numVariableID = #
> Attribute.numVariableID #
> </cfif>
>
> </cfquery>
>
> So, I'm CFMODULE-ing a call for this query and not passing numVariableID
> to the query call. The variable is present at the time of the cfmodule
> call, but not being passed. Somehow the cfmodule recognizes the
> variable and includes it in the query execution. The query is stored in
> a different circuit all together. To get around this, I have to place
> the query in each circuit. The kicker is I can still use cfmodule to
> call the query, but since it's in the same circuit there's no problem.
> I run into problems when I cfmodule to a different circuit. Any
> help/suggestions on this would be appreciated.
>
> Does anyone have any FuseQ examples? I'm looking at how to best manage
> have my query files in 1 location versus copying them into each circuit.
>
>
>
> Thanks -
>
> Tom Schreck
> 817-252-4900
> [EMAIL PROTECTED]
>
> I have not failed. I've found 10,000 ways that won't work.
>
> - Thomas Edison
>
>
>
>
>
>
==^================================================================
This email was sent to: [email protected]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]
T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================
