You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Thorsten Scherler <th...@apache.org> on 2006/08/13 23:54:21 UTC
HEADSUP {defaults:*} and {project:*} are not supported anymore and
{forrest:*} needs updating (was Re: svn commit: r431247)
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>
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: HEADSUP {defaults:*} and {project:*} are not supported anymore
and {forrest:*} needs updating (was Re: svn commit: r431247)
Posted by Thorsten Scherler <th...@apache.org>.
El lun, 14-08-2006 a las 08:43 -0400, Tim Williams escribió:
...
> 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?
Yes, but this is nothing new, nor is it in direct relations to the "new"
properties system.
Like Ross says there is not much to it, it turns your forrest.properties
into a xml based grammar and calls it forrest.properties.xml. That is
basically it. It works by just adding forrest.properties.xml to your
project.
If you do
svn praise main/webapp/WEB-INF/xconf/forrest-core.xconf you can find
that the ChainMetaModule was added with the initial revision of the
file. http://svn.apache.org/viewvc?view=rev&revision=125178
>
> E.g. Change forrest.locationmap=@context.home@/locationmap.xml to
> forrest.locationmap=http://badsite.com/locationmap.xml?
Yes via the modules we define in our xconf.
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/modules/input/ChainMetaModule.html
"This modules allows to "chain" several other modules. If a module
returns "null" as attribute value, the next module in the chain is
queried until either a value can be obtained or the end of the chain is
reached.
A typical example would be to "chain" request parameters, session
attributes, and constants in this order. This way, an application could
have a default skin that could be overridden by a user in her/his
profile stored in the session. In addition, the user could request a
different skin through passing a request parameter."
Meaning all {forrest:*} are chained like described above, all
{properties:*} (merge of defaults and project) not.
IMO it is very nice to use {forrest:*} in some parts of the code (like
described in the comment of the ChainMetaModule), but maybe in others we
would not like it too much.
Given your example above, why should we not want this? Imagine you can
really rapidly test new stuff.
> Maybe since I've not followed it closely I'm misunderstanding what you
> describe.
jeje, you are, like always, spot on. I think you understood very well.
You can see by adding the example code I posted before to any project
sitemap. You do not have to have a forrest.properties.xml, it always
have been like this before.
> I'll try to play with this new properties stuff soon.
The new inputModule plugin may give you some starting point as well
regarding properties from input modules.
salu2
> --tim
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: HEADSUP {defaults:*} and {project:*} are not supported anymore
and {forrest:*} needs updating (was Re: svn commit: r431247)
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> 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 don't need to "turn it on", just create a forrest.properties.xml
file and it will be used. Take a look at the projectInfo plugin for
examples of it in action.
Ross
Re: HEADSUP {defaults:*} and {project:*} are not supported anymore and {forrest:*} needs updating (was Re: svn commit: r431247)
Posted by Tim Williams <wi...@gmail.com>.
On 8/13/06, Thorsten Scherler <th...@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
Re: HEADSUP {defaults:*} and {project:*} are not supported anymore
and {forrest:*} needs updating (was Re: svn commit: r431247)
Posted by Thorsten Scherler <th...@apache.org>.
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:*}.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)