Le 20 déc. 04, à 12:23, Sylvain Wallez a écrit :
> ...The problem is that you have to know beforehand what blocks we want
> to use, compile them and -- here comes the real problem -- generate a
> cocoon.xconf. If you ever want to add or remove a block later on, you
> have to strip down the project's cocoon.xconf or merge it with the one
> that resulted from a new build with more blocks...
Taking a slightly different perspective here, I think both things can
be parallel: for several (rather small) recent projects I've been using
an application skeleton based on
http://wiki.apache.org/cocoon/YourCocoonBasedProjectAnt16, and I've
found it relatively easy to add and remove blocks as needed, by editing
one file, and also easy to add my own components by putting xconf files
in the appropriate directory (I've also started to use hivemind as the
application component manager to be decoupled from the Cocoon internals
at the app level but that's another story).
I was thinking that we could add an "application seed" to SVN (in a new
"contrib" directory maybe), a skeleton that allows people to build
their own apps based on Cocoon, with minimal interference with Cocoon's
build and blocks system. In this structure, the relevant parts of
Cocoon are "pulled into" the application as needed, based on a simple
configuration file which is itself built from Cocoon's configs.
IMHO this is very good for small to medium projects, and it requires
little knowledge about Cocoon internals to be productive.
I'd be happy to commit a stripped-down app skeleton if people think
this is useful.
WDYT?
|