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/06/27 13:39:07 UTC
[RT]: Unifying input modules and global parameters
In the latest CVS of 2.1, I think we have two overlapping
concepts: the global parameters and the input modules.
Perhaps we could merge the global parameters somehow into
the input modules and then remove the global parameters
as a separate concept again.
Current State
-------------
Currently, the global parameters are declared in the
map:pipelines section of a sitemap and the scope
is the map:pipeline sections.
So, if you want to refer to a global parameter, for
example named "skin", you have to use
{skin}, or {../skin} etc. depending on the depth of
your statement in the map:pipeline section.
Disadvantages:
- If you refer to a global parameter, you have to
precisly specify the path (= count the ../)
- global parameters are not inherited/available to
sub-sitemaps
Advantage:
- Configuration directly in the sitemap
The input modules are completly defined in the cocoon.xconf,
they can be used inside every sitemap by first choosing
the input module and then the key, like {request:parametername}.
Advantage:
- Simple use
- Single configured values are available in all sitemaps
Disadvantage:
- Configuration is not in the sitemap, but in the cocoon.xconf
Proposed Solution
-----------------
Make one input module sitemap configurable, like the
authentication manager. This means a (global) input module is
defined in the cocoon.xconf, but can be additionally configured
in the sitemap.
A subsitemap inherits this configuration from it's parent sitemap
and can add own key/value pairs, so this would look like this:
<map:pipelines>
<map:component-configurations>
<global-input-module>
<skin>some-value</skin>
...
</global-input-module>
</map:component-configurations>
</map:pipelines>
So, the key {global:skin} is available in this sitemap and in
all sub-sitemaps.
Comments? Suggestions?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Unifying input modules and global parameters
Posted by Stefano Mazzocchi <st...@apache.org>.
Christian Haul wrote:
> No, let's wait for a consensus for blocks and see if it would help us
> here.
Well, as soon as we don't release anything, we can play around with
things as much as possible, but I agree with Chris that the path taken
is dangerous.
I won't be able to write the block RT tonight, probably tomorrow.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Unifying input modules and global parameters
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 27.Jun.2002 -- 02:40 PM, Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
> >Currently, the global parameters are declared in the
> >map:pipelines section of a sitemap and the scope
> >is the map:pipeline sections.
I don't like this. Because it is yet another concept with overlaps
with other concepts. IMHO it boils down to the variable discussion
which was rejected because sitemap is no programming language.
> >- global parameters are not inherited/available to
> > sub-sitemaps
>
> I'm not sure if it's good for them to be automatically inherited. I
> suggested to add <map:parameters> to <map:mount> to achieve a behaviour
> similar to <xsl:param> (see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102267914817420&w=2)
While I don't like global parameters, having parameters for mount makes
sense because I believe a mount differs not much from a call. OTOH
with the advent of flowscripts, deprecating calls or at least
parameters for it might be sensible.
Since in all other cases parameters are used by the construct
immediately preceeding the parameter, the principle of least surprise
would suggest that parameters to "call" and "mount" are used by "call"
and "mount" respectively and not made available later on.
> >Advantage:
> >- Configuration directly in the sitemap
> >
> >The input modules are completly defined in the cocoon.xconf,
> >they can be used inside every sitemap by first choosing
> >the input module and then the key, like {request:parametername}.
> >
> >Advantage:
> >- Simple use
> >- Single configured values are available in all sitemaps
> >
> >Disadvantage:
> >- Configuration is not in the sitemap, but in the cocoon.xconf
I don't really see a need why any component should be configured in
sitemap.xmap at all -- if we had a way to break up the global
configuration file into small chunks. Thus I'm in favour of removing
all the actions, matchers, and selectors from sitemap.xmap. Not for
adding another category to it.
> >Proposed Solution
> >Make one input module sitemap configurable, like the
> >authentication manager. This means a (global) input module is
> >defined in the cocoon.xconf, but can be additionally configured
> >in the sitemap.
> >A subsitemap inherits this configuration from it's parent sitemap
> >and can add own key/value pairs, so this would look like this:
Again, I don't like it. And even if we are in alpha, we shouldn't
introduce features we will regret later because the installed base
relies on them so we cannot remove them again.
> Also, a few days ago, you have forbidden someone to add additional
> components in <map:components>, but since it _does_ work (only with the
> TreeProcessor, just like InputModules), wouldn't it be simpler to add
> <input-modules> in <map:components> to locally redefine/augment the set
> of input modules defined in cocoon.xconf ? Note that allowing this would
> be a first step towards a separate xconf per sitemap, and then cocoon
> blocks.
And even though I pointed out that it is possible I did it only
because I mistakenly thought map:components was an advertised feature.
No, let's wait for a consensus for blocks and see if it would help us
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: [RT]: Unifying input modules and global parameters
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> We really shouldn't allow this and patiently wait for
> Stefano and Giacomo to present their blocks concept.
Coming up later tonight.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT]: Unifying input modules and global parameters
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
> <snip>
>
> >Disadvantages:
> >- If you refer to a global parameter, you have to
> > precisly specify the path (= count the ../)
> >
>
> With the "/"-rooted syntax, this problem disappears.
>
Agreed.
> >- global parameters are not inherited/available to
> > sub-sitemaps
> >
> >
>
> I'm not sure if it's good for them to be automatically inherited. I
> suggested to add <map:parameters> to <map:mount> to achieve a behaviour
> similar to <xsl:param> (see
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102267914817420&w=2)
>
I think inheritance makes sense, because all other things (=generators,
readers etc. ) are inherited, so why not global parameters. Adding
<map:parameters> to a <map:mount> is still a possible feature. Inheriting
global parameters does not prevent us from also doing it.
> <snip/>
>
> Is this special handing of a particular global inputmodule still needed
> with "/"-rooted variables and <map:parameters> as proposed above ?
You have a special handling of a particular global inputmodule in contrast
to a special handling of so called global parameters. I don't know
what is better. But what makes IMHO sense, is the inheritance of
global parameters; I think someone already asked this some days ago.
>
> Also, a few days ago, you have forbidden someone to add additional
> components in <map:components>, but since it _does_ work (only with the
> TreeProcessor, just like InputModules), wouldn't it be simpler to add
> <input-modules> in <map:components> to locally redefine/augment the set
> of input modules defined in cocoon.xconf ? Note that allowing this would
> be a first step towards a separate xconf per sitemap, and then cocoon
> blocks.
>
Wow, I didn't know I have the power to forbid someone something. I think
I don't have the power and I really don't want to have it. It's still
open source, so everyone can do what he wants (at least as long as he is
an accepted committer...).
And I'm still -1000 (or choose any number less than -1) on defining
components in the sitemap. IMHO it is only possible by accident and
should be reverted. We really shouldn't allow this and patiently wait for
Stefano and Giacomo to present their blocks concept. If we allow
a <map:components> sections in the sitemap we could skip the cocoon.xconf.
But let's not get out of focus with this discussion, it's about
unifying input modules and global parameters.
So with your suggestion of a "/"-rooted syntax, we have another possibility
(if the parameters are inherited to a sub sitemap).
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Unifying input modules and global parameters
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>In the latest CVS of 2.1, I think we have two overlapping
>concepts: the global parameters and the input modules.
>Perhaps we could merge the global parameters somehow into
>the input modules and then remove the global parameters
>as a separate concept again.
>
>Current State
>-------------
>
>Currently, the global parameters are declared in the
>map:pipelines section of a sitemap and the scope
>is the map:pipeline sections.
>So, if you want to refer to a global parameter, for
>example named "skin", you have to use
>{skin}, or {../skin} etc. depending on the depth of
>your statement in the map:pipeline section.
>
>
I didn't knew this already existed, but thought of that while
implementing module-defined parameters. Basically, the idea is that
global sitemap parameters can be accessed throught the root of the
variable tree, i.e. {/skin}.
>Disadvantages:
>- If you refer to a global parameter, you have to
> precisly specify the path (= count the ../)
>
With the "/"-rooted syntax, this problem disappears.
>- global parameters are not inherited/available to
> sub-sitemaps
>
>
I'm not sure if it's good for them to be automatically inherited. I
suggested to add <map:parameters> to <map:mount> to achieve a behaviour
similar to <xsl:param> (see
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102267914817420&w=2)
>Advantage:
>- Configuration directly in the sitemap
>
>
>The input modules are completly defined in the cocoon.xconf,
>they can be used inside every sitemap by first choosing
>the input module and then the key, like {request:parametername}.
>
>Advantage:
>- Simple use
>- Single configured values are available in all sitemaps
>
>Disadvantage:
>- Configuration is not in the sitemap, but in the cocoon.xconf
>
>
>Proposed Solution
>-----------------
>Make one input module sitemap configurable, like the
>authentication manager. This means a (global) input module is
>defined in the cocoon.xconf, but can be additionally configured
>in the sitemap.
>A subsitemap inherits this configuration from it's parent sitemap
>and can add own key/value pairs, so this would look like this:
>
><map:pipelines>
> <map:component-configurations>
> <global-input-module>
> <skin>some-value</skin>
> ...
> </global-input-module>
> </map:component-configurations>
></map:pipelines>
>
>So, the key {global:skin} is available in this sitemap and in
>all sub-sitemaps.
>
>Comments? Suggestions?
>
>
Is this special handing of a particular global inputmodule still needed
with "/"-rooted variables and <map:parameters> as proposed above ?
Also, a few days ago, you have forbidden someone to add additional
components in <map:components>, but since it _does_ work (only with the
TreeProcessor, just like InputModules), wouldn't it be simpler to add
<input-modules> in <map:components> to locally redefine/augment the set
of input modules defined in cocoon.xconf ? Note that allowing this would
be a first step towards a separate xconf per sitemap, and then cocoon
blocks.
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: [RT]: Unifying input modules and global parameters
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
> In the latest CVS of 2.1, I think we have two overlapping
> concepts: the global parameters and the input modules.
> Perhaps we could merge the global parameters somehow into
> the input modules and then remove the global parameters
> as a separate concept again.
>
> Current State
> -------------
>
> Currently, the global parameters are declared in the
> map:pipelines section of a sitemap and the scope
> is the map:pipeline sections.
> So, if you want to refer to a global parameter, for
> example named "skin", you have to use
> {skin}, or {../skin} etc. depending on the depth of
> your statement in the map:pipeline section.
>
> Disadvantages:
> - If you refer to a global parameter, you have to
> precisly specify the path (= count the ../)
> - global parameters are not inherited/available to
> sub-sitemaps
>
> Advantage:
> - Configuration directly in the sitemap
>
>
> The input modules are completly defined in the cocoon.xconf,
> they can be used inside every sitemap by first choosing
> the input module and then the key, like {request:parametername}.
>
> Advantage:
> - Simple use
> - Single configured values are available in all sitemaps
>
> Disadvantage:
> - Configuration is not in the sitemap, but in the cocoon.xconf
>
>
> Proposed Solution
> -----------------
> Make one input module sitemap configurable, like the
> authentication manager. This means a (global) input module is
> defined in the cocoon.xconf, but can be additionally configured
> in the sitemap.
> A subsitemap inherits this configuration from it's parent sitemap
> and can add own key/value pairs, so this would look like this:
>
> <map:pipelines>
> <map:component-configurations>
> <global-input-module>
> <skin>some-value</skin>
> ...
> </global-input-module>
> </map:component-configurations>
> </map:pipelines>
>
> So, the key {global:skin} is available in this sitemap and in
> all sub-sitemaps.
>
> Comments? Suggestions?
+1. Sounds good.
Vadim
> Carsten
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org