You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Marc Portier <mp...@outerthought.org> on 2005/10/24 09:21:59 UTC
treeprocessor doesn't resolve variables in all attributes of sitemap
nodes
Hi there,
just found out that
<map:serialize status-code="{statusCode}" />
kept giving me a statuscode 200 no matter what the value of statusCode was.
as it turns out the SerializeNodeBuilder will in it's buildNode do:
> this.node = new SerializeNode(
> type,
> VariableResolverFactory.getResolver(config.getAttribute("src", null), this.manager),
> VariableResolverFactory.getResolver(config.getAttribute("mime-type", null), this.manager),
> config.getAttributeAsInteger("status-code", -1)
> );
which I read as: @src and @mime-type can but @status-code can-not be
resolved from variables
from an end-user POV this difference in handling is quite arbitrary
(meaning: if there are good considerations for this we should document
them well)
other examples of non-resolvable attributes:
> ./ActionSetNodeBuilder.java: "name"
>
> ./ActNodeBuilder.java: "set"
> ./ActNodeBuilder.java: "name"
> ./ActNodeBuilder.java: "src"
>
> ./CallNodeBuilder.java: "resource"
> ./CallNodeBuilder.java: "function"
> ./CallNodeBuilder.java: "continuation"
>
> ./HandleErrorsNodeBuilder.java: "type"
> ./HandleErrorsNodeBuilder.java: "when"
>
> ./FlowNodeBuilder.java: "language"
>
> ./MatchNodeBuilder.java: "pattern"
> ./MatchNodeBuilder.java: "name"
>
> ./MountNodeBuilder.java: "check-reload"
> ./MountNodeBuilder.java: "pass-through"
>
> ./PipelineNodeBuilder.java: "internal-only"
>
> ./RedirectToNodeBuilder.java: "resource"
> ./RedirectToNodeBuilder.java: "target"
> ./RedirectToNodeBuilder.java: "session"
> ./RedirectToNodeBuilder.java: "global"
> ./RedirectToNodeBuilder.java: "permanent"
>
> ./ReadNodeBuilder.java: "mime-type"
> ./ReadNodeBuilder.java: "status-code"
>
> ./SerializeNodeBuilder.java: "mime-type"
> ./SerializeNodeBuilder.java: "status-code"
>
> ./ScriptNodeBuilder.java: "src"
>
> ./SitemapLanguage.java: "logger"
> ./SitemapLanguage.java: "role"
> ./SitemapLanguage.java: "class"
>
> ./ViewNodeBuilder.java: "from-label"
> ./ViewNodeBuilder.java: "from-position"
# based on the naieve lookup through
$ cd src/java/org/apache/cocoon/components/treeprocessor/sitemap/;
$ find -type f |xargs grep 'config\.get' | grep -v '\.svn' | grep -v
VariableResolverFactory > ~/UnresolvedSitemapAttributes.txt
anyone any opinion on these?
maybe it makes sense to look at these with our "rule of least
surprise"-glasses on?
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: treeprocessor doesn't resolve variables in all attributes of
sitemap nodes
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>
>>>Yes, I think we should go through all these attributes and see/vote
>>>which ones can be made dynamic.
>>
>>
>>IIRC, this vote was already done at Cocoon 2.0 times. Substitution for component
>>types etc was prohibited on the basis that it makes it easier to implement
>>"dynamic pipelines".
>>
>
> Yeah, I know - and that's absolutely ok for component types. But what
> about mime-type,
> or the some others Marc listed?
I think following attributes can be subject to substitution:
status-code, mime-type on serialize and read
src on act
session, global, permanent on redirect-to
and probably
pattern on match
as well.
Vadim
Re: treeprocessor doesn't resolve variables in all attributes of
sitemap nodes
Posted by Carsten Ziegeler <cz...@apache.org>.
Vadim Gritsenko wrote:
>>Yes, I think we should go through all these attributes and see/vote
>>which ones can be made dynamic.
>
>
> IIRC, this vote was already done at Cocoon 2.0 times. Substitution for component
> types etc was prohibited on the basis that it makes it easier to implement
> "dynamic pipelines".
>
Yeah, I know - and that's absolutely ok for component types. But what
about mime-type,
or the some others Marc listed?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: treeprocessor doesn't resolve variables in all attributes of
sitemap nodes
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
> Marc Portier wrote:
>
>><SNIP/>
>>
>>anyone any opinion on these?
>>
>>maybe it makes sense to look at these with our "rule of least
>>surprise"-glasses on?
>
> Yes, I think we should go through all these attributes and see/vote
> which ones can be made dynamic.
IIRC, this vote was already done at Cocoon 2.0 times. Substitution for component
types etc was prohibited on the basis that it makes it easier to implement
"dynamic pipelines".
Vadim
Re: treeprocessor doesn't resolve variables in all attributes of
sitemap nodes
Posted by Marc Portier <mp...@outerthought.org>.
Carsten Ziegeler wrote:
> Marc Portier wrote:
>
<SNIP/>
>>
>>>./SerializeNodeBuilder.java: "mime-type"
>>>./SerializeNodeBuilder.java: "status-code"
>>>
>
> Hmm, either your script is not correct, or your statement above :) Can
> mime-type use variables or not?
>
well, it's the silly script of course
the mime-type CAN use variables, but there is some defaulting in the
code happening upfront which causes it to sneak through the grep -v
VariableResolverFactory
so it's probably safe to state that the generated list was (slightly)
bigger then it should
>
>><SNIP/>
>>
>>anyone any opinion on these?
>>
>>maybe it makes sense to look at these with our "rule of least
>>surprise"-glasses on?
>>
>
> Yes, I think we should go through all these attributes and see/vote
> which ones can be made dynamic.
>
ok, if we vote PRO making them dynamic I guess the too large list is no
problem: it would just mean the work already happened :-)
of course this assumes my script doesn't make errors in the other
direction (which I don't think it does)
anyone up for a better attempt at filtering out the ones we need to
discuss? Or should we just make a full list of all attributes, discuss
it completely and then go back to the code and check/fix for what we
decided?
actually this brings me back to the 'documentation' issue around
'arbitrary-looking' decissions for the newcomers I rose in the original
post (would be nice if we could really automatically list what is
available and dynamic or not)
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: treeprocessor doesn't resolve variables in all attributes of
sitemap nodes
Posted by Carsten Ziegeler <cz...@apache.org>.
Marc Portier wrote:
> Hi there,
>
> just found out that
> <map:serialize status-code="{statusCode}" />
>
> kept giving me a statuscode 200 no matter what the value of statusCode was.
>
> as it turns out the SerializeNodeBuilder will in it's buildNode do:
>
>> this.node = new SerializeNode(
>> type,
>> VariableResolverFactory.getResolver(config.getAttribute("src", null), this.manager),
>> VariableResolverFactory.getResolver(config.getAttribute("mime-type", null), this.manager),
>> config.getAttributeAsInteger("status-code", -1)
>> );
>
>
> which I read as: @src and @mime-type can but @status-code can-not be
> resolved from variables
>
> from an end-user POV this difference in handling is quite arbitrary
> (meaning: if there are good considerations for this we should document
> them well)
>
Hmm, I see no reason why status-code should not be able to use variables.
> <SNIP/>
>>./SerializeNodeBuilder.java: "mime-type"
>>./SerializeNodeBuilder.java: "status-code"
>>
Hmm, either your script is not correct, or your statement above :) Can
mime-type use variables or not?
> <SNIP/>
>
> anyone any opinion on these?
>
> maybe it makes sense to look at these with our "rule of least
> surprise"-glasses on?
>
Yes, I think we should go through all these attributes and see/vote
which ones can be made dynamic.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: treeprocessor doesn't resolve variables in all attributes of
sitemap nodes
Posted by Sylvain Wallez <sy...@apache.org>.
Marc Portier wrote:
> Hi there,
>
> just found out that
> <map:serialize status-code="{statusCode}" />
>
> kept giving me a statuscode 200 no matter what the value of statusCode was.
>
> as it turns out the SerializeNodeBuilder will in it's buildNode do:
>
>> this.node = new SerializeNode(
>> type,
>> VariableResolverFactory.getResolver(config.getAttribute("src", null), this.manager),
>> VariableResolverFactory.getResolver(config.getAttribute("mime-type", null), this.manager),
>> config.getAttributeAsInteger("status-code", -1)
>> );
>>
>
> which I read as: @src and @mime-type can but @status-code can-not be
> resolved from variables
>
> from an end-user POV this difference in handling is quite arbitrary
> (meaning: if there are good considerations for this we should document
> them well)
>
>
> other examples of non-resolvable attributes:
>
>
>> ./ActionSetNodeBuilder.java: "name"
>>
>> ./ActNodeBuilder.java: "set"
>> ./ActNodeBuilder.java: "name"
>> ./ActNodeBuilder.java: "src"
>>
>> ./CallNodeBuilder.java: "resource"
>> ./CallNodeBuilder.java: "function"
>> ./CallNodeBuilder.java: "continuation"
>>
>> ./HandleErrorsNodeBuilder.java: "type"
>> ./HandleErrorsNodeBuilder.java: "when"
>>
>> ./FlowNodeBuilder.java: "language"
>>
>> ./MatchNodeBuilder.java: "pattern"
>> ./MatchNodeBuilder.java: "name"
>>
>> ./MountNodeBuilder.java: "check-reload"
>> ./MountNodeBuilder.java: "pass-through"
>>
>> ./PipelineNodeBuilder.java: "internal-only"
>>
>> ./RedirectToNodeBuilder.java: "resource"
>> ./RedirectToNodeBuilder.java: "target"
>> ./RedirectToNodeBuilder.java: "session"
>> ./RedirectToNodeBuilder.java: "global"
>> ./RedirectToNodeBuilder.java: "permanent"
>>
>> ./ReadNodeBuilder.java: "mime-type"
>> ./ReadNodeBuilder.java: "status-code"
>>
>> ./SerializeNodeBuilder.java: "mime-type"
>> ./SerializeNodeBuilder.java: "status-code"
>>
>> ./ScriptNodeBuilder.java: "src"
>>
>> ./SitemapLanguage.java: "logger"
>> ./SitemapLanguage.java: "role"
>> ./SitemapLanguage.java: "class"
>>
>> ./ViewNodeBuilder.java: "from-label"
>> ./ViewNodeBuilder.java: "from-position"
>>
>
>
> # based on the naieve lookup through
> $ cd src/java/org/apache/cocoon/components/treeprocessor/sitemap/;
> $ find -type f |xargs grep 'config\.get' | grep -v '\.svn' | grep -v
> VariableResolverFactory > ~/UnresolvedSitemapAttributes.txt
>
>
> anyone any opinion on these?
>
All attributes that define the sitemap processing flow should be static.
This was decided to prevent the building of dynamic pipelines, and is
used by the TreeProcessor to do some build-time optimizations.
These static attributes are mainly the "name" on instructions (that
choose the component type) and view labels.
The status-code is obviously a good candidate for resolution, and we can
review all attributes to see what others should be resolved as well.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director