On Saturday, 16. March 2002 11:05, Matt Sergeant wrote:
> > If you download, check out the paramtest.xsl stylesheet in the example/
> > dir for a quick look at what this provides, or, you can look at it live
> > here. [2]
> >
> > Comments and suggested additions welcome. :-)
>
> Looks good. I'd consider renaming to XSLRequestParams and put it into
> AxKit's distribution.
But what happens to the default behaviour? Now that we have this fine module,
I think it is useless having just the query params as XSLT params. They won't
work out-of-the-box anyways (because of caching issues), so why not
a) make XSLRequestParams default behaviour, but be able to turn it off
or b) do not supply any XSL params at all, but require the user to choose
between XSLRequestParam and a manual param spec like my XSLParam module.
Moreover, the way it is now is not very intuitive (I didn't recognize the
query params were XSLT params until I already was fiddling with AxKit
internals).
One more thing: Param handling in Language.pm is ugly, IMHO. The only way to
get rid of the query params is via a sub ref in extra_xslt_params which
clears the param array.
What do you think about this approach:
- set up $r->pnotes('PARAMS') to hold a hash (why is it currently an array?)
of name, value pairs before any plugins are called
(The name is generic, implying it could apply to other transformation
processes as well, or usable in XSP. It is uppercase because that's
consistent with RequestNotes, should one happen to use that, and with
the session plugin.)
- make one of the param plugins the default behaviour, either the
XSLRequestParams or the manual param plugin, supply a 'old style'
compatibility plugin as well
- maybe even an own config directive for that? For example,
AxParamStyle auto|manual|compat|none
- Use that hash as source for params in place of the current cgi params.
Remove the customization via extra_xslt_params, since now plugins can
customize by accessing $r->pnotes('PARAMS') directly.
Result: Param handling in Language.pm is down to a one line statement.
Somewhere before the plugin calls a call to the appropriate param module must
be made. A compatibility plugin must be written. A config directive must be
added. Param plugins must be modified.
A lengthy explanation for a quite simple and easy modification...
--
CU
Joerg
PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]