You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2002/10/08 10:35:50 UTC
[Proposal]: Advanced Value Substitution
Hi,
here is a simple proposal for an easier value substitution algorithm
in the sitemap.
Currently, if you nest actions and matchers you have to aware of
the paths to get your information:
<match pattern="**">
<act type="anything">
<read src="{directory}/{../1}"/>
</act>
</match>
This can get very complicated. When I first got contact with value
substitution more than two years ago, I thought I could write:
<read src="{directory}/{1}"/>
The two components use different keys, so there is no conflict and
the values can be resolved.
This is in accordence to usual programming languages where a
variable is not only searched in the current scope but also
in the parent scope:
{
int i;
{
int x;
i = 5;
}
}
Only if you have conflicts, which means you define a variable with
the same name in the inner block and want to use a variable with
the same name of an outer block you have to define the complete
path.
So, keeping this short, I propose to change the search algorithm
for value substitution:
If a key is not found in the inner block, the search is continued
up the chain.
So in the above example {1} is first searched in the values
delivered by the action - not found there - and then searched
in the values by the matcher.
The old path syntax is untouched - so no compatibility problems
but easier handling.
What do you think?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal]: Advanced Value Substitution
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
tcurdt@dff.st wrote:
>Quoting Sylvain Wallez <sy...@anyware-tech.com>:
>
>
>
>>tcurdt@dff.st wrote:
>>
>>
>>
>>>>I think, the proposed {\1} looks nice. And its very easy to understand.
>>>>
>>>>
>>>>
>>>>
>>>Other comments?
>>>
>>>
>>>
>>We don't support absolute paths for now, although it can easily be added
>>in o.a.c.treeprocessor.variables.PreparedVariableResolver.
>>
>>
>
>Should I add it then?
>
>
Sure !
>>We also have the (hidden ?) <map:global-parameters> feature which
>>defines the first level or sitemap variables. These are the ones that
>>should be accessed by the /-rooted notation.
>>
>>
>
>Didn't Carsten just remove it again? (see CVS latest mails)
>Sure we want to drop this completely in favour of the GlobalInputModule?
>
Thought transmission during lunch time !
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal]: Advanced Value Substitution
Posted by tc...@dff.st.
Quoting Sylvain Wallez <sy...@anyware-tech.com>:
> tcurdt@dff.st wrote:
>
> >>I think, the proposed {\1} looks nice. And its very easy to understand.
> >>
> >>
> >
> >Other comments?
> >
>
> We don't support absolute paths for now, although it can easily be added
> in o.a.c.treeprocessor.variables.PreparedVariableResolver.
Should I add it then?
> We also have the (hidden ?) <map:global-parameters> feature which
> defines the first level or sitemap variables. These are the ones that
> should be accessed by the /-rooted notation.
Didn't Carsten just remove it again? (see CVS latest mails)
Sure we want to drop this completely in favour of the GlobalInputModule?
> Naming note : what about renaming "global-parameters" to
> "global-variables" ? Parameters are built by the sitemap for use used by
> components, whereas variables are set by components and given back to
> the sitemap for {} subsitution. So the "global-variables" names seems to
> me more appropriate.
>
> How does it sound ?
Sounds good to me
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal]: Advanced Value Substitution
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Christian Haul wrote:
> > First, it's a general approach which works for all components (at least
> > those
> > looked up using the ComponentManager - it does not work for selectors).
> > It is currently used and it works.
>
> OK. But the "configuration at runtime" argument should hold here, too,
> or be ignorable for the InputModules as well.
>
This depends on your point of view. Look at all the sitemap components,
they are configurable at runtime as well: through map:parameter
statements.
And it wasn't me who abandoned "configuration at runtime". But there is
one important difference between the solution I implemented and the
current input modules: IoC! The current ConfigurableSitemap component
follows strictly the IoC pattern from Avalon - the input modules not.
So, I guess this point is still valid.
> LifeCycle does not make sense for InputModules, so it would be the
> only possibility to pass them on the go.
>
Yes, LifeCycle makes sense - see the globale module or even the
module for getting request information has a lifecycle. By adding
the objectModel to the method signature you make this explicitly.
By choosing RequestLifecycleComponent this would have been
implicit.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal]: Advanced Value Substitution
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 08.Oct.2002 -- 03:17 PM, Carsten Ziegeler wrote:
> Christian Haul wrote:
> >
> > On 08.Oct.2002 -- 02:17 PM, Carsten Ziegeler wrote:
> > > Sylvain Wallez wrote:
> > > >
> > > > Good, we're in accordance again ;-)
> > > >
> > > Yup.
> > >
> > > > However, can you explain the exact purpose of
> > > > <map:component-configurations>, and how it is handled ?
> > > >
> > > > I see that it is now defined in the Processor interface, but can't
> > > > understand how it is used and what CocoonComponentManager exactly does
> > > > with it (this stack management is black magic).
> > > >
> > > > How is it related to <map:components> which is nothing more than the
> > > > configuration of a ComponentManager and can thus hold any component
> > > > declaration ?
> > > >
> > > Ok...this whole thing is a cool (FS-like) implementation of dynamically
> > > configured components....still there?...
> >
> > Carsten, could you explain in a few words how this differs from the
> > modeConf parameter in the InputModule interface and what makes it
> > better here?
> >
> First, it's a general approach which works for all components (at least
> those
> looked up using the ComponentManager - it does not work for selectors).
> It is currently used and it works.
OK. But the "configuration at runtime" argument should hold here, too,
or be ignorable for the InputModules as well.
LifeCycle does not make sense for InputModules, so it would be the
only possibility to pass them on the go.
> And it allows to configure components in the sitemap which are *not*
> declared there - the cocoon user does not notice that these are
> Avalon components.
Dito.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal]: Advanced Value Substitution
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Christian Haul wrote:
>
> On 08.Oct.2002 -- 02:17 PM, Carsten Ziegeler wrote:
> > Sylvain Wallez wrote:
> > >
> > > Good, we're in accordance again ;-)
> > >
> > Yup.
> >
> > > However, can you explain the exact purpose of
> > > <map:component-configurations>, and how it is handled ?
> > >
> > > I see that it is now defined in the Processor interface, but can't
> > > understand how it is used and what CocoonComponentManager exactly does
> > > with it (this stack management is black magic).
> > >
> > > How is it related to <map:components> which is nothing more than the
> > > configuration of a ComponentManager and can thus hold any component
> > > declaration ?
> > >
> > Ok...this whole thing is a cool (FS-like) implementation of dynamically
> > configured components....still there?...
>
> Carsten, could you explain in a few words how this differs from the
> modeConf parameter in the InputModule interface and what makes it
> better here?
>
First, it's a general approach which works for all components (at least
those
looked up using the ComponentManager - it does not work for selectors).
It is currently used and it works.
And it allows to configure components in the sitemap which are *not*
declared there - the cocoon user does not notice that these are
Avalon components.
And this is the general use case:
But sometimes you want to give your component some information/configuration
and want to extend this in your subsitemap. So if you use this component
in the main sitemap it gets the configuration of the main sitemap.
If you use the component in the subsitemap it gets the configuration of
the main sitemap and the subsitemap.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal]: Advanced Value Substitution
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 08.Oct.2002 -- 02:17 PM, Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
> >
> > Good, we're in accordance again ;-)
> >
> Yup.
>
> > However, can you explain the exact purpose of
> > <map:component-configurations>, and how it is handled ?
> >
> > I see that it is now defined in the Processor interface, but can't
> > understand how it is used and what CocoonComponentManager exactly does
> > with it (this stack management is black magic).
> >
> > How is it related to <map:components> which is nothing more than the
> > configuration of a ComponentManager and can thus hold any component
> > declaration ?
> >
> Ok...this whole thing is a cool (FS-like) implementation of dynamically
> configured components....still there?...
Carsten, could you explain in a few words how this differs from the
modeConf parameter in the InputModule interface and what makes it
better here?
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal]: Advanced Value Substitution
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Good, we're in accordance again ;-)
>
Yup.
> However, can you explain the exact purpose of
> <map:component-configurations>, and how it is handled ?
>
> I see that it is now defined in the Processor interface, but can't
> understand how it is used and what CocoonComponentManager exactly does
> with it (this stack management is black magic).
>
> How is it related to <map:components> which is nothing more than the
> configuration of a ComponentManager and can thus hold any component
> declaration ?
>
Ok...this whole thing is a cool (FS-like) implementation of dynamically
configured components....still there?...
There is sometimes the need for a component which I can configure in the
sitemap, e.g. a generator. When you have a sub sitemap you might want to
configure this component differently. This is no problem with the
cascaded component managers.
But sometimes you want to give your component some information/configuration
and want to extend this in your subsitemap. So if you use this component
in the main sitemap it gets the configuration of the main sitemap.
If you use the component in the subsitemap it gets the configuration of
the main sitemap and the subsitemap.
This is for example used for the authentication handler configuration.
A handler configured in the main sitemap is also available in a sub sitemap,
but handlers configured in a subsitemap are not available in the main
sitemap.
How can this be handled? By the o.a.c.components.SitemapConfigurable
components.
If you look up such a component, the setup() method of the above interface
is invoked for each sitemap already processed (main sitemap, first
subsitemap,
subsubsitemap etc.) This invocation takes only place of a configuration
for this component is in the sitemap.
This configuration is in the map:component-configurations block. The
configuration for the component is enclosed in the role name/short-hint.
Example:
MainSitemap
-----------
<map:component-configurations>
<global-variables>
<skin>cocoon</skin>
</global-variables>
</map:component-configurations>
Sub Sitemap
-----------
<map:component-configurations>
<global-variables>
<uri>localhost</uri>
</global-variables>
</map:component-configurations>
Now, if you lookup the global-variables component in the main sitemap
this component knows one value (for skin) - and if you look it
up in the sub sitemap it knows two values (skin and uri).
The global InputModule in turn uses the "global-variables" component,
so you can write {global:skin} in the main sitemap but not
{global:uri}. However, in the subsitemap both is allowed.
(Man, this should go into the docs....hint...hint)
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal]: Advanced Value Substitution
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>tcurdt@dff.st wrote:
>>
>>
>>
>>>>I think, the proposed {\1} looks nice. And its very easy to understand.
>>>>
>>>>
>>>>
>>>>
>>>Other comments?
>>>
>>>
>>>
>>We don't support absolute paths for now, although it can easily be added
>>in o.a.c.treeprocessor.variables.PreparedVariableResolver.
>>
>>We also have the (hidden ?) <map:global-parameters> feature which
>>defines the first level or sitemap variables. These are the ones that
>>should be accessed by the /-rooted notation.
>>
>><map:pipelines>
>> <map:global-parameters>
>> <map:parameter name="img-dir" value="foo"/>
>> </map:global-parameters>
>>
>> <map:pipeline>
>> <map:match src="*.gif">
>> <map:read src="{/img-dir}/{1}.gif"/>
>> </map:match>
>> </map:pipeline>
>></map:pipelines>
>>
>>Naming note : what about renaming "global-parameters" to
>>"global-variables" ? Parameters are built by the sitemap for use used by
>>components, whereas variables are set by components and given back to
>>the sitemap for {} subsitution. So the "global-variables" names seems to
>>me more appropriate.
>>
>>How does it sound ?
>>
>>
>>
>Ehm, since approx. two hours we don't have "global-parameters" anymore!
>Yuppi!
>
>
Good, we're in accordance again ;-)
However, can you explain the exact purpose of
<map:component-configurations>, and how it is handled ?
I see that it is now defined in the Processor interface, but can't
understand how it is used and what CocoonComponentManager exactly does
with it (this stack management is black magic).
How is it related to <map:components> which is nothing more than the
configuration of a ComponentManager and can thus hold any component
declaration ?
>Serious: we had this discussion several months ago to unify the
>"global-parameters" with the input modules and I exactly did this:
>We have a new input module "global" which can be configured in the
>sitemap like the authentication handlers. The name for this
>configuration is ...tata...global-variables.
>
Cool.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal]: Advanced Value Substitution
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> tcurdt@dff.st wrote:
>
> >>I think, the proposed {\1} looks nice. And its very easy to understand.
> >>
> >>
> >
> >Other comments?
> >
>
> We don't support absolute paths for now, although it can easily be added
> in o.a.c.treeprocessor.variables.PreparedVariableResolver.
>
> We also have the (hidden ?) <map:global-parameters> feature which
> defines the first level or sitemap variables. These are the ones that
> should be accessed by the /-rooted notation.
>
> <map:pipelines>
> <map:global-parameters>
> <map:parameter name="img-dir" value="foo"/>
> </map:global-parameters>
>
> <map:pipeline>
> <map:match src="*.gif">
> <map:read src="{/img-dir}/{1}.gif"/>
> </map:match>
> </map:pipeline>
> </map:pipelines>
>
> Naming note : what about renaming "global-parameters" to
> "global-variables" ? Parameters are built by the sitemap for use used by
> components, whereas variables are set by components and given back to
> the sitemap for {} subsitution. So the "global-variables" names seems to
> me more appropriate.
>
> How does it sound ?
>
Ehm, since approx. two hours we don't have "global-parameters" anymore!
Yuppi!
Serious: we had this discussion several months ago to unify the
"global-parameters" with the input modules and I exactly did this:
We have a new input module "global" which can be configured in the
sitemap like the authentication handlers. The name for this
configuration is ...tata...global-variables.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal]: Advanced Value Substitution
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
tcurdt@dff.st wrote:
>>I think, the proposed {\1} looks nice. And its very easy to understand.
>>
>>
>
>Other comments?
>
We don't support absolute paths for now, although it can easily be added
in o.a.c.treeprocessor.variables.PreparedVariableResolver.
We also have the (hidden ?) <map:global-parameters> feature which
defines the first level or sitemap variables. These are the ones that
should be accessed by the /-rooted notation.
<map:pipelines>
<map:global-parameters>
<map:parameter name="img-dir" value="foo"/>
</map:global-parameters>
<map:pipeline>
<map:match src="*.gif">
<map:read src="{/img-dir}/{1}.gif"/>
</map:match>
</map:pipeline>
</map:pipelines>
Naming note : what about renaming "global-parameters" to
"global-variables" ? Parameters are built by the sitemap for use used by
components, whereas variables are set by components and given back to
the sitemap for {} subsitution. So the "global-variables" names seems to
me more appropriate.
How does it sound ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal]: Advanced Value Substitution
Posted by tc...@dff.st.
> I think, the proposed {\1} looks nice. And its very easy to understand.
Other comments?
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal]: Advanced Value Substitution
Posted by Antonio Gallardo Rivera <ag...@agsoftware.dnsalias.com>.
Sorry to put my spoon here ;)
I think Torsten is right. We cannot make dialects. If the users have now
problem with the current syntaxis, this will be even worse if also we will
need to ask:
"What dialect are you using?"
I think, the proposed {\1} looks nice. And its very easy to understand.
Regards,
Antonio Gallardo
El Martes, 08 de Octubre de 2002 04:00, tcurdt@dff.st escribió:
> Quoting Carsten Ziegeler <cz...@s-und-n.de>:
> > Ok, what do you guys think about this?
> >
> > A configurable variable substitution component! I can configure
> > in the cocoon.xconf if I want to use the old substitution algorithm
> > or my suggestion (or a custom implementation).
> >
> > Carsten
>
> ...that will give different sitemap dialects. You sure you want that??
>
> In terms of documentation it definitly a bad thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal]: Advanced Value Substitution
Posted by tc...@dff.st.
Quoting Carsten Ziegeler <cz...@s-und-n.de>:
> Ok, what do you guys think about this?
>
> A configurable variable substitution component! I can configure
> in the cocoon.xconf if I want to use the old substitution algorithm
> or my suggestion (or a custom implementation).
>
> Carsten
...that will give different sitemap dialects. You sure you want that??
In terms of documentation it definitly a bad thing.
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal]: Advanced Value Substitution
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Please don't answer on this one...it's only a joke, really :)
Carsten
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> Sent: Tuesday, October 08, 2002 11:53 AM
> To: cocoon-dev@xml.apache.org
> Subject: RE: [Proposal]: Advanced Value Substitution
>
>
> Ok, what do you guys think about this?
>
> A configurable variable substitution component! I can configure
> in the cocoon.xconf if I want to use the old substitution algorithm
> or my suggestion (or a custom implementation).
>
> Carsten
>
> > -----Original Message-----
> > From: www-data [mailto:www-data@dff.st]On Behalf Of tcurdt@dff.st
> > Sent: Tuesday, October 08, 2002 11:39 AM
> > To: cocoon-dev@xml.apache.org
> > Subject: Re: [Proposal]: Advanced Value Substitution
> >
> >
> > > >here is a simple proposal for an easier value substitution algorithm
> > > >in the sitemap.
> > > >
> > > >Currently, if you nest actions and matchers you have to aware of
> > > >the paths to get your information:
> > > ><match pattern="**">
> > > > <act type="anything">
> > > > <read src="{directory}/{../1}"/>
> > > > </act>
> > > ></match>
> > > >
> > > >This can get very complicated. When I first got contact with value
> > > >substitution more than two years ago, I thought I could write:
> > > ><read src="{directory}/{1}"/>
> > > >
> > > >The two components use different keys, so there is no conflict and
> > > >the values can be resolved.
> > > >This is in accordence to usual programming languages where a
> > > >variable is not only searched in the current scope but also
> > > >in the parent scope:
> >
> > ...
> >
> > > >What do you think?
> > > >
> > >
> > > Sorry Carsten, this is a day where we don't agree :-/
> >
> > Although I am also sometimes confused about substitution values like
> > {../../../../../../../1} just to get the result of the first match..
> > But I fear you might find yourself searching for clashes... don't know
> > if this will make things really easier...
> >
> > BTW: Do we support absolute paths already? like {/1} being on the
> > first level?
> > --
> > Torsten
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal]: Advanced Value Substitution
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Ok, what do you guys think about this?
A configurable variable substitution component! I can configure
in the cocoon.xconf if I want to use the old substitution algorithm
or my suggestion (or a custom implementation).
Carsten
> -----Original Message-----
> From: www-data [mailto:www-data@dff.st]On Behalf Of tcurdt@dff.st
> Sent: Tuesday, October 08, 2002 11:39 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [Proposal]: Advanced Value Substitution
>
>
> > >here is a simple proposal for an easier value substitution algorithm
> > >in the sitemap.
> > >
> > >Currently, if you nest actions and matchers you have to aware of
> > >the paths to get your information:
> > ><match pattern="**">
> > > <act type="anything">
> > > <read src="{directory}/{../1}"/>
> > > </act>
> > ></match>
> > >
> > >This can get very complicated. When I first got contact with value
> > >substitution more than two years ago, I thought I could write:
> > ><read src="{directory}/{1}"/>
> > >
> > >The two components use different keys, so there is no conflict and
> > >the values can be resolved.
> > >This is in accordence to usual programming languages where a
> > >variable is not only searched in the current scope but also
> > >in the parent scope:
>
> ...
>
> > >What do you think?
> > >
> >
> > Sorry Carsten, this is a day where we don't agree :-/
>
> Although I am also sometimes confused about substitution values like
> {../../../../../../../1} just to get the result of the first match..
> But I fear you might find yourself searching for clashes... don't know
> if this will make things really easier...
>
> BTW: Do we support absolute paths already? like {/1} being on the
> first level?
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal]: Advanced Value Substitution
Posted by tc...@dff.st.
> >here is a simple proposal for an easier value substitution algorithm
> >in the sitemap.
> >
> >Currently, if you nest actions and matchers you have to aware of
> >the paths to get your information:
> ><match pattern="**">
> > <act type="anything">
> > <read src="{directory}/{../1}"/>
> > </act>
> ></match>
> >
> >This can get very complicated. When I first got contact with value
> >substitution more than two years ago, I thought I could write:
> ><read src="{directory}/{1}"/>
> >
> >The two components use different keys, so there is no conflict and
> >the values can be resolved.
> >This is in accordence to usual programming languages where a
> >variable is not only searched in the current scope but also
> >in the parent scope:
...
> >What do you think?
> >
>
> Sorry Carsten, this is a day where we don't agree :-/
Although I am also sometimes confused about substitution values like
{../../../../../../../1} just to get the result of the first match..
But I fear you might find yourself searching for clashes... don't know
if this will make things really easier...
BTW: Do we support absolute paths already? like {/1} being on the first level?
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal]: Advanced Value Substitution
Posted by "Ilya A. Kriveshko" <il...@kaon.com>.
How about prefixing of retuned parameters' names? Here's what I mean:
<map:match pattern="*-*" param-prefix="mtch1">
<!-- matcher returns parameters: '1' and '2', which are renamed to
'mtch1:1' and 'mtch1:2' -->
<map:act type="my-action" param-prefix="act1">
<!-- my-action alsoreturns parameters: '1' and '2', which are
renamed to 'act1:1' and 'act1:2' -->
<map:generate type="serverpages" src="{mtch:1}.xsp">
<map:parameter name="display" value="{mtch1:2}"/>
<map:parameter name="param1" value="{act1:1}"/>
<map:parameter name="param2" value="{act1:2}"/>
</map:generate>
</map:act>
</map:match>
Obviously, the exact syntax (i.e. 'prefix:name') is not crucial here.
The sitemap components themselves would not be aware of the prefix, and
would simply return a Map with "1" and "2".
The prefix would be prepended to all the parameter names in that Map by
whatever code is interpreting/executing the sitemap (?)
This way one can always control the visibility of the parameters in
nested elements explicitly by choosing a unique prefix or a matching
prefix. This would also not require any changes to the existing users'
sitemaps, since w/o prefixes everything would work as it does now.
Sorry for intruding on your debate, but I have contributed my opinions
and code here in the past and have been welcome then.
--
Ilya
Vadim Gritsenko wrote:
> Carsten Ziegeler wrote:
>
>> Sylvain Wallez wrote:
>>
>>
>>>> So, keeping this short, I propose to change the search algorithm
>>>> for value substitution:
>>>> If a key is not found in the inner block, the search is continued
>>>> up the chain.
>>>>
>>>
>>> Crawling up the chain can be very expensive !
>>>
>>>
>>
>> Yes, maybe.
>>
>>
>>
>>>> So in the above example {1} is first searched in the values
>>>> delivered by the action - not found there - and then searched
>>>> in the values by the matcher.
>>>>
>>>>
>>>
>>> Your above example, even if it seems nice at first, leads to some
>>> predictability problems : how do you know which {1} will be used ?
>>> What if several components in the stack return a {1} but with a
>>> different meaning ?
>>>
>>> In a programming language, a local variable is *written* in the
>>> code, and you know which one you are using, even if hiding variables
>>> is often considered as a bad practice - if allowed by compilers. In
>>> the sitemap, returned variables are optional and their names aren't
>>> visible.
>>>
>>>
>>
>> Hmm, not exactly - they are not optional - they are defined by the used
>> component. If you read the docs, you know which ones this component
>> returns. They are not directly visible - yes, that's true.
>>
>> If you simply use a variable in a programming language you don't know
>> which one is used, either. You have to carefully scan the code and
>> the same applies to the sitemap where you have to scan the sitemap
>> (and the docs).
>> And you still can use {../../../../37} - no problem.
>>
>> In the last months I saw many cocoon users complaining or even
>> getting stuck into this area. They forgot a ../ here and so on.
>>
>
> Carsten,
>
> Yes, I also seen users stuck there. But the problem is that this
> sitemap concept is not documented (at least, I failed to find proper
> doc).
>
> User's problems will go away as soon as somebody with english writing
> skill will put together something better then
> http://xml.apache.org/cocoon/faq/faq-sitemap.html#faq-7 and in more
> visible place.
>
>
> Vadim
>
>
>>>> The old path syntax is untouched - so no compatibility problems
>>>> but easier handling.
>>>>
>>>> What do you think?
>>>>
>>>>
>>>
>>> Sorry Carsten, this is a day where we don't agree :-/
>>>
>>>
>>
>> Sniff....ok, let's continue the discussions tomorrow :)
>>
>> Carsten
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal]: Advanced Value Substitution
Posted by Vadim Gritsenko <va...@verizon.net>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>>So, keeping this short, I propose to change the search algorithm
>>>for value substitution:
>>>If a key is not found in the inner block, the search is continued
>>>up the chain.
>>>
>>>
>>>
>>Crawling up the chain can be very expensive !
>>
>>
>>
>Yes, maybe.
>
>
>
>>>So in the above example {1} is first searched in the values
>>>delivered by the action - not found there - and then searched
>>>in the values by the matcher.
>>>
>>>
>>>
>>Your above example, even if it seems nice at first, leads to some
>>predictability problems : how do you know which {1} will be used ? What
>>if several components in the stack return a {1} but with a different
>>meaning ?
>>
>>In a programming language, a local variable is *written* in the code,
>>and you know which one you are using, even if hiding variables is often
>>considered as a bad practice - if allowed by compilers. In the sitemap,
>>returned variables are optional and their names aren't visible.
>>
>>
>>
>Hmm, not exactly - they are not optional - they are defined by the used
>component. If you read the docs, you know which ones this component
>returns. They are not directly visible - yes, that's true.
>
>If you simply use a variable in a programming language you don't know
>which one is used, either. You have to carefully scan the code and
>the same applies to the sitemap where you have to scan the sitemap
>(and the docs).
>And you still can use {../../../../37} - no problem.
>
>In the last months I saw many cocoon users complaining or even
>getting stuck into this area. They forgot a ../ here and so on.
>
Carsten,
Yes, I also seen users stuck there. But the problem is that this sitemap
concept is not documented (at least, I failed to find proper doc).
User's problems will go away as soon as somebody with english writing
skill will put together something better then
http://xml.apache.org/cocoon/faq/faq-sitemap.html#faq-7 and in more
visible place.
Vadim
>>>The old path syntax is untouched - so no compatibility problems
>>>but easier handling.
>>>
>>>What do you think?
>>>
>>>
>>>
>>Sorry Carsten, this is a day where we don't agree :-/
>>
>>
>>
>Sniff....ok, let's continue the discussions tomorrow :)
>
>Carsten
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal]: Advanced Value Substitution
Posted by Antonio Gallardo Rivera <ag...@agsoftware.dnsalias.com>.
El Martes, 08 de Octubre de 2002 03:38, Carsten Ziegeler escribió:
> Sylvain Wallez wrote:
> > >So, keeping this short, I propose to change the search algorithm
> > >for value substitution:
> > >If a key is not found in the inner block, the search is continued
> > >up the chain.
> >
> > Crawling up the chain can be very expensive !
>
> Yes, maybe.
>
> > >So in the above example {1} is first searched in the values
> > >delivered by the action - not found there - and then searched
> > >in the values by the matcher.
> >
> > Your above example, even if it seems nice at first, leads to some
> > predictability problems : how do you know which {1} will be used ? What
> > if several components in the stack return a {1} but with a different
> > meaning ?
> >
> > In a programming language, a local variable is *written* in the code,
> > and you know which one you are using, even if hiding variables is often
> > considered as a bad practice - if allowed by compilers. In the sitemap,
> > returned variables are optional and their names aren't visible.
>
> Hmm, not exactly - they are not optional - they are defined by the used
> component. If you read the docs, you know which ones this component
> returns. They are not directly visible - yes, that's true.
>
> If you simply use a variable in a programming language you don't know
> which one is used, either. You have to carefully scan the code and
> the same applies to the sitemap where you have to scan the sitemap
> (and the docs).
> And you still can use {../../../../37} - no problem.
>
> In the last months I saw many cocoon users complaining or even
> getting stuck into this area. They forgot a ../ here and so on.
I think we had problems in this area because this was a new approach and
nobody told us about the "change".
Antonio Gallardo.
>
> > >The old path syntax is untouched - so no compatibility problems
> > >but easier handling.
> > >
> > >What do you think?
> >
> > Sorry Carsten, this is a day where we don't agree :-/
>
> Sniff....ok, let's continue the discussions tomorrow :)
>
> Carsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal]: Advanced Value Substitution
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
> >
> >So, keeping this short, I propose to change the search algorithm
> >for value substitution:
> >If a key is not found in the inner block, the search is continued
> >up the chain.
> >
>
> Crawling up the chain can be very expensive !
>
Yes, maybe.
> >So in the above example {1} is first searched in the values
> >delivered by the action - not found there - and then searched
> >in the values by the matcher.
> >
>
> Your above example, even if it seems nice at first, leads to some
> predictability problems : how do you know which {1} will be used ? What
> if several components in the stack return a {1} but with a different
> meaning ?
>
> In a programming language, a local variable is *written* in the code,
> and you know which one you are using, even if hiding variables is often
> considered as a bad practice - if allowed by compilers. In the sitemap,
> returned variables are optional and their names aren't visible.
>
Hmm, not exactly - they are not optional - they are defined by the used
component. If you read the docs, you know which ones this component
returns. They are not directly visible - yes, that's true.
If you simply use a variable in a programming language you don't know
which one is used, either. You have to carefully scan the code and
the same applies to the sitemap where you have to scan the sitemap
(and the docs).
And you still can use {../../../../37} - no problem.
In the last months I saw many cocoon users complaining or even
getting stuck into this area. They forgot a ../ here and so on.
> >The old path syntax is untouched - so no compatibility problems
> >but easier handling.
> >
> >What do you think?
> >
>
> Sorry Carsten, this is a day where we don't agree :-/
>
Sniff....ok, let's continue the discussions tomorrow :)
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Proposal]: Advanced Value Substitution
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Hi,
>
>here is a simple proposal for an easier value substitution algorithm
>in the sitemap.
>
>Currently, if you nest actions and matchers you have to aware of
>the paths to get your information:
><match pattern="**">
> <act type="anything">
> <read src="{directory}/{../1}"/>
> </act>
></match>
>
>This can get very complicated. When I first got contact with value
>substitution more than two years ago, I thought I could write:
><read src="{directory}/{1}"/>
>
>The two components use different keys, so there is no conflict and
>the values can be resolved.
>This is in accordence to usual programming languages where a
>variable is not only searched in the current scope but also
>in the parent scope:
>{
> int i;
> {
> int x;
> i = 5;
> }
>}
>Only if you have conflicts, which means you define a variable with
>the same name in the inner block and want to use a variable with
>the same name of an outer block you have to define the complete
>path.
>
>So, keeping this short, I propose to change the search algorithm
>for value substitution:
>If a key is not found in the inner block, the search is continued
>up the chain.
>
Crawling up the chain can be very expensive !
>So in the above example {1} is first searched in the values
>delivered by the action - not found there - and then searched
>in the values by the matcher.
>
Your above example, even if it seems nice at first, leads to some
predictability problems : how do you know which {1} will be used ? What
if several components in the stack return a {1} but with a different
meaning ?
In a programming language, a local variable is *written* in the code,
and you know which one you are using, even if hiding variables is often
considered as a bad practice - if allowed by compilers. In the sitemap,
returned variables are optional and their names aren't visible.
>The old path syntax is untouched - so no compatibility problems
>but easier handling.
>
>What do you think?
>
Sorry Carsten, this is a day where we don't agree :-/
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org