You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/10/10 23:50:19 UTC
Variable Expanders
Piroumian Konstantin wrote:
> Ok. I'll give a real Use-Case and you look at it with your critical glance.
> Maybe we are too input-module-minded after so many discussions and are
> FS-infected.
Thanks, I really needed that.
> Forrest's Use-Case
> ==============
>
> Prerequisites
> ---------------------
> Forrest has skinning system which now uses Ant filtering tokens in the
> sitemap to define which skin to use, e.g.:
>
> <map:transform src="skins/@skin@/style.xsl" />
>
> Everyone agrees that this looks ugly and the skin name is hard-coded in the
> resulting sitemap, which makes it impossible to change the skin at runtime
> in the web-app version of Forrest. It also requires the source to be copied
> to the 'build' directory and makes development a little more difficult (you
> should run build after every change in the sitemap, while Cocoon could
> reload it from the source directly).
>
> Solution
> -------------
> Using a special input module makes sitemap look much better:
>
> <map:transform src="skins/{skin:name}/style.xsl" />
>
> Everyone agrees with this one too.
Ok, cool, I see.
> Chaining
> -------------
> Where does the skin module get the configuration data? There are several
> places where it can get it:
> - a request parameter (?skin-name=forrest-site)
> - a session attribute (after the user has set this somewhere else)
> - a cookie (to retain user's settings between sessions)
> - a config file (customized default values for a specific project)
> - configuration in cocoon.xconf (global default, used if customized
> config is not found)
Ok, got it.
> So having already input modules for 'request-param', 'session-attr',
> 'cookie' and 'xml-config' we can use a meta module which simply traverse
> it's child input modules and tries to get the value from them. Then it was
> proposed this approach:
>
> <component-instance class="MetaModule" name="skin">
> <input-module name="request-param"/>
> <input-module name="session-attr"/>
> <input-module name="cookie"/>
> <input-module name="xml-config"/>
> <input-module name="defaults"/>
> </component-instance>
>
>>So, what the heck is this 'glue' thing?
>
>
> So, the 'glue' is a meta module which has other input modules as its config.
Gotcha.
>
>>And why is Torsten is talking about "filters"? gosh, don't you people
>>think we already have enough concepts and components and models and
>>names? (expecially when they are so widely used that nobody
>>really knows
>>if the user already knows the concept or has to relearn it
>>from scratch)
>
>
> I have no idea what the 'filter' can mean in this context, but from the
> user's point of view, input modules act as namespaced sitemap variables,
> e.g.:
>
> <map:transform src="{request-param:stylesheet-name}.xsl" />
>
> So, instead of using a wrapper action to get a request parameter value in
> the sitemap, the user will simply use this short version.
All right, finally I got the picture. I really needed that (and I think
many others as well).
Now, follow me:
1) from the user's point of view, input modules act as namespaced
sitemap variables (you said that)
2) that means that just like the user knows that type="xslt" will
match the transformer associated with 'xslt', the variable
{request:skin} will match the 'skin' attribute in the input module named
'request'
so, question:
why aren't you declaring them in the sitemap?
also
why not calling them something more specific than InputModules?
Take a look at this
<map:sitemap>
<map:components>
...
<map:expanders>
<map:expander name="A" src="..."/>
<map:expander name="B" src="..."/>
</map:expanders>
...
</map:components>
...
<map:expanders-sets>
<map:expander-set name="blah">
<map:expand type="A"/>
<map:expand type="B"/>
</map:expander-set>
</map:expander-sets>
...
</map:sitemap>
isn't it more precisely describing what you want to achieve?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Variable Expanders
Posted by Vadim Gritsenko <va...@verizon.net>.
Jeff Turner wrote:
>On Fri, Oct 11, 2002 at 01:56:09PM +0200, Christian Haul wrote:
>
>
>>On 11.Oct.2002 -- 09:38 PM, Jeff Turner wrote:
>>
>>
>...
>
>
>>>How about if they could be declared in either cocoon.xconf (when used
>>>generically) or sitemap.xmap (when used as 'expanders')? Two different
>>>'contexts', two different configuration syntaxes.
>>>
>>>
>>And another clarification: I don't _really_ mind declaring them in
>>sitemap.
>>
>>
>
>Would that be in addition to, or instead of, declaring them in
>cocoon.xconf?
>
My opinion: in additon to. Same as for other sitemap components.
PS Is it mail problem - have you seen
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103428869316766&w=2 ?
Vadim
>--Jeff
>
>
>
>> Chris.
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Variable Expanders
Posted by Jeff Turner <je...@apache.org>.
On Fri, Oct 11, 2002 at 01:56:09PM +0200, Christian Haul wrote:
> On 11.Oct.2002 -- 09:38 PM, Jeff Turner wrote:
...
> > How about if they could be declared in either cocoon.xconf (when used
> > generically) or sitemap.xmap (when used as 'expanders')? Two different
> > 'contexts', two different configuration syntaxes.
>
> And another clarification: I don't _really_ mind declaring them in
> sitemap.
Would that be in addition to, or instead of, declaring them in
cocoon.xconf?
--Jeff
>
> Chris.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Variable Expanders
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 11.Oct.2002 -- 09:38 PM, Jeff Turner wrote:
> On Fri, Oct 11, 2002 at 11:49:50AM +0200, Christian Haul wrote:
> > On 10.Oct.2002 -- 11:50 PM, Stefano Mazzocchi wrote:
> [snip naming debate]
Just to make things clear: I don't _really_ mind changing the name.
> [snip (unneeded) expander-sets]
>
> > > isn't it more precisely describing what you want to achieve?
> >
> > No. It changes a name and not for the better and places the
> > declaration to a place were SoC is breached. What really is needed is
> > multiple xconfs. Most (all?) sitemap components should be in a local
> > xconf.
>
> How would multiple configs help? I'd imagine:
>
> cocoon.xconf -> declare and configure generic components
> sitemap.xconf -> declare and configure sitemap components (map:components stuff)
> sitemap.xmap -> use components
>
> But even then, input modules would belong in cocoon.xconf (being
> generic), so multiple configs isn't the answer to the problem.
One would only declare stuff relevant to the application. This is
mostlikely a different person than the one caring about cocoon.xconf.
> > Until then, it should stay in the one that we have.
>
> How about if they could be declared in either cocoon.xconf (when used
> generically) or sitemap.xmap (when used as 'expanders')? Two different
> 'contexts', two different configuration syntaxes.
And another clarification: I don't _really_ mind declaring them in
sitemap.
> > BTW did someone notice, that these thingies that we spend so much time
> > about now are in CVS since Q1 02??
>
> :) Probably because no-one had any clue they were _useful_. Their general
> usefulness was so well camouflaged by docs like the one above.
And a third one: I didn't intent to blame anyone for not noticing
earlier. I just wondered why it draws so much attention now.
And yes, I hope to find some spare time during the week end and come
up with a new "glue" module like the one we discussed and agreed
on. In addition, I will change the interface to return an Iterator
instead of an Enumeration. Provided I find the time.
Oh, I almost don't dare to suggest it: but what if a module could gain
access to the sitemap variable stack? a) it could provide easy XPath
access to all vars and b) could provide any naming scheme desired.
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: Variable Expanders
Posted by Jeff Turner <je...@apache.org>.
On Fri, Oct 11, 2002 at 11:49:50AM +0200, Christian Haul wrote:
> On 10.Oct.2002 -- 11:50 PM, Stefano Mazzocchi wrote:
...
> > why aren't you declaring them in the sitemap?
>
> Because they are not only relevant to the sitemap and declaration of
> general components in the sitemap was considered bad.
> >
> > Take a look at this
> >
> > <map:sitemap>
> > <map:components>
> > ...
> > <map:expanders>
> > <map:expander name="A" src="..."/>
> > <map:expander name="B" src="..."/>
> > </map:expanders>
> > ...
> > </map:components>
....
[snip naming debate]
[snip (unneeded) expander-sets]
> > isn't it more precisely describing what you want to achieve?
>
> No. It changes a name and not for the better and places the
> declaration to a place were SoC is breached. What really is needed is
> multiple xconfs. Most (all?) sitemap components should be in a local
> xconf.
How would multiple configs help? I'd imagine:
cocoon.xconf -> declare and configure generic components
sitemap.xconf -> declare and configure sitemap components (map:components stuff)
sitemap.xmap -> use components
But even then, input modules would belong in cocoon.xconf (being
generic), so multiple configs isn't the answer to the problem.
> Until then, it should stay in the one that we have.
How about if they could be declared in either cocoon.xconf (when used
generically) or sitemap.xmap (when used as 'expanders')? Two different
'contexts', two different configuration syntaxes.
> It probably doesn't add anything to this discussion, but maybe this
> illustrates some aspects.
> http://xml.apache.org/cocoon/userdocs/concepts/modules.html
>
> BTW did someone notice, that these thingies that we spend so much time
> about now are in CVS since Q1 02??
:) Probably because no-one had any clue they were _useful_. Their general
usefulness was so well camouflaged by docs like the one above.
--Jeff
> 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: Variable Expanders
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Hi (this mail is *not* targetted at anyone specific),
I can only repeat myself:
We need something *similar* to the current InputModules for the
sitemap - this must not necessarily be those components we already
have - just ignore them for now (for this discussion).
What we need is a simple and usable concept for the sitemap
(repeat: *sitemap* and not cocoon.xconf or blocks or...).
And to clarify this distinction it might be worth to use a
new name as Stefano suggested. It's a "new" concept anyway...
And yes, the current implementation is a long time in the cvs
but have a close look at the whole cvs. How many components/classes
are there which some of us don't know? Does anybody really care?
This topic has now gained much interest and we all can only learn
from it.
Look at other components we have, e.g. the webservices support or
the portal framework. Unless one really uses it, one can't have an
opinion about it. So one ignores it - until this topic gets
interesting. And when it gets interest by a wider audience
it's important to make the best out of it and listen to other opinions.
The input modules have an intersting history: first they were introduced
as a nice concept but were not intended to be used in the sitemap.
Then someone had the idea: "Hey, we can use them in the sitemap" and
they were integrated. And now many people feel: "Hmm, I can use them
in the sitemap now - but I don't like the way it works." And it's
our responsibility to fix this.
This whole discussions has cost many energy and one can think
"Uhm, if one of us had spend this energy into implementing this stuff,
it would already be there." Perhaps this is the right approach to
do, perhaps not. Anyway, we should summarize these ideas -
otherwise I fear that this thread will silently "die another day"
and nothing happens - the history in this project has proofed this.
Ah man, I really hate writing these long mails...
So what's the conclusion we can draw here?
Let's forget the current InputModule implementation for the sitemap.
Let's implement a new "component" for this, and invent a name for it.
Let's see how it works - remember we are in alpha state, so
we can simply delete it, if it doesn't make sense.
I will go on vacation for the next two weeks, so I'm interest in
what I will find when I come back :)
Have a nice weekend.
Bye
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Variable Expanders
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 10.Oct.2002 -- 11:50 PM, Stefano Mazzocchi wrote:
> Piroumian Konstantin wrote:
> Now, follow me:
>
> 1) from the user's point of view, input modules act as namespaced
> sitemap variables (you said that)
If used in sitemap, yes. In gereral they are arbitrary data sources.
> 2) that means that just like the user knows that type="xslt" will
> match the transformer associated with 'xslt', the variable
> {request:skin} will match the 'skin' attribute in the input module named
> 'request'
>
> so, question:
>
> why aren't you declaring them in the sitemap?
Because they are not only relevant to the sitemap and declaration of
general components in the sitemap was considered bad.
> also
>
> why not calling them something more specific than InputModules?
>
> Take a look at this
>
> <map:sitemap>
> <map:components>
> ...
> <map:expanders>
> <map:expander name="A" src="..."/>
> <map:expander name="B" src="..."/>
> </map:expanders>
> ...
> </map:components>
OK, although I don't like the name. <map:inputs><map:input .../></map:inputs>
would IMO be better.
> <map:expanders-sets>
> <map:expander-set name="blah">
> <map:expand type="A"/>
> <map:expand type="B"/>
> </map:expander-set>
> </map:expander-sets>
Since you can stack them as you like (if they support it, that is), it
does not make sense to have a special syntax for it. InputModules that
can be composed of others ('meta') differ in no way from 'normal'
ones. So there is no need for a special block.
> isn't it more precisely describing what you want to achieve?
No. It changes a name and not for the better and places the
declaration to a place were SoC is breached. What really is needed is
multiple xconfs. Most (all?) sitemap components should be in a local
xconf. Until then, it should stay in the one that we have.
It probably doesn't add anything to this discussion, but maybe this
illustrates some aspects.
http://xml.apache.org/cocoon/userdocs/concepts/modules.html
BTW did someone notice, that these thingies that we spend so much time
about now are in CVS since Q1 02??
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: Variable Expanders
Posted by Vadim Gritsenko <va...@verizon.net>.
Stefano Mazzocchi wrote:
> Piroumian Konstantin wrote:
>
>> Ok. I'll give a real Use-Case and you look at it with your critical
>> glance.
>
[forrest use-case goes here]
>> from the
>> user's point of view, input modules act as namespaced sitemap variables,
>> e.g.:
>>
>> <map:transform src="{request-param:stylesheet-name}.xsl" />
>>
>> So, instead of using a wrapper action to get a request parameter
>> value in
>> the sitemap, the user will simply use this short version.
>
>
> All right, finally I got the picture. I really needed that (and I
> think many others as well).
"Me-too" goes here.
> Now, follow me:
>
> 1) from the user's point of view, input modules act as namespaced
> sitemap variables (you said that)
>
> 2) that means that just like the user knows that type="xslt" will
> match the transformer associated with 'xslt', the variable
> {request:skin} will match the 'skin' attribute in the input module
> named 'request'
>
> so, question:
>
> why aren't you declaring them in the sitemap?
>
> also
>
> why not calling them something more specific than InputModules?
>
> Take a look at this
>
> <map:sitemap>
> <map:components>
> ...
> <map:expanders>
> <map:expander name="A" src="..."/>
> <map:expander name="B" src="..."/>
> </map:expanders>
> ...
> </map:components>
>
> ...
>
> <map:expanders-sets>
> <map:expander-set name="blah">
> <map:expand type="A"/>
> <map:expand type="B"/>
> </map:expander-set>
> </map:expander-sets>
>
> ...
>
> </map:sitemap>
>
> isn't it more precisely describing what you want to achieve?
Stefano,
AFAIU from these recent discussions (yes, I've read them - silently), it
is not yet set in stone where input modules should be declared - in the
sitemap or in the cocoon.xconf. Some (or many) do not agree with input
modules configuration in the xconf file. I also think that input modules
should be declared in the sitemap - it's more user friendly then in the
xconf.
But, as we have now ability to declare any sitemap components in the
xconf file, same way (IMHO) we should have ability to declare input
modules in the xconf too. And this should not remove ability to declare
them in the sitemap - were all declarations of the "glue" modules
actually belongs to.
Thus, it seems to me that the best way would be to support configuration
in the xconf *and* in the sitemap - same way as for other sitemap
components (generators, etc).
Regarding this component name: input module / expander / what-else:
Let's choose one and stick to it, before 2.0.4 released.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Variable Expanders
Posted by Giacomo Pati <gi...@apache.org>.
Stefano Mazzocchi wrote:
<snipped alot />
> Take a look at this
>
> <map:sitemap>
> <map:components>
> ...
> <map:expanders>
> <map:expander name="A" src="..."/>
> <map:expander name="B" src="..."/>
> </map:expanders>
> ...
> </map:components>
>
> ...
>
> <map:expanders-sets>
> <map:expander-set name="blah">
> <map:expand type="A"/>
> <map:expand type="B"/>
> </map:expander-set>
> </map:expander-sets>
>
> ...
>
> </map:sitemap>
>
> isn't it more precisely describing what you want to achieve?
Another big +1 today ;-)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Variable Expanders
Posted by Giacomo Pati <gi...@apache.org>.
Sylvain Wallez wrote:
>> <map:sitemap>
>> <map:components>
>> ...
>> <map:expanders>
>> <map:expander name="A" src="..."/>
>> <map:expander name="B" src="..."/>
>> </map:expanders>
>> ...
>> </map:components>
>
>
>
> +1 ! This should be as easy as adding a few lines in
> treeprocessor-builtins.xml !
What about sitemap.xsl ??
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Variable Expanders
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
> Piroumian Konstantin wrote:
>
>> Ok. I'll give a real Use-Case and you look at it with your critical
>> glance.
>> Maybe we are too input-module-minded after so many discussions and are
>> FS-infected.
>
>
> Thanks, I really needed that.
>
>> Forrest's Use-Case
>> ==============
>>
>> Prerequisites
>> ---------------------
>> Forrest has skinning system which now uses Ant filtering tokens in the
>> sitemap to define which skin to use, e.g.:
>>
>> <map:transform src="skins/@skin@/style.xsl" />
>>
>> Everyone agrees that this looks ugly and the skin name is hard-coded
>> in the
>> resulting sitemap, which makes it impossible to change the skin at
>> runtime
>> in the web-app version of Forrest. It also requires the source to be
>> copied
>> to the 'build' directory and makes development a little more
>> difficult (you
>> should run build after every change in the sitemap, while Cocoon could
>> reload it from the source directly).
>>
>> Solution
>> -------------
>> Using a special input module makes sitemap look much better:
>>
>> <map:transform src="skins/{skin:name}/style.xsl" />
>>
>> Everyone agrees with this one too.
>
>
> Ok, cool, I see.
>
>> Chaining
>> -------------
>> Where does the skin module get the configuration data? There are several
>> places where it can get it:
>> - a request parameter (?skin-name=forrest-site)
>> - a session attribute (after the user has set this somewhere else)
>> - a cookie (to retain user's settings between sessions)
>> - a config file (customized default values for a specific project)
>> - configuration in cocoon.xconf (global default, used if customized
>> config is not found)
>
>
> Ok, got it.
>
>> So having already input modules for 'request-param', 'session-attr',
>> 'cookie' and 'xml-config' we can use a meta module which simply traverse
>> it's child input modules and tries to get the value from them. Then
>> it was
>> proposed this approach:
>>
>> <component-instance class="MetaModule" name="skin">
>> <input-module name="request-param"/>
>> <input-module name="session-attr"/>
>> <input-module name="cookie"/>
>> <input-module name="xml-config"/>
>> <input-module name="defaults"/>
>> </component-instance>
>
> >
>
>>> So, what the heck is this 'glue' thing?
>>
>>
>>
>> So, the 'glue' is a meta module which has other input modules as its
>> config.
>
>
> Gotcha.
>
>>
>>> And why is Torsten is talking about "filters"? gosh, don't you
>>> people think we already have enough concepts and components and
>>> models and names? (expecially when they are so widely used that
>>> nobody really knows if the user already knows the concept or has to
>>> relearn it from scratch)
>>
>>
>>
>> I have no idea what the 'filter' can mean in this context, but from the
>> user's point of view, input modules act as namespaced sitemap variables,
>> e.g.:
>>
>> <map:transform src="{request-param:stylesheet-name}.xsl" />
>>
>> So, instead of using a wrapper action to get a request parameter
>> value in
>> the sitemap, the user will simply use this short version.
>
>
> All right, finally I got the picture. I really needed that (and I
> think many others as well).
>
> Now, follow me:
>
> 1) from the user's point of view, input modules act as namespaced
> sitemap variables (you said that)
>
> 2) that means that just like the user knows that type="xslt" will
> match the transformer associated with 'xslt', the variable
> {request:skin} will match the 'skin' attribute in the input module
> named 'request'
>
> so, question:
>
> why aren't you declaring them in the sitemap?
>
> also
>
> why not calling them something more specific than InputModules?
>
> Take a look at this
>
> <map:sitemap>
> <map:components>
> ...
> <map:expanders>
> <map:expander name="A" src="..."/>
> <map:expander name="B" src="..."/>
> </map:expanders>
> ...
> </map:components>
+1 ! This should be as easy as adding a few lines in
treeprocessor-builtins.xml !
> <map:expanders-sets>
> <map:expander-set name="blah">
> <map:expand type="A"/>
> <map:expand type="B"/>
> </map:expander-set>
> </map:expander-sets>
I see the analogy with action sets, but don't think it is applicable
here. Actions are called using <map:act type="..."> whereas action-sets
are called using <map:act set="...">.
We don't have such a distinction for the use of input modules (or
yet-another-puking-syntax ?), so we steel need the meta-module, but now
declared in the <map:expanders> section.
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: Variable Expanders
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> 1) from the user's point of view, input modules act as namespaced
> sitemap variables (you said that)
>
> 2) that means that just like the user knows that type="xslt" will
> match the transformer associated with 'xslt', the variable
> {request:skin} will match the 'skin' attribute in the input module named
> 'request'
>
> so, question:
>
> why aren't you declaring them in the sitemap?
>
+5
> also
>
> why not calling them something more specific than InputModules?
>
> Take a look at this
>
> <map:sitemap>
> <map:components>
> ...
> <map:expanders>
> <map:expander name="A" src="..."/>
> <map:expander name="B" src="..."/>
> </map:expanders>
> ...
> </map:components>
>
> ...
>
> <map:expanders-sets>
> <map:expander-set name="blah">
> <map:expand type="A"/>
> <map:expand type="B"/>
> </map:expander-set>
> </map:expander-sets>
>
> ...
>
> </map:sitemap>
>
> isn't it more precisely describing what you want to achieve?
>
+1
And with this new name we can keep the more general InputModules
as they are. Sounds good.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org