If I define a datasource variable in the application.cfm file in my webroot
shouldn't that variable be available to a cfc inside my webroot/components/
directory?
in webroot /application.cfm
CFSET datasource = database_01
in webroot/components/some.cfc
!--- CFC forLa Dolce/Sting contest - ---
This is not an attempt to promote my work but I just posted an article about
this a couple of days ago that I think you would benefit from.
http://www.danvega.org/blog/index.cfm/2007/2/19/Avoid-Global-Data
Dan Vega
http://www.danvega.org/blog/
On 2/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED]
cfquery datasource=datasource name=Expedition
SELECT ID
FROM tbl_Ecotourism
/cfquery
You might want to try this
In the application file try this:
CFSET request.datasource = database_01
In the cfc try this:
cfquery datasource=#request.datasource# name=Expedition
You did not
Great article. I wrap everything, almost everything, in functions and i have
consistently found myself locked in. I wish I would have read this some time
ago.
Take this advise seriously, especially if your application architecture uses
this type of structure often.
-- Original
The artcile still does not address what I think is the root of the question
though.
Are application variables availble inside a component (cfc) initiated within
that application root?
-- Original Message --
From: Dan Vega [EMAIL PROTECTED]
Reply-To:
Yes they are available, however they do need to be in the Application
scope, the initial post was just creating global variables which are
not available to the CFC rather than Application variables. Similarly
as someone has pointed out, the use of the variable was not surrounded
with hashes so
what about request scoped variables? Are they available inside components?
-- Original Message --
From: JediHomer [EMAIL PROTECTED]
Reply-To: cf-talk@houseoffusion.com
Date: Wed, 21 Feb 2007 15:13:28 +
Yes they are available, however they do need to
As far as I know these are also available, within theory you should be
able to access Application, Session, Request and Client scopes
directly, whether this is a good idea or not isn't my call ;)
HTH
On 21/02/07, Dwayne Cole [EMAIL PROTECTED] wrote:
what about request scoped variables? Are
Not to Hijack but I always do this
// instantiate Image CFC
imgObject = CreateObject(component, model.image).init(dsn);
cffunction name=init returntype=user access=public output=false
cfargument name=dsn type=string required=yes /
cfset variables.dsn = arguments.dsn /
cfreturn this /
Eric if I was not comitted, I would use your approach. It doesn't cost much and
i think it's just alot easier to back out of.
However, everything depends of the scope and the size of your project. My
son's toy boat works fine in the bath tub but in the open ocean, we might have
a few
Passing the dsn to the CFC in the create object?? Is this correct or
should
I change my ways?
I think it depends on your requirements and personal taste. I have done
exactly the same thing, but now I also need to pass not just the DSN but
also the database I'm currently working on. I chose
On 2/21/07, Richard Kroll [EMAIL PROTECTED] wrote:
Passing the dsn to the CFC in the create object?? Is this correct or
should
I change my ways?
Sorta off topic, but this is one area where ColdSpring is pretty awesome.
That's pretty much the only way I'm using CS right now-- Haven't even
Sorta off topic, but this is one area where ColdSpring is pretty
awesome.
That's pretty much the only way I'm using CS right now-- Haven't even
scratched the surface of Advice, which is just freaking cool.
I agree completely!
Rich Kroll
13 matches
Mail list logo
