neat piece of code!
I need some advice:
BEFORE
-----------
Currently I have all the following TYPES of statements as follows:
(1)Circuit app fusebox: project
<cfform action="index.cfm?fuseaction=getInfo&#request.urltoken#"
method="post">
(2)Circuit app fusebox: self_assessment
<a href = "index.cfm?fuseaction=nextPage&#request.urltoken#"> <-- this
link is within one of the fuses
(3)Circuit app fusebox: self_assessment
<a href =
"#request.site.webroot#/self_assessment/index.cfm?fuseaction=selfAssessment&
#request.urltoken#">
(4)Circuit app fusebox: login
<cflocation url =
"#request.site.cfroot#/survey/login/index.cfm?fuseaction=loginForm&#request.
urltoken#>
Each of the above fuseboxes have an included ../app_global.cfm
Based on the email, the following code would be in the app_global.cfm:
<cfscript>
urlstring = cgi.path_info;
urlstring = reverse(urlstring);
urlstring = mid(urlstring, find("/", urlstring, 1), len(urlstring));
urlstring = reverse(urlstring);
request.pathinfo = urlstring;
</cfscript>
AFTER
-----------
Then for the above (1), (2) and (4), the changes would be as follows:
(1)Circuit app fusebox: project
<cfform
action="#request.pathinfo#index.cfm?fuseaction=getInfo&#request.urltoken#"
method="post">
(2)Circuit app fusebox: self_assessment
<a href =
"#request.pathinfo#index.cfm?fuseaction=nextPage&#request.urltoken#"> <--
this link is within one of the fuses
(4)Circuit app fusebox: login
<cflocation url =
"#request.pathinfo#index.cfm?fuseaction=loginForm&#request.urltoken#>
Questions
-----------
(1) Am I doing this correctly?
(2) How do I handle type (3)?
(3) OT - When do I use #request.site.cfroot# vs #request.site.webroot#? In
fact what is really assigned to these variables?
Kinley
-----Original Message-----
From: Mike Craig [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 06, 2001 5:02 AM
To: Fusebox
Subject: RE: structure question
oh you poor thing...programming AND having to type...what a tragedy. Ok
that was sarcastic and I don't mean to be cruel but this excuse for not
doing things the right way is really annoying to me as I have heard it many
times before, like let's use the variable name "a" when it stands for
"employeeid".
Personal issues aside (I am seeing a doctor for this problem), you should
not only create only one developer mapping for the root of your site as
#request.cfroot# AND a request variable to store the root for NON <cf> tags
(like <IMG> for example (called request.webroot by the way) but I have found
in several of my implementations, expecially the larger ones, that if I put
the following code:
urlstring = cgi.path_info;
urlstring = reverse(urlstring);
urlstring = mid(urlstring, find("/", urlstring, 1), len(urlstring));
urlstring = reverse(urlstring);
request.pathinfo = urlstring;
in my app_server or app_globals, which will be included in EVERY page
rendered, that I now have a generic variable that will ALWAYS point to where
my current circuit is. This has proven to be incredible helpful when
circuits have to move around or even just components of circuits. If
everything uses those three variables for directory pointers, you will never
have to worry about something not working just because you moved it.
Hope that offers a little insight.
Mike
-----Original Message-----
From: Douglas Brown [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 05, 2001 10:52 PM
To: Fusebox
Subject: structure question
I am creating a fusebox app with about 500 tables and about 20 different
folders, inside each sub-folder I have three other folders called (qry, dsp,
act) and my question is should I create a development mapping to all folders
that will hold templates or should I create a single mapping and use
#request.cfroot# in the index.cfm of each primary folder? I hate typing out
these long lines for the path to the folders using #request.cfroot# but if I
should do it, I will.
Thanks
Doug
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
