So the entire point is to make sure that you uniquely identify all
request scope vars. I don't see that as a problem, this has been
an issue for many systems over many operating systems for years.
Palm today has a registration page for assigning unique application
IDs to developers for the platform. It is a 4 character field.
OpenVMS had (has?) a registration system for generation of system
error messages for each application developement company.
At one company I worked for we had an internal document that described
the vars and what prefixes to use. Every application had a unique 3 or
4 letter prefix acronym.
Simply put, we always prefixed all global vars with an identifier, such
as a company nickname or nick name of the application.
So, if you develop tags for others, or even what MIGHT be for others,
always prefix your request scope vars with something like your domain
name or even company name. If you want something shorter, use X1234567,
where the 1-7 is your telephone number.
The previous thread really had me confused. I had thought I just heard
that the request scope vars were global across ALL applications / page
requests on the Server. That threw me for a loop.
Steve
At 06:51 PM 10/8/2000 -0400, Jeff Peters wrote:
>On 8 Oct 00, at 17:19, Kevin Bridges wrote:
>
>> Can someone expand on why this would be a bad idea? I converted the
>> formurl2attributes to formurl2request some time ago and have found it works
>> wonderfully ... it simplified things even further in coding. I run on a
>
>It's very easy to overlook the "badness" of the idea when you're coding your
>own applications. Because you have the overall view of the application,
you're
>more likely to keep you variables marching in formation, so to speak.
>
>If, however, your development expands to include other coders, you'll
begin to
>see where Nat's vehement objections come in. The attribute scope allows
you to
>use variables within a template, without worrying about either how the value
>was passed in, or what variables are named outside (either above or parallel
>to) the template's scope.
>
>As an example, if I call a template that returns a value to a variable
name I
>specify as an attribute in the call, I don't care what variable names are
used
>within the template I called. In fact, I don't care at all what's in the
>called template, as long as I can rely on it to return the result I expect.
>Similarly, whoever coded the called template doesn't care what I name my
>variables. If we start using the request scope, we MUST know whether our
>variable names will conflict with one another. This is why, from the
point of
>view of dev management, request scope is not a good replacement for
attribute
>scope.
>
>Now that I've made it clear as mud...<g>
>
>- Jeff
>
>==============================================================
>| Jeffrey S. Peters | "Specialization is for insects." |
>| [EMAIL PROTECTED] | - Lazarus Long |
>==============================================================
>---------------------------------------------------------------------------
---
>To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
>
--
Stephen Garrett
GPS
[EMAIL PROTECTED] (360) 896-2714
ICQ# 10776767
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
