Your post appears to be incomplete.

Right before that line, cfdump your application scope to see if the variable is there.

The problem might be that your application does not have a name.

johnny_perez_new wrote:

 

I did that I added a name to the application.cfm "<cfset this.name=testname>" and then put "<cfdump var="#application#">" before the include and the application name was there and I enabled robust debugging which said that the error is from the <include template="#application.basePath#master.cfm" /> is there any other method to include a relative link that might work..

Ensure the name of your application file starts with capital A. Also, let the cfapplication tag at least have the following attributes:

<cfapplication name="testname"

    sessionmanagement="Yes"

    sessiontimeout="#createTimeSpan(0,0,20,0)#"

    applicationtimeout="#createTimeSpan(1,0,0,0)#">

Ensure the name of your application file starts with capital A. Also, let the cfapplication tag at least have the following attributes:

 

<cfapplication name="testname"

    sessionmanagement="Yes"

    sessiontimeout="#createTimeSpan(0,0,20,0)#"

    applicationtimeout="#createTimeSpan(1,0,0,0)#">

I think your subsequent post is the one that's important, but just on this one: the only attribute one needs is the name.  Session activation is only needed if one needs sessions, and the timeouts are only needed if they vary from what's in CFAdmin already.

Strictly speaking even the name is not required, but it's bad form not to have one.

But it's the improper use of <cfapplication> as a nestable tag that's most likely the problem here.

--

Adam

Adam Cameron. wrote:

I think your subsequent post is the one that's important, but just on this one: the only attribute one needs is the name.  Session activation is only needed if one needs sessions, and the timeouts are only needed if they vary from what's in CFAdmin already.

 

Strictly speaking even the name is not required, but it's bad form not to have one.

All true. However, I was thinking of something else. As Johnny_Perez_New seems to be unfamilar with cfapplication, I wished to introduce the tag with its most commonly used attributes.

 

Your cfdump shows that application.basePath is not being set by your Application.cfm page.  It's just as well.  Your approach makes it possible for user A to set the variable, user B to change it, and then user A uses the wrong value.

That isn't the case here, Dan. Application.basePath is a CGI variable which, we may assume, cannot be changed by the user.

I see what Dan's on about.

Say a user hits /some/path/to/a/file.cfm, then application.basePath will be /some/path/to/a/.  Now a different user hits /some/path/to/a/different/file.cfm, the variable will be /some/path/to/a/different/.

This is not the sort of thing one wants setting on a request by request basis, which is what's gonna happen in Application.cfm

The variable should not:

a) be set via a request-centric setting such as a CGI-scoped variable

b) reset every request.

Surely the base path is known to the application code, so it should just be hard-coded?

I'd also recommend using Application.cfc over Application.cfm.  Whilst not specifically stated, Appliction.cfm is an obsolete approach to application / request management.

--

Adam

The code in question is a , and it's bring called every request.

--

Adam

Adam Cameron. wrote:

 

What I actually posted was this:

 

The code in question is a <cfset> in Application.cfm. The variable will be re-set every request. Application.cfm had no special application-centric properties (it's misnamed, it should be called OnRequestStart.cfm), so it doesn't matter about application timeouts: a <cfset> is a <cfset>, and it's [being] called every request.

I shouldn't have attempted to respond by email, I guess.

No problem: it was obvious something went wrong on the wire.

Thanks for pointing that out. I can now see the confusion arose from an omission on my part. By the time I wrote my last post, at least 2 recommendations had been made to the poster to switch to Application.cfc. (which I incidentally also strongly support). I therefore implicitly had Application.cfc and onApplicationStart in mind. The assumption is therefore that the application variable is initialized in onApplicationStart.

Otherwise my point about a restart becomes absurd, to say the least. I hope this explanation clarifies that passage. Even if you switch to Application.cfc, initializing the application variable in onApplicationStart, you still won't escape the dilemma of one user setting a path for others.