[thelist] CF: form. Url. Attributes. A better way?

[Jon Hall]

Actually, I believe that the general variables are more useful in the
request scope, and the rest are better specified as attributes to the custom
tag. Variables like #dsn# should always been request.dsn (unless is
application or session scope), it's just less typing.
Relying on the request scope in a custom tag  only makes the custom tag less
modular if you want to use the tag on another site. If this tag is only
going to used for your internal development, standardizing on the request
scope for all your projects is fine. We do it.

>what's more, a custom tag should not attempt to change the values
> of variables outside of the custom tag, especially those in the request
> scope, if at all possible.

Umm, Unless that is the whole purpose of the tag. There is no general rule,
do what works for the task at hand.

Back to the original question though, the question is a very broad one. The
best bet would be to stadardize on one scope or not rely on the scope at
all.

Since this seems to be getting into CF methodologies I'll post my general
methodology.

All forms submit to themselves.
At the top of each page test for the existence of the form variables
if an action needs to take place, set a standard mode variable to the action
that needs to take place
include your action page, some of my action pages have upwards of 20 custom
tags.
Perform action, and the action may be site specific. Custom tags don't just
exist for code reuse. They are real nice ways to easily navigate through
your code later. Relying on the request scope is fine in this case.
Then you can use cflocation to go to any other page of necessary, or just
come back to your original page with now updated data.
This way their is no chance of you being uncertain of what scope a variable
came from since you always control the scope before including your action
page.

jon

> be very careful and think long and hard before you consider using the
> request scope, especially with such generic variable names as "id".  if
> you're calling a custom tag or cfmodule and you need to make some data
> available to it, pass it in with an attribute.  the custom tag or cfmodule
> template should *never* assume what variables are available to it from the
> outside.  what's more, a custom tag should not attempt to change the
values
> of variables outside of the custom tag, especially those in the request
> scope, if at all possible.
>
> the problem (which sometimes seems like an advantage) with the request
scope
> is that it's a global scope meaning anything in that scope is available to
> *everything* from the beginning of the request, through the processing of
> all templates and custom tags, until the end of the request.  at first
this
> seems like a good thing.  however, using it within custom tags tends to
make
> them much less modular and much more dependent on certain variables being
> setup outside of the custom tag.
>
> good luck,
>
> .jeff