Ben,
As far as I know, there is no facility in Commonspot's
caching mechanism
to allow for URL parameters. Commonspot's caching is based
on subsite
id, page id, and element id (at least by way of filenaming).
Query
strings are not part of the strategy.
So, there are a couple of options that I see, to get to
where you want
to go.
The first is do less with your render handlers. An initial
take on doing
this, not knowing anything about your code, would be to
actually create
a "view_by_week.cfm" page, and a
"view_by_month.cfm" page, etc... Taking
that element of dynamicality (okay, I made that up) out of
the picture.
Depending on what you're actually doing when you interpret
the ?view
parameter, that might help to speed things up. Analyze the
other
parameters to see if the same thing might apply to them.
Another thing you might be able to do... It sounds like
based on these
URL parameters, you might be running your own custom
queries. If so,
just adding the cachedWithin parameter to your CFQUERY
tag(s) would
speed things up. Particularly if you use CFQUERYPARAMs (and
you should).
Another option, again, depending on your code, is to use
Commonspot's
own invoke-dynamic-cfml module... You'll find it in the
/commonspot/utilities directory. If a lot of your
renderhandler is
display code, and that display code is part of what's
causing the
renderhandler to run slow, then run the renderhandler as
"cached", and
call invoke-dynamic-cfml to just run the code that you need
to be
dynamic. It might not speed up a *whole* lot (the slowness
is typically
in the model rather than the view), but it's an option.
And finally, if performance is really as bad as you say it
is, it might
be worth the effort to implement your OWN caching mechanism
for the
elements in question. We do this on a lot of our elements
(we have a
goal to make all our pages process in under 200ms... So we
actually do
quite a bit of private caching). The idea is fairly simple,
though your
implementations would probably vary depending on need.
Basically the
render handlers would run "uncached", and you'd
handle the caching
yourself.
Psuedo code:
<cfset sPrivateCacheDirectory = some directory somewhere
(like
/cache/private) >
<!--- assemble some meaningful filenaming structure
for your
private cache file like... --->
<cfset sPrivateCacheFilename =
"#request.page.id#-#attributes.view#-#attributes.year#
-#attributes.month
#-#attributes.day#">
<get the file timestamp of the private cache file - you
can use
CFFILE for this, or invoke java.io.File and use the
lastModified()
function, which tends to be a little faster>
<if a private cache file by that filename exists AND the
DateDiff between Now() and the timestamp of the private
cache file is LT
4 hours (arbitrary number, adjust for your needs) AND the
Commonspot
request.page.buildingCache flag is not true>
<CFINCLUDE
template="#sPrivateCacheDirectory#/#sPrivateCacheFilen
ame#.html">
<else>
<!--- create the private cache --->
<cfsavecontent variable="sPrivateCache">
<cfoutput>
<!--- run your usual render handler
display code here --->
</cfoutput>
</cfsavecontent>
<cffile action="write"
file="#sServerWebRoot#/#sPrivateCacheDirectory#/#sPriv
ateCacheFilename#.
html" output="#sPrivateCache#" ...>
<!--- and don't forget to output the cahce as well, or
nothing will appear of the page the first hit --->
<cfoutput>
#sPrivateCache#
</cfoutput>
</cfif>
Some of our private cache goes a step further, storing
sPrivateCache
into application scope, in addition to a file-based cache,
so playback
is almost instantaneous. You can also hook into on-approve
or
after-replication hooks to invalidate the private cache (and
even build
it back up if you wanted to).
-Carl Steinhilber
www.mentor.com
-----Original Message-----
From: commonspot-bounces chattyfig.figleaf.com
[mailto:commonspot-bounceschattyfig.figleaf.com] On
Behalf Of Benjamin
Chadwick
Sent: Tuesday, September 12, 2006 11:36 AM
To: Commonspot Mailing List
Subject: [Commonspot] Caching an element with url query
terms
We're trying to improve the efficiency of a page we've set
up that uses
several different custom render handlers. It's a calendar
with an
events list, controlled through URL parameters (e.g.
/our_page.cfm?view=week&day=10&month=11&year=200
6 will show all events
in the week of November 10th, and a calendar of the month of
November).
We seem to have the option of either letting CommonSpot
render the
elements on every refresh at its usual pace -- which is
leisurely with
only one user -- or we can let CommonSpot cache the rendered
elements.
But when it caches the rendered elements it ignores the
query variables,
so the page winds up the same no matter what is passed in
the URL. In
other words we're stuck with an unusably slow page or a
page that
doesn't show what it's supposed to.
There should be a way to tie the rendered element's cache
to the query
terms on the page, but I couldn't find any info on this in
the docs. Or
is there some alternative I'm not thinking of?
Thanks,
Ben
--
Benjamin Chadwick
Technology Developer
Krate
43-40 34th Street, Floor 2
Long Island City, NY 11101
T 718.729.7552
F 718.228.6229
http://www.kratedesign.com
_______________________________________________
Commonspotchattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/commonspot
Brought to you by Fig Leaf Software
Premier Authorized Paperthin Consulting and Training
http://www.figleaf.com
http://training.figleaf.c
om
_______________________________________________
Commonspotchattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/commonspot
Brought to you by Fig Leaf Software
Premier Authorized Paperthin Consulting and Training
http://www.figleaf.com
http://training.figleaf.c
om
|