This proposal is based on the earlier email about PSP optimziation and
caching. This proposal explains the requirement for rendering policy.
The proposal is to add a new page directive called renderPolicy:
<%@ page renderPolicy = "dynamic" %>
<%@ page renderPolicy = "dynamic-params([query-param-list])" %>
<%@ page renderPolicy = "dynamic-config([config-param-list])" %>
<%@ page renderPolicy = "static" %>
The behavior of the directive is as follows:
dynamic:
This is the default, it is the same as PSP currently operates:
PSP pages are 'run' to render the HTML output. Included PSP's are
placed in the including PSP verbatim at compile time.
dynamic-params:
The request handler uses the values of the given query/post paramers.
For each unique combination of the parameters, a cache file name is
computed. the PSP in quesiton is rendered and the result stored in
the cache file. That cache file is served up at request time for PSP
pages that are cached in this manner. For included PSPs, the cached
content is included into the enveloping dynamic page dynamicly by
including the rendered cache file.
For related approaches, see memoization and the Memoize CPAN module.
Actualy this could be implemented in the request handler, but it might
be better implemented as code that is injected into the compiled page
by the PSP compler that does the dynamic checking.
dynamic-config:
This works as dynamic-params, the only difference being that the
dependency is on configuration file paramters instead of request-time
parameters.
static:
The PSP code is rendered and cached at compile time. At request time
the cached rendering is served. For includes, the static cached
rendering is included into the enveloping dynamic page at compile time.
The complation should support multiple instances of: dynamic-params and
dynamic-config. The specified parameter names should 'stack up' and be
unifieid, then the combined list used to determine which cache-file needs
to be accessed.
The use of this directive will undoubtedly complicate the development
and testing process while building sites with Pas, but it does allow
for very fine-grained control of content rendering policy.
The initial intention of this directive is to allow for control and
optimization - page rendering times can be reduced by specifying
caching policies in this manner.
A secondary implication of this is that developers can now virtualize
some of the page rendering and not worry about the performance
implicaitons. An example might be the choice of color schemes to
use in a cascading style sheet - mark the style sheet as 'static',
and have the color chocies be dynamic based on configuration file
paramters. Then the .css file is rendered once, but you only need 1
.css file per configuration (say you're supporting mulitple websites
on the same codebase) each with thier own branding.
An importiant issue here is that if we support multiple rounds of cache
control inspection and staic-rendering during compliation of the main
(or parent) PSP, then we can use this feature like a macro system. A
PSP could be marked as 'static', and generate PSP code that will be run
at request time (this could be arbitrarily nested, which is something
we need to both support and watch out for). The idea here is to write
the static PSP in a very abstracted or refactored manner and have it
generate the code that needs to be run at request time. This can be
viewed similarly to the macro systems supported LISP or Scheme.
The second implication of this feature is potentialy the most powerful
for allowing site developers higher and higher levels of abstraction
for developing their websites.
Commentary and rebuttal is encouraged.
Kyle
--
------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
-- Christmas Humphreys
mo...@vo... http://www.voicenet.com/~mortis
------------------------------------------------------------------------------
|
