Sylvain Wallez wrote:
Team, here's a formal vote about splitting cocoon.xconf.
I propose to add a new <import> feature in cocoon.xconf so that adding/removing blocks to a Cocoon instance doesn't require do merge each block's configuration in a unique cocoon.xconf file as of today.
With this feature, cocoon.xconf can simply be a list of imports, thus allowing to very easily add/remove blocks in a Cocoon application. For more background, please see the initial "splitting cocoon.xconf" post [1].
The first implementation will focus on basic import (one file per <import> element), and later on we'll implement globbing features proposed by Carsten [2].
Please cast your votes.
Here's my +1 (of course!)
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110354180900487&w=2 [2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110361460811792&w=2
If I'm allowed to vote here: +1000 ! Really good idea!
One suggestion:
Why not optionally scanning the folder WEB-INF for files having a special suffix (e.g. *.inc.xconf) and then, including the content of this files under the root element <cocoon/> in cocoon.xconf? This avoids any changes of cocoon.xconf if own components must be included. Just placing such a file in WEB-INF makes the component or block working. This makes it very easy to provide own components for customers by using build processes like Ant.
Maybe two possibilities: An import element <import/> to import a special file and a element <import-files/> to scan a certain folder for files to include at the specified position. An example:
<import-files dir="context://WEB-INF/xconf-includes" suffix=".inc.xconf"/>
WDYT?
Ahh, after reading the messages of the posted links above, I saw, Carsten has already posted an similar idea. Nevertheless, I will post this message, too ;-) Just to express that this feature would very very nice!!
Regards Stephan
