Jeffry Houser said:
> I don't see much use beyond "A way to avoid sending
> parameters to custom tags." Unless I'm mistaken the
> only difference between the variables scope and the
> request scope is that variables in the request scope
> are available to custom tags.
Actually, I just thought I'd mention a use that I hadn't seen addressed so
far: making sure that something is done only once per request. For
instance, if I have a general-use custom tag that puts some JavaScript
helper functions in a page, but the tag could possibly be called many times
within the page or its custom tags or so on, I wouldn't want to output those
JavaScript functions more than once.
Specifically, I use it for a Date Picker popup for my HTML forms. I set
something like Reqest.DatePickerFunctionsSent=1 and then the tag is smart
enough to StructKeyExists() before it outputs the functions. This would
apply to both CFMODULE-based custom tags and CFINCLUDE-d templates.
I also use it for queries for navigational menus. We have a moderately
complex intranet with a hierarchical navigation system that is rights-based.
That is, everyone in the company sees a slightly different tree of
navigation options. The query to generate those navigation trees is fast,
but not instantaneous. In certain layouts of our intranet, the navigation
may be shown (in different forms) in up to 4 different places in a single
page. (Big and complete nav bar running down the left side, user's
most-used options in a DHTML layer behind that, and top and bottom
horizontal rows of the top-level items.) Obviously, we'd only need to run
the query once per request. Throw it in the Request scope and anything can
use it. We even ended up using it to eliminate some of our other
permissions checking, consolidating all of our rights requests into one
query that also produced navigation. ("This is everything on the site that
this user has access to, along with their rights for each object, and all of
the objects are arranged in this hierarchy.") The custom tags that would
then otherwise be running their own query, to see if they had rights to be
used, instead do a quick check through the cached query.
HTH,
-R
P.S. - Before you mention it, while I could probably get away with using
Session vars to hold the query, we actually find that it's easier to just
use Request, as the navigation items and rights change more often than you
would think. I had even built such a system where one person could change
another person's rights and it would mark their cached query as needing to
be refreshed, but it was so hopelessly complex an non-intuitive that it
would have been a nightmare for anyone else to maintain, no matter how much
documentation I had supplied. I'm not by any means saying it shouldn't be
done that way, just that it wasn't worth it to us. If our db server ever
gets to the point where it can't handle the strain, I can always go back to
the Session implementation. Until then, however, RAM prices are cheaper
than programmer hours.
-R
______________________________________________________________________
Dedicated Windows 2000 Server
PIII 800 / 256 MB RAM / 40 GB HD / 20 GB MO/XFER
Instant Activation � $99/Month � Free Setup
http://www.pennyhost.com/redirect.cfm?adcode=coldfusiona
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
