On Thursday, Sep 4, 2003, at 10:56 US/Pacific, Mauricio Giraldo wrote:
In general, when using CFCs I would recommend creating the variables
inside the CFCs as instance variables upon invocation rather than
look
out of the CFC to external data.
The idea is to have users generate their own
-Original Message-
From: Mauricio Giraldo [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 04, 2003 1:56 PM
To: CF-Talk
Subject: request vs application scope
In general, when using CFCs I would recommend creating the variables
inside the CFCs as instance variables upon
Mauricio, this looks good, well done.
Kind Regards - Mike Brunt
Original Message ---
Of course I'm new to all this myself so I may (and quite probably am)
completely off-base on the right way to do this in OO. Hopefully
somebody with some more experience will chime in as
-Original Message-
From: Mauricio Giraldo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2003 11:58 PM
To: CF-Talk
Subject: request vs application scope
Hi
We are developing this web-based HTML editor:
http://www.elefectoaxe.com.co/spaw/test.cfm
It uses CFCs and
Absolutely no problem... I do it regularly...
-Original Message-
From: Steve Vosloo [mailto:[EMAIL PROTECTED]]
Sent: 29 May 2001 08:34
To: CF-Talk
Subject: Request vs application scope
I am using the following line of code in my application.cfm
cfset request.HomeDir =
Thanks.
Can I put any data in there that I want to use across the site? And I don't
have to apply CFLOCKs do I?
-Original Message-
From: Daniel Lancelot [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 29, 2001 2:32 PM
To: CF-Talk
Subject: RE: Request vs application scope
Yes thats right.
-Original Message-
From: Steve Vosloo [mailto:[EMAIL PROTECTED]]
Sent: 29 May 2001 13:51
To: CF-Talk
Subject: RE: Request vs application scope
Thanks.
Can I put any data in there that I want to use across the site? And I don't
have to apply CFLOCKs do I
Brilliant! So what's the downside? The variables are not persistent across
pages are they?
-Original Message-
From: Daniel Lancelot [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 29, 2001 2:56 PM
To: CF-Talk
Subject: RE: Request vs application scope
Yes thats right
I am using the following line of code in my application.cfm
cfset request.HomeDir = http://127.0.0.1/work/ACME/may2001/website;
Then elsewhere in the site I refer all links and images to:
cfoutput#request.HomeDir#/cfoutput
Is this OK to do? I'm trying to avoid using the application
: Request vs application scope
Brilliant! So what's the downside? The variables are not persistent across
pages are they?
-Original Message-
From: Daniel Lancelot [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 29, 2001 2:56 PM
To: CF-Talk
Subject: RE: Request vs application scope
(maybe
100B)?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: 29 May 2001 15:07
To: CF-Talk
Subject: RE: Request vs application scope
That's the downside! Also, they are unique to each request, so memory
processor usage will increase by a set amount for each page
Brilliant! So what's the downside? The variables are not
persistent across pages are they?
Request variables aren't persistent across pages, as Session, Application
and Server variables are. However, you're using them in Application.cfm, so
they'll be available on every page. They'll simply
]]
Sent: 29 May 2001 15:37
To: CF-Talk
Subject: RE: Request vs application scope
But using request vars means the memory is released immediately the request
has finished...
I would agree if you are planning to store large/complex data (esp query
result sets etc) then its probably best to use app scope
: Tuesday, May 29, 2001 9:43 AM
|To: CF-Talk
|Subject: RE: Request vs application scope
|
|
|Brilliant! So what's the downside? The variables are not
|persistent across
|pages are they?
|
|
|
| -Original Message-
| From: Daniel Lancelot [mailto:[EMAIL PROTECTED]]
| Sent: Tuesday, May 29
Isn't it a bit illogical to use request scope for storing constants if they
can be overwritten? I understand that there is no sense in doing cfif
isdefined(request.myvar) as the variable will be destroyed no matter
what, so you have to always re-initialize it. Does that carry more or less
The primary advantage of using REQUEST scoped variables is the freedom from
locking everything, as with APPLICATION and SESSION variables.
Steve
-Original Message-
From: stas [mailto:[EMAIL PROTECTED]]
Sent: Sunday, April 29, 2001 4:05 PM
To: CF-Talk
Subject: Re: Request vs application
.
-Original Message-
From: stas [mailto:[EMAIL PROTECTED]]
Sent: Sunday, April 29, 2001 3:05 PM
To: CF-Talk
Subject: Re: Request vs application scope
Isn't it a bit illogical to use request scope for storing constants if they
can be overwritten? I understand that there is no sense in doing
Isn't it a bit illogical to use request scope for storing
constants if they can be overwritten?
Since CF doesn't provide anything directly analogous to a constant, it's as
close as you can get. Typically, when used as constants, request variables
are created in Application.cfm for each page
You also need to lock your application variables, which add some additional
overhead.
Todd
- Original Message -
From: "Andrew Tyrone" [EMAIL PROTECTED]
To: "CF-Talk" [EMAIL PROTECTED]
Sent: Thursday, April 19, 2001 6:17 PM
Subject: RE: Request vs. Application sco
ROTECTED]
Sent: Thursday, April 19, 2001 3:17 PM
Subject: RE: Request vs. Application scope
-Original Message-
From: Jason Lotz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 19, 2001 4:25 PM
To: CF-Talk
Subject: Request vs. Application scope
I have noticed that I can ea
]
-Original Message-
From: Jason Lotz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 19, 2001 4:39 PM
To: CF-Talk
Subject: Re: Request vs. Application scope
Andrew,
Thanks for the response. I completely understand what you are saying so I
To my understanding using automatic read locking degrades the performance of
a server greatly. Also, any performance degrade with using the Request
scope won't make too much of a noticable difference. This is only my
understanding, but I'm not positive. So as far as I am concerned the use of
But as a recent thread discussed, proper coding requires that you should always lock
every access to an Application variable, in which case automatic read locking on
Application scope variables does not degrade performance any more than manual read
locking of every read of an Application scope
ary 02, 2001 3:38 PM
Subject: Re: Request VS Application scope
But as a recent thread discussed, proper coding requires that you should
always lock every access to an Application variable, in which case automatic
read locking on Application scope variables does not degrade performance any
more than
: Re: Request VS Application scope
So it appears your choice is to properly lock access to shared variables
and take the slight performance hit
using either automatic locking or manual locking, or do not properly lock
access to shared variables and have
an unstable server
If I understand your
TED]]
Sent: Tuesday, January 02, 2001 4:21 PM
To: CF-Talk
Subject: Re: Request VS Application scope
So it appears your choice is to properly lock access to shared
variables
and take the slight performance hit
using either automatic locking or manual locking, or do not properly
lock
access
The reason why locking is visible to the developer is because it is much
more efficient if the person writing the code, who knows how the
application
should work, decides where to lock and more importantly what type of lock
to
use. If the ColdFusion server had to decide whether to use a
html
font size=3Here Here!!br
Finally someone seems to understand/agree with my frustration on this
point.br
br
The way Cold Fusion handles locking is just DUMB. It is ASKING for
application instability, which in the long run will ruin the reputation
of Cold Fusion as a web development
Here Here!!
Finally someone seems to understand/agree with my frustration on this point.
The way Cold Fusion handles locking is just DUMB. It is ASKING for application
instability, which in the long run will ruin the reputation of Cold Fusion as a web
development environment. It is especially
29 matches
Mail list logo
