forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Williams" <william...@gmail.com>
Subject Re: HEADSUP {defaults:*} and {project:*} are not supported anymore and {forrest:*} needs updating (was Re: svn commit: r431247)
Date Mon, 14 Aug 2006 12:43:04 GMT
On 8/13/06, Thorsten Scherler <thorsten@apache.org> wrote:
> El dom, 13-08-2006 a las 23:54 +0200, Thorsten Scherler escribió:
> > El dom, 13-08-2006 a las 21:41 +0000, thorsten@apache.org escribió:
> > > Author: thorsten
> > > Date: Sun Aug 13 14:41:37 2006
> > > New Revision: 431247
> > >
> > > URL: http://svn.apache.org/viewvc?rev=431247&view=rev
> > > Log:
> > > FOR-920 Merging the defaults and project modules to the new properties module.
You can use it like {properties:forrest.home}, please refer to the update documentation how
to change your {defaults:*} {project:*} and {forrest:*}.
> >
> >       <p> In all custom code you have, </p>
> >
> >       <ul>
> >         <li>find:
> >           <code>{defaults:</code> and replace with
> >           <code>{properties:forrest.</code></li>
> >         <li>find:
> >           <code>{forrest:</code> and replace with
> >           <code>{forrest:forrest.</code> or
> >           <code>{properties:forrest.</code> (if you do not need the
> >           ChainMetaModule)</li>
> >         <li>find:
> >           <code>{project:</code> and replace with
> >           <code>{properties:</code></li>
> >       </ul>
>
> Actually a thought a lot about the {forrest*} module.
>
> This is done by the ChainMetaModule, which is a kind of fallback module
> lookup.
>
> <input-module name="request-param"/>
> <input-module name="request-attr"/>
> <input-module name="session-attr"/>
> <input-module name="properties"/>
>
> Imagine
> <map:match pattern="test">
> ...
> <map:transform src="foo.xsl">
>  <map:parameter name="forrest" value="{forrest:forrest.i18n}" />
>  <map:parameter name="properties" value="{properties:forrest.i18n}" />
> </map:transform>
> ...
> </map:match>
>
> With foo.xsl having:
>   <xsl:param name="forrest"/>
>   <xsl:param name="properties"/>
>   <xsl:template match="/">
>     forrest: <xsl:value-of select="$forrest"/>; properties:
> <xsl:value-of
> select="$properties"/>;
>   </xsl:template>
>
> requesting http://localhost:8888/test will return (default)
> forrest: false; properties: false;
>
> requesting http://localhost:8888/test?forrest.i18n=true will return
> (default)
> forrest: true; properties: false;
>
> This is because <input-module name="request-param"/> will be tested
> before <input-module name="properties"/>. Meaning all the references in
> our code that read {forrest:*} can be overridden by above listed
> modules.
>
> We may want to review the usage of {forrest:*} whether it should be
> overridden. Further we may want to use the {forrest:*} module in other
> parts of our code where we right now use {projects:*}.

I haven't kept up with the new properties mechanism discussion and so
I don't know how to turn this on to test it right now but what you're
describing here sounds pretty serious.  You're saying that request
params can override any property?

E.g. Change forrest.locationmap=@context.home@/locationmap.xml to
forrest.locationmap=http://badsite.com/locationmap.xml?

Maybe since I've not followed it closely I'm misunderstanding what you
describe.  I'll try to play with this new properties stuff soon.
--tim

Mime
View raw message