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
(Perhaps if you show us some code, this will be easier?)
LOL... I'm trying to set the SourceForge project but that CVS thing is pretty
overwhelming (and I thought I was a techie)... I could send a ZIP file...
Mmmm gonna post the ZIP here:
http://www.elefectoaxe.com.co/spaw/test.cfm
Click
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 well.
Jim Davis
These are all interesting remarks... This HTML editor is actually a CF port from an
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
Mauricio, this looks good, well done.
Thanks. Feel free to download. It's GNU GPL.
- mga
~|
Archives: http://www.houseoffusion.com/lists.cfm?link=t:4
Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4
Unsubscribe:
-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
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 config file without touching the CFCs.
How would you recommend this to be
Hi
We are developing this web-based HTML editor:
http://www.elefectoaxe.com.co/spaw/test.cfm
It uses CFCs and has several configuration variables (default language,
folder to place images into, etc) that are created in a couple of
configuration templates. Right now we handle these
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 scope. Are
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 = http://127.0.0.1
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
I have noticed that I can easily interchange the use of Application and
Request scoped variables. Both are easily accessible in custom tags and are
only exist for the current http request. So, what are good reasons to use
one instead of the other?
Jason
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
At 02:41 AM 1/7/01 -0500, Dave Watts wrote:
[...] There is NO performance penalty over properly used manual read locking.[...]
Are you sure there's no performance penalty? How much testing have you done
on this? Or, are you relying on a test done by someone else? How accurate
was that test?
Got
This is also the reason I have been ranting about Automatic
Read locking on this list lately. It works. There is NO
performance penalty over properly used manual read locking. I
am sure the ONLY reason it isn't at least the default if not
the ONLY choice is simply a legacy from older
Here's an interesting question:
We all know that setting global variables in the request scope is faster and
more thread-safe than using the Application scope, but does that remain true
as we scale?
Environment: 50 request variables are set in application.cfm (so they are
set every time a page
of
the Request scope is the way to go.
--Greg
- Original Message -
From: "Bryan Love" [EMAIL PROTECTED]
To: "CF-Talk" [EMAIL PROTECTED]
Sent: Tuesday, January 02, 2001 2:43 PM
Subject: Request VS Application scope
Here's an interesting question:
We all know that sett
ot; [EMAIL PROTECTED]
To: "CF-Talk" [EMAIL PROTECTED]
Sent: Tuesday, January 02, 2001 2:43 PM
Subject: Request VS Application scope
Here's an interesting question:
We all know that setting global variables in the request scope is faster
and
more thread-safe than using the Applica
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
39 matches
Mail list logo
