cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [RT] input-modules in the sitemap
Date Tue, 01 Feb 2005 07:27:03 GMT
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.


View raw message