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 2005/01/30 21:50:36 UTC
[RT] input-modules in the sitemap
Am I the only one that is bugged by the fact that you have to add the
input modules in the cocoon.xconf while the sitemap components go in the
sitemap?
--
Stefano.
Re: [RT] input-modules in the sitemap
Posted by Ralph Goers <Ra...@dslextreme.com>.
Stefano Mazzocchi wrote:
> Am I the only one that is bugged by the fact that you have to add the
> input modules in the cocoon.xconf while the sitemap components go in
> the sitemap?
>
As part of the stuff Sylvain and Carsten recently did I thought we
discussed putting all "definitions" in the block's xconf file so the
sitemap could only contain pipelines and resource definitions.
Ralph
Re: [RT] input-modules in the sitemap
Posted by Reinhard Poetz <re...@apache.org>.
Stefano Mazzocchi wrote:
> Am I the only one that is bugged by the fact that you have to add the
> input modules in the cocoon.xconf while the sitemap components go in the
> sitemap?
>
Recently there was a discussion about FOM and input modules:
http://marc.theaimsgroup.com/?t=110654827400001&r=1&w=2, in particular
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110657224222559&w=2
in short: it's about making the object model pluggable and useable in the
sitemap, e.g. <map:call continuation="{$cocoon.request.contid}"/>
--
Reinhard
Re: [RT] input-modules in the sitemap
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 31 janv. 05, à 07:59, Sylvain Wallez a écrit :
> ....You can do it right now. <map:components> is handled exactly as an
> xconf file to feed the service manager...
> ...This behaviour, although unofficial, is effective since day one in
> the TreeProcessor. IMO, it's time to make it official.
+1
-Bertrand
Re: [RT] input-modules in the sitemap
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> Am I the only one that is bugged by the fact that you have to add the
>> input modules in the cocoon.xconf while the sitemap components go in
>> the sitemap?
>
>
>
> You can do it right now. <map:components> is handled exactly as an xconf
> file to feed the service manager. And since components don't care about
> namespaces in their configurations, you can even write:
>
> <map:input-modules>
> <map:input-module name="blah" class="com.blah.BlahModule"/>
> </map:input-modules>
>
> (notice though the use of "class" instead of "src")
>
> This behaviour, although unofficial, is effective since day one in the
> TreeProcessor. IMO, it's time to make it official.
Yeah, we could start doing so by moving that section on our own sitemap ;-)
--
Stefano.
Re: [RT] input-modules in the sitemap
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Sylvain Wallez wrote:
>>
>>>> No, please not - with 2.2 we have the official include feature and
>>>> imho this is sufficient for this.
>>>
>>>
>>>
>>>
>>>
>>> Yeah, but technically speaking, this makes absolutely no difference,
>>> as <include> does nothing but expanding the contents of an xconf
>>> within <map:components>
>>>
>> Yes, I know - so following your road we could just skip the whole
>> cocoon.xconf and put it in the root sitemap :)
>> Components are not used directly in the sitemap (except sitemap
>> components), so we shouldn't start defining them in the sitemap. Of
>> course this is a little bit different with input modules which just
>> has historical reasons that they're in the xconf.
>
>
>
> If we restrict ourselves to components "used directly in the sitemap",
> then yes, other component don't fit there.
>
> Now things are different if we consider a sitemap a modularization unit
> in a Cocoon application. Why should we define in the global cocoon.xconf
> e.g. a JDBC datasource that is used only in a particular subsitemap, or
> a business component used in a particular sitemap's flowscript?
>
> A concrete example: imagine an admin tool for a webapp which has write
> access to the user database whereas all other parts of the application
> have read-only access. Allowing the datasource to be defined in the
> admin sitemap cleanly isolates it from the rest of the application. And
> if for some reason we decide that admin should not be possible through
> the web, then just delete the admin directory and you're done, without
> modifying the main xconf.
>
>> I think it's better to move everything out of the sitemap into xconf
>> files that *belong* to the sitemap than the opposite.
>
>
>
> I understand your point. Does this mean you would be ok for the
> datasource mentioned above to be declared in an xconf file included by
> the admin sitemap? From my POV this is just a syntax detail and I'm ok
> with moving sitemap-related components (considered as a modularization
> unit) to an xconf file beside the sitemap.
>
Yes, I think this is a clean solution. I see the need for defining
components "locally" (on a per sitemap base) as well. That's why I
wanted the include feature :) So, I'm +1 for including them from the
sitemap, but -1 for adding them directly in the sitemap.
I know, technically it's the same, but separating them is imho the
cleaner solution.
Carsten
Re: [RT] input-modules in the sitemap
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>>> No, please not - with 2.2 we have the official include feature and
>>> imho this is sufficient for this.
>>
>>
>>
>>
>> Yeah, but technically speaking, this makes absolutely no difference,
>> as <include> does nothing but expanding the contents of an xconf
>> within <map:components>
>>
> Yes, I know - so following your road we could just skip the whole
> cocoon.xconf and put it in the root sitemap :)
> Components are not used directly in the sitemap (except sitemap
> components), so we shouldn't start defining them in the sitemap. Of
> course this is a little bit different with input modules which just
> has historical reasons that they're in the xconf.
If we restrict ourselves to components "used directly in the sitemap",
then yes, other component don't fit there.
Now things are different if we consider a sitemap a modularization unit
in a Cocoon application. Why should we define in the global cocoon.xconf
e.g. a JDBC datasource that is used only in a particular subsitemap, or
a business component used in a particular sitemap's flowscript?
A concrete example: imagine an admin tool for a webapp which has write
access to the user database whereas all other parts of the application
have read-only access. Allowing the datasource to be defined in the
admin sitemap cleanly isolates it from the rest of the application. And
if for some reason we decide that admin should not be possible through
the web, then just delete the admin directory and you're done, without
modifying the main xconf.
> I think it's better to move everything out of the sitemap into xconf
> files that *belong* to the sitemap than the opposite.
I understand your point. Does this mean you would be ok for the
datasource mentioned above to be declared in an xconf file included by
the admin sitemap? From my POV this is just a syntax detail and I'm ok
with moving sitemap-related components (considered as a modularization
unit) to an xconf file beside the sitemap.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] input-modules in the sitemap
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>> No, please not - with 2.2 we have the official include feature and
>> imho this is sufficient for this.
>
>
>
> Yeah, but technically speaking, this makes absolutely no difference, as
> <include> does nothing but expanding the contents of an xconf within
> <map:components>
>
Yes, I know - so following your road we could just skip the whole
cocoon.xconf and put it in the root sitemap :)
Components are not used directly in the sitemap (except sitemap
components), so we shouldn't start defining them in the sitemap. Of
course this is a little bit different with input modules which just has
historical reasons that they're in the xconf.
I think it's better to move everything out of the sitemap into xconf
files that *belong* to the sitemap than the opposite.
Carsten
Re: [RT] input-modules in the sitemap
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> Am I the only one that is bugged by the fact that you have to add
>>> the input modules in the cocoon.xconf while the sitemap components
>>> go in the sitemap?
>>
>
> We had several attempts to change this but there was always someone
> against it :(
>
>> You can do it right now. <map:components> is handled exactly as an
>> xconf file to feed the service manager. And since components don't
>> care about namespaces in their configurations, you can even write:
>>
>> <map:input-modules>
>> <map:input-module name="blah" class="com.blah.BlahModule"/>
>> </map:input-modules>
>>
>> (notice though the use of "class" instead of "src")
>>
>> This behaviour, although unofficial, is effective since day one in
>> the TreeProcessor. IMO, it's time to make it official.
>
>
> No, please not - with 2.2 we have the official include feature and
> imho this is sufficient for this.
Yeah, but technically speaking, this makes absolutely no difference, as
<include> does nothing but expanding the contents of an xconf within
<map:components>
So writing
<map:components>
<include src="blah.xconf"/>
</map:components>
is exactly the same as copy/pasting the contents of blah.xconf in the
sitemap...
Going further, add the possibility to specify a class-path to
<map:components> to feed a per-sitemap classloader (or autocompiling
classloader) and you have cheap semi-real blocks.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] input-modules in the sitemap
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> Am I the only one that is bugged by the fact that you have to add the
>> input modules in the cocoon.xconf while the sitemap components go in
>> the sitemap?
>
We had several attempts to change this but there was always someone
against it :(
>
>
> You can do it right now. <map:components> is handled exactly as an xconf
> file to feed the service manager. And since components don't care about
> namespaces in their configurations, you can even write:
>
> <map:input-modules>
> <map:input-module name="blah" class="com.blah.BlahModule"/>
> </map:input-modules>
>
> (notice though the use of "class" instead of "src")
>
> This behaviour, although unofficial, is effective since day one in the
> TreeProcessor. IMO, it's time to make it official.
>
No, please not - with 2.2 we have the official include feature and imho
this is sufficient for this.
Carsten
Re: [RT] input-modules in the sitemap
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Am I the only one that is bugged by the fact that you have to add the
> input modules in the cocoon.xconf while the sitemap components go in
> the sitemap?
You can do it right now. <map:components> is handled exactly as an xconf
file to feed the service manager. And since components don't care about
namespaces in their configurations, you can even write:
<map:input-modules>
<map:input-module name="blah" class="com.blah.BlahModule"/>
</map:input-modules>
(notice though the use of "class" instead of "src")
This behaviour, although unofficial, is effective since day one in the
TreeProcessor. IMO, it's time to make it official.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }