Man, I'm reading this thread and wondering why Jacob got som mad over nothing so
quickly!!! Did your dog die or something man? Take it easy man, nobody's here to fight
with each other. We're just trying to solve problems and help each other out, right?
Ferg
-----Original Message-----
From: Dan Blackman [mailto:[EMAIL PROTECTED]
Sent: Fri 9/19/2003 8:09 AM
To: [EMAIL PROTECTED]
Cc:
Subject: RE: Since its so quiet lately . . .
Jacob,
My biggest concern with your idea of "we don't work together so it's ok"
is this...
Let's just say you you get fired or go on vacation tomorrow. Your
company has to hire someone or someone has to maintain your code while
your out. If you are not using a standard or best practice to "Scope"
your variables then the person maintaining your code has to weed through
it and figure out what variables are what. If you don't scope your
variables it makes it harder to figure out where your variables are
coming from.
In my opinion, do what you want but hopefully I never have to go through
the pain of maintaining code that doesn't use best practices.
As for converting Form and URL variables, I convert them to the
"request" scope. That way I only have mess with a single scope when
using form and URL variables.
Cheers.
Dan
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jacob Cameron
Sent: Thursday, September 18, 2003 6:27 PM
To: [EMAIL PROTECTED]
Subject: RE: Since its so quiet lately . . .
As I said earlier today when I was talking to someone, I won't
use any names:) Sometimes you want to leave scope off of form and URL
mainly for their use. If they are referring to my code, they will
notice that there is always scoping used on CGI, Cookie, session and a
lot of other variables. Do I normally avoid them, yes when writing form
validation code so I don't have to type as much. If I would do
something as backwards as looping through an entire scope to reset one
scope to another and claim it to be faster, who could possibly think
that finding a work around to try and make your statement true would
possibly be logical?
I didn't say there was anything wrong with scoping, simply that
I don't do it on form and URL normally unless I am doing it for security
reasons.
In my mind, scoping is not a must. A knowledge of its existence
in the world sure, but if I had my way. Everyone would start learning
to code with ANSI C so they learn about scoping from that as I did.
And as many of you know, I also believe that if you say that you
should 'always' do something in code, then you are very narrow minded.
Do you think allowing none scoped variables in CF and ASP was an
accident? A bug? Or are you just smarter than the creators of these
scripting languages?
Also, in the past I have created sites that have received over 1
million hits in one hour and currently work on a site that receives over
2 million hits a day. You work on sites that get 1000 hits a day if
they are luck, more like 1000 a month. In my mind, worrying about this
kind of stuff is a waste of your time an your employers. Code anyway
you want. I code my way, that I know works and have testing in live
environments, not looping on beta code. If you want to code your way
that is fine, we don't even work together.
I cannot see the difference in load times from scoping or not
scoping url or form variables, so you are right because you think you
are? As you said this afternoon, you can loop through it 1 million times
and see a difference. If you get 1 million hits in one second or less
to a website you created, you will run out of threads before a single
web server will be able to serve it an everyone will be waiting in line
anyway. In talking
about speed, there is a lot more involved than scoping a variable. Do
any
of the sites you have created or maintain get that many hits? Are they
on a single server or on multiple. Mine is on a single server running
CF 5.0.
Jacob
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of S.Isaac Dealey
Sent: Thursday, September 18, 2003 5:55 PM
To: [EMAIL PROTECTED]
Subject: Re: Since its so quiet lately . . .
I was pretty slack about scoping variables when I first started working
with ColdFusion and for a while I tried to leave form and url variables
unscoped intentionally, although I've given up that habbit. I like to
copy all my form and url variables into an attributes structure in the
application.cfm which allows me to use base templates as custom tags if
the need arises and it's only 3 short, sweet lines of code. (It's one of
the nicer tricks from
Fusebox) If you use New Atlanta's BlueDragon server it's only 2 lines of
code because BlueDragon automatically combines the form and url
variables, so referencing form[var] is the same as referencing url[var].
I've mostly gotten out of the habbit of unscoped variables, and try even
with the variables scope to scope them because sometimes when you don't
scope them during a set statement they don't actually get into the
variables scope, although I don't know how or why they don't. If I need
a temp variable quickly for a loop or the like, I'll frequently use a
single character variable like x or i unscoped, only if I know that I've
set it and am making all references to it in the same template. And of
course, if it's in a function or a CFC method, I always make sure to use
<var> to declare the same single-character variables just in case.
Is scoping one of the first things a cf developer should learn? Maybe. I
think so. I know the question of scoping has sparked minor flame wars on
the cf-talk list. Not by any means like the flame wars sparked by the
issue of locking, but they've happened.
s. isaac dealey 972-490-6624
team macromedia volunteer
http://www.macromedia.com/go/team
chief architect, tapestry cms http://products.turnkey.to
onTap is open source http://www.turnkey.to/ontap
> Thought I would spark up a quick discussion.
> I was discussing a few things with a coder (no names), and I raised
> the subject of scoping variables.
> I am a real stickler when it comes to scoping variables. Other than
> obvious performance gain, and not having the issue of values bleeding
> from one scope into another - scoping simply makes code much easier to
> read.
> Looking at the variable #customer# tells you there is a variable named
> customer. Looking at the variable #form.customer# or
> #qInvoice.customer# tells you where the value came from and some
> insight on how it is going to be used, why, etc... (Especially when
> you deal with more than one page per
> request)
> I do on the other hand leave local scoped variables alone (the
> variables.[name] scope) - Which I think is standard practice, and
> there is no ambiguity when only one scope follows such a convention.
> I was curious if anyone else had a differing view of scoping. Perhaps
> (though I highly doubt) someone can give me an example of when leaving
> off the scope of a variable name has an actual advantage.
> The only idea that was half valid was using either form/url scope.
> This of course can be solved by coping one scope into the other and
> can be done in a few lines, so in the end, I don't think it's much of
> a valid point at all.
> Am I alone in thinking scoping variables is an absolute must, and
> pretty much day one stuff?
> Best Regards,
> Nate Nielsen
> [EMAIL PROTECTED]
> -----------------------------------------------
> To post, send email to [EMAIL PROTECTED] To unsubscribe:
> Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe /
> unsubscribe: http://www.dfwcfug.org
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe:
Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe:
Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe:
Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
N�h�� �צj)m�X����q������칻 �&�I��PԔ �
-�X������-u� ~�(����r��{�����r��zm����_���
