You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2004/12/20 12:23:08 UTC
Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Marc Portier wrote:
>
>
> Reinhard Poetz wrote:
>
>> Tony Collen wrote:
>>
>>
>> as said in my previos mail: we *have to* reach a common understanding
>> on what Cocoon *core* is.
>>
>
> it seems logic to me there would be something as 'minimal' and
> 'typical' as opposed to the current 'full'
>
> More categories would probably be just a waste of energy?
>
> And yeah, I sense somewhat your fear for some long-winding discussion
> on the outer-boundaries of those (including room for quite some
> surmising mails eloquently brought as the new testament)...
>
> Now, being really pragmatic, and somewhat inline with Daniel's
> suggestion of moving out the blocks on the svn-repo (sounded quite
> ok), there seems to be an easy win based on the build-system we
> already have
>
> - provide sample local.*.properties files for the various categories
> - opt for one of those to become the default one (I guess deciding
> will depend on what is actually in those, or else content discussions
> will be fueled by this upfront decission)
>
> all of which should at least ensure:
>
> - that new blocks added do _not_ get automatically added to the build?
After doing some internal support on our projects here last week, I saw
once again how difficult it is for people, even experienced ones, to
strip down Cocoon to their needs.
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.
Sooo complicated and painful when there are so many components you don't
even know what their use is. Result: all blocks are included in every
project, which effectively makes Cocoon scary (not talking also of the
slow startup).
So, enough is enough, I started this week-end to scracth something that
has been itching me for long: being able to have one xconf snippet per
block (including the core block), the main cocoon.xconf being just a set
of imports of block-specific xconf snippets.
The result is that to activate/deactivate a block, you'll simply have to
decomment/comment a line in the main cocoon.xconf. Example:
<cocoon>
<!-- block-specific components -->
<import src="cocoon-pdf-block.xconf"/>
<import src="cocoon-portal-block.xconf"/>
<import src="cocoon-svg-block.xconf"/>
<!-- the core cocoon components (parser, cache, pipelines, etc) -->
<import src="cocoon-core.xconf"/>
</cocoon>
The biggest problem is not related to the actual inclusion, but that
some selectors can be fed by multiple blocks (e.g. source protocols
provided by core, xmldb and databases blocks or taglibs provided by
taglib and faces blocks).
So I started refactoring ECM++ so that a selector doesn't manage
components itself but adds them to its service manager, and also
delegates select() to this manager. This actually "flattens" the
component space, thus allowing variations of a given role (what normally
goes into selectors) to come from different sources. This is nearly done
(still some problems for selectors nested in selectors), and <import>
should come soon after.
WDYT?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
<snip/>
>> After doing some internal support on our projects here last week, I
>> saw once again how difficult it is for people, even experienced ones,
>> to strip down Cocoon to their needs.
>>
>> 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.
>>
>> Sooo complicated and painful when there are so many components you
>> don't even know what their use is. Result: all blocks are included in
>> every project, which effectively makes Cocoon scary (not talking also
>> of the slow startup).
>>
>> So, enough is enough, I started this week-end to scracth something
>> that has been itching me for long: being able to have one xconf
>> snippet per block (including the core block), the main cocoon.xconf
>> being just a set of imports of block-specific xconf snippets.
>>
>> The result is that to activate/deactivate a block, you'll simply have
>> to decomment/comment a line in the main cocoon.xconf. Example:
>> <cocoon>
>> <!-- block-specific components -->
>> <import src="cocoon-pdf-block.xconf"/>
>> <import src="cocoon-portal-block.xconf"/>
>> <import src="cocoon-svg-block.xconf"/>
>>
>> <!-- the core cocoon components (parser, cache, pipelines, etc) -->
>> <import src="cocoon-core.xconf"/>
>> </cocoon>
>>
>> The biggest problem is not related to the actual inclusion, but that
>> some selectors can be fed by multiple blocks (e.g. source protocols
>> provided by core, xmldb and databases blocks or taglibs provided by
>> taglib and faces blocks).
>>
>> So I started refactoring ECM++ so that a selector doesn't manage
>> components itself but adds them to its service manager, and also
>> delegates select() to this manager. This actually "flattens" the
>> component space, thus allowing variations of a given role (what
>> normally goes into selectors) to come from different sources. This is
>> nearly done (still some problems for selectors nested in selectors),
>> and <import> should come soon after.
>>
>> WDYT?
>
>
> AWESOME!!! You are my new hero :-) [well, you are in my hero list
> already but your plaque was getting rusty now I'm off to shine it up
> again ;-)]
Kewl, but please wait for it to actually work before shining my plaque ;-)
Sylvai
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Marc Portier wrote:
>
>>
>>
>> Reinhard Poetz wrote:
>>
>>> Tony Collen wrote:
>>>
>>>
>>> as said in my previos mail: we *have to* reach a common understanding
>>> on what Cocoon *core* is.
>>>
>>
>> it seems logic to me there would be something as 'minimal' and
>> 'typical' as opposed to the current 'full'
>>
>> More categories would probably be just a waste of energy?
>>
>> And yeah, I sense somewhat your fear for some long-winding discussion
>> on the outer-boundaries of those (including room for quite some
>> surmising mails eloquently brought as the new testament)...
>>
>> Now, being really pragmatic, and somewhat inline with Daniel's
>> suggestion of moving out the blocks on the svn-repo (sounded quite
>> ok), there seems to be an easy win based on the build-system we
>> already have
>>
>> - provide sample local.*.properties files for the various categories
>> - opt for one of those to become the default one (I guess deciding
>> will depend on what is actually in those, or else content discussions
>> will be fueled by this upfront decission)
>>
>> all of which should at least ensure:
>>
>> - that new blocks added do _not_ get automatically added to the build?
>
>
>
> After doing some internal support on our projects here last week, I saw
> once again how difficult it is for people, even experienced ones, to
> strip down Cocoon to their needs.
>
> 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.
>
> Sooo complicated and painful when there are so many components you don't
> even know what their use is. Result: all blocks are included in every
> project, which effectively makes Cocoon scary (not talking also of the
> slow startup).
>
> So, enough is enough, I started this week-end to scracth something that
> has been itching me for long: being able to have one xconf snippet per
> block (including the core block), the main cocoon.xconf being just a set
> of imports of block-specific xconf snippets.
>
> The result is that to activate/deactivate a block, you'll simply have to
> decomment/comment a line in the main cocoon.xconf. Example:
> <cocoon>
> <!-- block-specific components -->
> <import src="cocoon-pdf-block.xconf"/>
> <import src="cocoon-portal-block.xconf"/>
> <import src="cocoon-svg-block.xconf"/>
>
> <!-- the core cocoon components (parser, cache, pipelines, etc) -->
> <import src="cocoon-core.xconf"/>
> </cocoon>
>
> The biggest problem is not related to the actual inclusion, but that
> some selectors can be fed by multiple blocks (e.g. source protocols
> provided by core, xmldb and databases blocks or taglibs provided by
> taglib and faces blocks).
>
> So I started refactoring ECM++ so that a selector doesn't manage
> components itself but adds them to its service manager, and also
> delegates select() to this manager. This actually "flattens" the
> component space, thus allowing variations of a given role (what normally
> goes into selectors) to come from different sources. This is nearly done
> (still some problems for selectors nested in selectors), and <import>
> should come soon after.
>
> WDYT?
AWESOME!!! You are my new hero :-) [well, you are in my hero list
already but your plaque was getting rusty now I'm off to shine it up
again ;-)]
--
Stefano.
RE: Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> <SNIP/>
>
> The result is that to activate/deactivate a block, you'll
> simply have to decomment/comment a line in the main
> cocoon.xconf. Example:
> <cocoon>
> <!-- block-specific components -->
> <import src="cocoon-pdf-block.xconf"/>
> <import src="cocoon-portal-block.xconf"/>
> <import src="cocoon-svg-block.xconf"/>
>
> <!-- the core cocoon components (parser, cache, pipelines, etc) -->
> <import src="cocoon-core.xconf"/>
> </cocoon>
>
> The biggest problem is not related to the actual inclusion,
Yes, the inclusion could be done by using entities although the explicit
import statement looks nicer to be.
I like the idea, but I would love to extend it a little bit:
<import src="configs/*.xconf"/>
This would import all files ending with ".xconf" from the configs directory.
So a little support for patterns would be great. An alternative would be:
<import dir="configs"/> which simply imports all files in the configs
directory.
WDYT?
Carsten
Re: app skeleton based on YourCocoonBasedProjectAnt16?
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> Le 20 déc. 04, à 14:39, Sylvain Wallez a écrit :
>
>> ...Sorry, but I still find this too much complicated. 12 steps,
>> involving ant, command-line, xpatch are way too much complex compared
>> to my proposal which simply consists in moving files around and
>> modifying <import> elements in a centralized file...
>
>
> Ok, let's see your proposal in the flesh.
> We're probably seing the problem from different perspectives here.
Sure, we have the same problem: assembling a Cocoon suited to our
project's need in the most simple way.
>> ...We must come back to a binary distro which can be stripped down
>> easily and started without having to open a console window. That will
>> make Cocoon less scary...
>
>
> Hmm...I still think people need to be comfortable with a command-line
> to be efficient with Cocoon. you'd lose too much by sticking to point
> and click. But having such a distro wouldn't hurt for training or
> initial contact with Cocoon.
Well, here is what I need to type on the command line as a user (not
talking of developing Cocoon):
- build.sh webapp
- cocoon.sh servlet
Provide a binary distro and have cocoon.sh/bat start as servlet by
default and you can develop your entire project without ever using a
commandline prompt.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: app skeleton based on YourCocoonBasedProjectAnt16?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 20 déc. 04, à 14:39, Sylvain Wallez a écrit :
> ...Sorry, but I still find this too much complicated. 12 steps,
> involving ant, command-line, xpatch are way too much complex compared
> to my proposal which simply consists in moving files around and
> modifying <import> elements in a centralized file...
Ok, let's see your proposal in the flesh.
We're probably seing the problem from different perspectives here.
> ...We must come back to a binary distro which can be stripped down
> easily and started without having to open a console window. That will
> make Cocoon less scary...
Hmm...I still think people need to be comfortable with a command-line
to be efficient with Cocoon. you'd lose too much by sticking to point
and click. But having such a distro wouldn't hurt for training or
initial contact with Cocoon.
-Bertrand
Re: app skeleton based on YourCocoonBasedProjectAnt16?
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Sylvain Wallez wrote:
> During trainings, many people are trying to start Cocoon by
> double-clicking on cocoon.bat and tell me "it fails to start" simply
> because this file expects an argument. Windows users are really not used
> to using the commandline.
lenya solved this by making servlet the default target.
Re: app skeleton based on YourCocoonBasedProjectAnt16?
Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:
> 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.
Sorry, but I still find this too much complicated. 12 steps, involving
ant, command-line, xpatch are way too much complex compared to my
proposal which simply consists in moving files around and modifying
<import> elements in a centralized file.
During trainings, many people are trying to start Cocoon by
double-clicking on cocoon.bat and tell me "it fails to start" simply
because this file expects an argument. Windows users are really not used
to using the commandline.
We must come back to a binary distro which can be stripped down easily
and started without having to open a console window. That will make
Cocoon less scary.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
app skeleton based on YourCocoonBasedProjectAnt16? (was: Splitting cocoon.xconf)
Posted by Bertrand Delacretaz <bd...@apache.org>.
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?
Re: Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Poetz wrote:
> Sylvain Wallez wrote:
>
>> The result is that to activate/deactivate a block, you'll simply have
>> to decomment/comment a line in the main cocoon.xconf. Example:
>> <cocoon>
>> <!-- block-specific components -->
>> <import src="cocoon-pdf-block.xconf"/>
>> <import src="cocoon-portal-block.xconf"/>
>> <import src="cocoon-svg-block.xconf"/>
>>
>> <!-- the core cocoon components (parser, cache, pipelines, etc) -->
>> <import src="cocoon-core.xconf"/>
>> </cocoon>
>
>
> two thoughts:
> 1. once on icq we chatted about implicit .xconf files to enable
> blocks. this goes into the same direction, doesn't it? Imean if i
> deploay a block inzo WEB-INF/blocks, it isn't necessary to make an
> explicit import.
Well, WEB-INF/blocks isn't there yet, but yes, there could be some
implicit imports from deployed blocks. I finally chose an explicit
<import> statement for the main cocoon.xconf rather than loading
WEB-INF/*.xconf in order for this feature to work in the less magical
and therefore the more predictible and understandable way.
> 2. how does this relate to carsten's proposal, that we are voting on?
<import> will come for free in <map:components> also. We may want to
keep a uniform syntax between xconf and xmap or have a different one
with <map:components src="blah.xconf"/>, which actually easily
translates to an xconf with a single <import>. I have no particular
preference for one syntax or the other ATM...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Posted by Reinhard Poetz <re...@apache.org>.
Sylvain Wallez wrote:
> The result is that to activate/deactivate a block, you'll simply have to
> decomment/comment a line in the main cocoon.xconf. Example:
> <cocoon>
> <!-- block-specific components -->
> <import src="cocoon-pdf-block.xconf"/>
> <import src="cocoon-portal-block.xconf"/>
> <import src="cocoon-svg-block.xconf"/>
>
> <!-- the core cocoon components (parser, cache, pipelines, etc) -->
> <import src="cocoon-core.xconf"/>
> </cocoon>
two thoughts:
1. once on icq we chatted about implicit .xconf files to enable blocks. this
goes into the same direction, doesn't it? Imean if i deploay a block inzo
WEB-INF/blocks, it isn't necessary to make an explicit import.
2. how does this relate to carsten's prposal, that we are voting on?
--
Reinhard
RE: Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> So I started refactoring ECM++ so that a selector doesn't
> manage components itself but adds them to its service
> manager, and also delegates select() to this manager. This
> actually "flattens" the component space, thus allowing
> variations of a given role (what normally goes into
> selectors) to come from different sources. This is nearly
> done (still some problems for selectors nested in selectors),
> and <import> should come soon after.
>
Sounds great. ECM++ did already part of it, or more precisly
it did it the other way round: you could lookup a component
using the fortress syntax and this was delegated to the
appropriate selector.
Carsten