cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: refering to: http://wiki.cocoondev.org/Wiki.jsp?page=CocoonUpgrade
Date Thu, 06 Mar 2003 16:33:16 GMT
Leszek Gawron wrote:
> I think it would be nice if cocoon.xconf could be docomposed into several
> files. why ? Now when changin cocoon version I have to:
> 0. build appropriate version (now it's easy as no javadocs/examples/docs are
> included)
> 1. edit web.xml file to include database driver class loading (obviously that
> connot be moved elsewhere)
> 2. edit cocoon.xconf:
> 	- remove standard datasource (that exists there even if you do not include
> 	  samples, but include database block)
> 	- add my own datasources
> 	- add my own logicsheets
> 	- add my custom components (I do not have ones but surely will have in the
> 	  future)
> 3. customize logkit (add my own categories so I can search entries faster)
> 4. Default sitemap automounts subsitemaps now so it's enough just to copy the
> files
> 
> What's wrong with that ? if you have one additional datasource and one
> logicsheet- no problem, but when changing versions in more complicated
> environment it may drive you nuts.
> 
> The solution would be to allow users create their own cocoon.xconf files
> (residing in the same place as sub-sitemap.xmap that defines local custom
> enhancements). The file could be loaded and components initialized the first
> time users accesses a subsitemap. Is it at all posible ? Same for logkit?


Other possibility would be that you write a patch (diff -u WRT a clean 
config tree) and store it, to be applied when upgrading, and checked 
manually (always needed, as configs tend to have new/changed semantics 
every now and then), even if the patch succeeds.

Just my 2 cents.

Regards,
      Santiago

> 	ouzo



Mime
View raw message