>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: htt
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
>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
o
>(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
> -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
> >insi
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 th
>>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
> -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
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 configuration
> 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 pa
.
-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
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
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 as the variable will be destroyed no matter
what, so you have to always re-initialize it. Does that carry more or less
penalty than checking for existence o
ED]]
|Sent: 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]]
|&g
Message-
From: Daniel Lancelot [mailto:[EMAIL PROTECTED]]
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 (
> 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
(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
--
From: Steve Vosloo [mailto:[EMAIL PROTECTED]]
Sent: 29 May 2001 14:43
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:[E
> I am using the following line of code in my application.cfm
>
> http://127.0.0.1/work/ACME/may2001/website";>
>
> Then elsewhere in the site I refer all links and images to:
>
> #request.HomeDir#
>
> Is this OK to do? I'm trying to avoid using the application
> scope. Are there any known of
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.
-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
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
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
http://127.0.0.1/work/ACME/may2001
I am using the following line of code in my application.cfm
http://127.0.0.1/work/ACME/may2001/website";>
Then elsewhere in the site I refer all links and images to:
#request.HomeDir#
Is this OK to do? I'm trying to avoid using the application scope. Are there
any known of issues with this met
]
-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
lt;[EMAIL PROTECTED]>
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
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: R
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
~~
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?
> 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 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 b
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 ba
> 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 Re
CTED]>
Sent: Tuesday, January 02, 2001 4:35 PM
Subject: RE: Request VS Application scope
> One of the points to using application variables is the
> fact that they are persistent. The entire scope is a
> shared memory scope which means that your variables persist
> which means you d
;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 to shared variables
PROTECTED]>
Sent: Tuesday, January 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
l 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 al
the use 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 interes
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
39 matches
Mail list logo
