I like coldFusion's request scope
I've gotten more and more into using the request scope for just about everything lately. Well, maybe not everything, but much more than I used to.
I usually start off with the following line of code in the application file:
<cfset StructAppend(request, form, "no")>
This allows all url and form variables to be added to the request scope. For many applications, this is a nice convenience. There have been plenty of times when I come across a client that has variables either un-scoped (bad, bad, bad), or they might get the variable from the form or url scope. This solves that problem.
Example: A form submits to a page that shows a report. The report expects many of the variables to come in the Form scope. However, they also have a download link that passes everything in the Url. Now, you can always have a few lines at the top of the page like this:
<cfset form.myVariableName = url.myVariableName>
</cfif>
But you would have to do this for every variable that could possibly be passed. With the request scope, you can set it in one place, and then reference it.
Another convenience item I like is adding the dsn name to the request scope as well. Again, in the application file.
The greatest benefit with this, is that now this one variable - "request.dsn" - can be used in CFCs, CFMODULE, Custom Tags, etc. I don't have to pass the name of the dsn variable in the arguments scope to a CFC, or attributes scope for a custom tag, as I have seen others do. Very nice.
Of course, there are always circumstances where you may want to have the dsn name passed in, but for the fast majority of circumstances, I gladly omit that variable and reference my request scope!
I often combine the form scope and the url scope into a single pseudo-scope, called input. I find this helps to consolidate the input parameters. I don't use the request scope much at all however. You make an interesting case. I find though, that using the request scope tempts me into breaking encapsulation.
Using the request scope in a custom tag allows the developer to reference a value that was not passed in. While this lessens the number of attributes that must be programmed, it also creates a dependency on a value coming from the request scope. This goes against the concept of encapsulation and makes the dependencies of the tag much less clear.
The same goes for a CFC. I prefer to pass the dsn into the init function when the cfc is created. This allows for others who use my code to understand what is needed to create a completely ready instance of the CFC and use it.
If the dsn is referenced through the request scope, or any other shared scope for that matter, it breaks encapsulation on a theoretical level, and requires that other developers read and analyze every line in the CFC to see what the dependencies are and how to create the component properly.
Do you find that you personally are using a lot of cfcs in your development?
DW