Well like I said and others will say the same thing, you just need to use
the same application name.
So if they have
<cfapplication name="myApplication" />
You use in Application.cfc
this.name = "myApplication";
or
<cfset this.name = "myApplication" />
I assume the application will run in the same server as theirs, which it
sounds like if they are asking you to include their application.cfm?
Indeed. I have literally been going back through old documentation
trying to remember how to use the old Application.cfm, it has been
that long.
Any idea where the "argument.targetPage" value comes from? I figured
instead of extending coldbox.system.Coldbox, I would need to use
createObject, that way I can use the reloadchecks() and
processColdBoxRequest() methods. I am just not sure where they are
getting the targetPage value from. I mean, it looks like it is just a
manipulation of the url.
K
targetPage comes from ColdFusion, when a request is started ColdFusion if
there is an Application.cfc will fire the event onRequestStart, or
onRequestEnd or onRequest in your Application.cfc and passes the name of
the page.
As for ColdBox if you download the full package it has examples of using
non inheritance.
So you can do this
component {
this.sessionManagement = true;
this.sessionTimeout = createTimeSpan(0,0,45,0);
this.setClientCookies = true;
// Mapping Imports
import coldbox.system.*;
}
Notice the import!! Also if you are going to use ColdBox that is not stored
in the webroot, then you will need to make sure you define the mapping for
it as well.
For example
this.mappings["/ColdBox"] = expandPath("../coldbox");
Will grab it from the next directory up, and set that as the mapping.
Andrew,
So here is what my cfm page looks like. It seems to be working
smashingly. Here is the irony, as long as I include their
application.cfm, the session persists no matter what I call my
application. There is something that is really disturbing about their
set up, but you have to work with the cards you are dealt.
<cfapplication name="QAR" clientmanagement="Yes"
sessionmanagement="Yes" />
<cfset cb = CreateObject("component", "coldbox.system.Coldbox") />
<!--- Must include lower level application file in order to persist
the global session variables --->
<cfinclude template="../../application.cfm">
<!--- Reload Checks --->
<cfset cb.reloadChecks()>
<!--- Process Request --->
<cfset cb.processColdBoxRequest()>
That is because you are defining the application name before the include,
so it is switching the name to theirs, which confirms that the session is
lost because you are not using the same name in the Application.cfc when
you use ColdBox's way of doing it.
Personally, I would go with the Application.cfc and just change the name of
the Application to what it should be.
You will also need to remember that any ORM is not able to be used in
Application.cfm, and there is also a good chance that some other aspects of
the framework might be broken. So rather than trying to fix a problem, that
you have ignored right from the start, and then having to deal with any
other issue that may pop up, I would just stick with the Application.cfc
and just ad the correct name.
Sorry to say this, but if you are not able to see that the session is being
held now, and why it is being held. And that the fact that the application
name is being over ridden when you include it, then I am bowing out of this
thread. I see no use in trying to get it to work with an Application.cfm
when all you had to do was change the application name, and this latest
post from you now confirms what we told you right from the word go.
After a few revelations, I felt it was only fair of me to let you guys
know the conclusion; especially since it includes an unexpected
behavior.
After much prodding, I was giving access to the code base only to find
out that the information I had been given was incorrect. Every
application was indeed sharing an application name, although all using
Application.cfm rather than .cfc. This allowed me to go back to the
original configuration of coldbox. Here were a couple of things that
were interesting.
1) coldbox.appName does not set this.name, at least not at first load.
Sure, it is obvious when you look at the code, not to mention it
probably wouldn't be possible. It does make me wonder what function
coldbox.appName performs. I would guess perhaps specifically making
coldbox aware of which application is which. Still doing some
investigation on that.
2) I found that if I changed this.name="x" and coldbox.appName="x", I
would run into that exact same issue with session overwriting. The
first page would have the "x" session (according to the debug
information), the second page (which was a form submit to get in to
the app from the welcome page) would have a totally different session
(also according to the debug information).
The good news is, with this.name and coldbox.appName different, it
works perfectly.
Well to be honest Keith I think it is a no brainer that it had to have an Application name, but you never know what some rouge developers might do.
As for your other questions.
No and neither should it either they are two different things. If you think about that problem for a minute you will realise that once ColdBox is running it can’t manipulate anything in the Application this scope.
if I recall right the appName defined in ColdBox is used for Enterpirse versions, or any version of ColdFusion that uses a context in the URL.
You are absolutely right. I think that was why it was such a
difficult issue for me to try and figure out. Here I was being told
that they definitely didn't share an application name, when that was
the only sensible way of doing it.
Them not being the same makes absolute sense, it was more that I
couldn't figure out what the use of the coldbox setting would be,
since it obviously could affect the "this" scope. The reasons you
mentioned make a lot of sense.
Thank you again Andrew, and everyone else who reached out, for helping
me not feel insane when I was getting misinformation.
Keith
Your welcome.