You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2004/12/19 21:32:53 UTC
Re: Cocoon, a Huge, Scary Beast?
Daniel Fagerstrom wrote:
> Steven Noels wrote:
> <snip/>
>
>> I had a Cocoon BOF two days ago at JavaPolis. I spoke to quite a few
>> folks during the conference as well, which know how we (as a company)
>> have been pushing people to use Cocoon over the past three years.
>
>
>> With all due respect, I think there's only a few things we should care
>> to work on to give Cocoon more chances for success. I know there were
>> many success stories lately, but we should be realistic as well: the
>> world is looking into a shift from Struts to JSF, and that's about all
>> they care.
>
>
> Or at least the _Java_ world ;) I think that one of the reasons that
> Cocoon is complex is that part of the developer community has a Java
> centric view and other parts of the community has a XML centric view.
> And the perception of what is a nice and elegant solution of a certain
> usecase, often differ between the two groups.
>
>> People still perceive Cocoon as a big, complicated, scary beast.
>
>
> And IMHO they are right. I think we spend much more effort in making
> complicated things possible than in making simple things simple. That
> might be a natural result of gathering higly competent developers, but
> neither the less, the threshold for start using Cocoon is rather high.
>
> I found the Orbeon tutorial
> http://www.orbeon.com/ois/doc/pages/Tutorial.pdf, rather interesting.
> Not that I necesarilly agreed with their solutions. But it seemed that
> simple things actually where simple to achieve.
>
> I think that a basic Cocoon tutorial that describe our _prefered_ way of
> doing basic stuff is what we most of all lack in our documentation.
> Maybe we could start from the supersonic tour. There are several
> advantages on having an _official_ basic tutorial:
>
> * We have to decide what the basic use cases for Cocoon are.
> * We have to decide what _the_ prefered way of doing a certain thing is.
> * We would (hopefully) feel motivated to make the things in the tutorial
> as simple to achieve as possible.
>
>> Some recurring complaints were:
>>
>> * documentation (oh well)
>> * cohesive direction (as in: _only_ explain folks about things like
>> the power trio, and make sure these things work flawlessly, and stop
>> being hesitant about deprecation and removal of alternatives)
>> * prune, prune, prune: make blocks separately downloadable, and drop
>> blocks which aren't supported nor used
>
>
> Yes, I think its time to stop waiting for the "real blocks". They are no
> doubt important and I very much apriciate Reihard's effort in making
> them happen. But IMO blocks are not only about technology its much more
> about how we organize our work. And we can start to work on the
> organizational issues right away.
>
> IMO we should create a block directory directly under cocoon in svn,
> with the sub directories:
> * supported/stable,
> * supported/unstable and
> * unsupported,
> (for the detailed structure I'm certain that Reinhard had a much better
> idea, my main message is the supported, unsupported dimension). Next we
> put all of our blocks in the unsupported directory. Then if someone feel
> that a block actually should be supported by us as a community he/she
> has to start a vote about it. And during such a vote I think that we
> should be carfull about if we are +0 or +1 about a block, i.e. if we are
> mearly positive about it or if we actually are going to support it.
>
> Also we should make an evaluation of the "core" components in
> generation, transformer etc, some of might really be core but many of
> them are there because they where written before the block system or
> because they are percieved to small for being part of a block or because
> no one have cared enough.
>
> Moving all the blocks outside the trunk might complicate things in the
> short term, but I think that it is necessary that we decide what we are
> going to support as a community. Then some of the blocks might become
> sub projects in their own right. It will also make us more motivated in
> working on the tools for block handling.
>
>> * make sure people don't need a bit of everything to build a decent
>> Cocoon app (as in: some Actions, some Input modules, some Javascript,
>> some Java, a bit of CForms, a choice over various O/R efforts, some
>> Springkles here and there, and so on and so forth)
>
>
> Exactly, we could create a minimal Cocoon distro with just core and the
> supported stuff (or even a base subset of the suported stuff).
>
>> The last one doesn't mean people shouldn't use all this, it's just
>> that all this is now perceived as totally separated, isolated,
>> unrelated and incohesively documented stuff.
>>
>> The JBoss folks were right when they told me over drinks that Cocoon
>> is too much of a research project.
>
>
> "It is all about community" I would be supprised if I'm the only one who
> joined the community, not only because I needed an XML based web
> framework, but also as I enjoyed Stefano's and others RTs. Being partly
> a research project is not only one of Cocoon's main problems it is also
> one of its main strenghs. In short tht: if it wasn't partly a research
> project, both the community and the project would be something else, or
> not at all. So the question is how we protect our users and our selfs
> from the negative aspects. IMHO we do a rather good work in keeping
> Cocoon stable, but we might be less succesfull in communicating that we
> care much about it.
>
>> Just to give an example: JXTG isn't even used massively (too many
>> folks still stuck with XSPs), and already we start chatting about
>> JXTG-NG. How should users believe we actually care about them? (=
>> literal remark I got yesterday!)
>
>
> Yes, this is an example of how the perception about what we do and what
> we actually do differ. The JXTG work is mainly about making JXTG easier
> to support and build upp on for our community, and to achieve a position
> where we as a community can say that JXTG is the recomended template
> solution in Cocoon. I think that I and other people involved in the work
> have said that it is going to be back compatible in about every mail
> about it, but it created a lot of FUD anyway :/
>
> /Daniel
first sorry for the short answer, ...
before my accident I held a 3-days training on Cocoon. the feedback was very
positive but there was one thing that made me think: after the third day they
told me that really like cForms, flow and pipelines but they didn't find this
information in the docs in the way I told them. as bertrand said, we have much
more docs than we think but they do not *reflect* Cocoon in 2004. you might also
say that I have a different view on Cocoon than others.
we should make our understanding of Cocoon explicit before we
move on with writing new docs or start to clean up blocks:
The real question is:
+-------------------------------------+
| WHAT IS APACHE COCOON CORE? |
+-------------------------------------+
I try to give an answer in technical terms:
- sitemap & side-effect-free pipelines
- continuation based controller
- xml templating
- forms framewrok
based on the concepts of soc and ioc.
i know this may sound controversial for some of you but we shouldn't confuse our
users with old ways of doing things like xsp or pipelines that generate content
by directly accessing datasources without an explicit controller.
this has to be cleared - our first step.
next step:
imo we should strip down Cocoon to a minimum:
- cocoon servlet env
- basic pipeline components: fileGen, traxTrans, wildcMatcher,
htmlSer, xmlSer, cachingPipe, noncachingPipe
- flowscript
- jxtemplate
- cforms
everything else should be factored out to other places. based on this micro
Cocoon we can start to write docs & beginner tutorials only for this *from the
scratch* - every single existing doc should be evaluated, missing docs newly
written.
third step: reorganizing the rest.
(following this path also makes blocks dev easier).
--
Reinhard
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
Splitting cocoon.xconf (was Re: Cocoon, a Huge, Scary Beast?)
Posted by Sylvain Wallez <sy...@apache.org>.
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: Cocoon, a Huge, Scary Beast?
Posted by Reinhard Poetz <re...@apache.org>.
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)...
or even the old 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?
yes, a good first step. pls, whoever is able to, just do it IN 2.2! but if we
want to write new docs that's not enough, because we need a (at least pragmatic)
understanding about the message of those new docs, imho.
--
Reinhard
Re: Cocoon, a Huge, Scary Beast?
Posted by Marc Portier <mp...@outerthought.org>.
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?
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: Cocoon, a Huge, Scary Beast?
Posted by Reinhard Poetz <re...@apache.org>.
Tony Collen wrote:
> Reinhard Poetz wrote:
>
> [snip]
>
>> this has to be cleared - our first step.
>>
>> next step:
>> imo we should strip down Cocoon to a minimum:
>
>
> I was having this thought as well recently....
>
>>
>> - cocoon servlet env
>> - basic pipeline components: fileGen, traxTrans, wildcMatcher,
>> htmlSer, xmlSer, cachingPipe, noncachingPipe
>> - flowscript
>> - jxtemplate
>> - cforms
>
>
> My ideas were simple. Currently, (practically) every block is included
> by default. For ages, people ask how to build a minimal Cocoon. IMO we
> should give it to them by default. Obviously, excluding all the blocks
> by default won't result in a maximal, "demo" build of Cocoon. This
> could be worked around by including a couple sample blocks.properties
> files. Perhaps the default one could be minimal (The stuff you listed
> above, basic components, FS, JXTG, etc..), and we can include a
> sample-full.blocks.properties in the repository.
>
> The problem about having a default "minimal" build is that we won't have
> sample apps. We need some good sample apps (perhaps built from the
> Supersonic-Tour) up front that aren't buried.
>
>> everything else should be factored out to other places. based on this
>> micro Cocoon we can start to write docs & beginner tutorials only for
>> this *from the scratch* - every single existing doc should be
>> evaluated, missing docs newly written.
>
>
> +10000. Supersonic Tour should be the "premiere" tutorial for Cocoon.
> Installation and building docs need to be completely overhauled. It's
> really hard to even just find the SVN repository URL, and the fact that
> we aren't using CVS anymore.
>
> I'm all for having the docs in Document-v.whatever, but I'm also not
> afraid to just start writing and organizing docs with MSWord or GVim.
>
> IMO the docs have a few major areas that need to be addressed:
>
> Intro: What is Cocoon, etc.
> Tutorials/General Documentation: Supersonic Tour. How to build apps and
> publish with Cocoon
> Reference Docs: API Docs, Component Reference, SVN repo, mailing lists,
> etc.
as said in my previos mail: we *have to* reach a common understanding on what
Cocoon *core* is.
--
Reinhard
Re: Cocoon, a Huge, Scary Beast?
Posted by Tony Collen <co...@umn.edu>.
Reinhard Poetz wrote:
[snip]
> this has to be cleared - our first step.
>
> next step:
> imo we should strip down Cocoon to a minimum:
I was having this thought as well recently....
>
> - cocoon servlet env
> - basic pipeline components: fileGen, traxTrans, wildcMatcher,
> htmlSer, xmlSer, cachingPipe, noncachingPipe
> - flowscript
> - jxtemplate
> - cforms
My ideas were simple. Currently, (practically) every block is included
by default. For ages, people ask how to build a minimal Cocoon. IMO we
should give it to them by default. Obviously, excluding all the blocks
by default won't result in a maximal, "demo" build of Cocoon. This
could be worked around by including a couple sample blocks.properties
files. Perhaps the default one could be minimal (The stuff you listed
above, basic components, FS, JXTG, etc..), and we can include a
sample-full.blocks.properties in the repository.
The problem about having a default "minimal" build is that we won't have
sample apps. We need some good sample apps (perhaps built from the
Supersonic-Tour) up front that aren't buried.
> everything else should be factored out to other places. based on this
> micro Cocoon we can start to write docs & beginner tutorials only for
> this *from the scratch* - every single existing doc should be evaluated,
> missing docs newly written.
+10000. Supersonic Tour should be the "premiere" tutorial for Cocoon.
Installation and building docs need to be completely overhauled. It's
really hard to even just find the SVN repository URL, and the fact that
we aren't using CVS anymore.
I'm all for having the docs in Document-v.whatever, but I'm also not
afraid to just start writing and organizing docs with MSWord or GVim.
IMO the docs have a few major areas that need to be addressed:
Intro: What is Cocoon, etc.
Tutorials/General Documentation: Supersonic Tour. How to build apps and
publish with Cocoon
Reference Docs: API Docs, Component Reference, SVN repo, mailing lists, etc.
Tony
Re: Cocoon, a Huge, Scary Beast?
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz wrote:
> <snip/>
>
>> before my accident
>
>
> Havn't heard anything about that, what happended? Hope you are well again.
>
>> I held a 3-days training on Cocoon. the feedback was very
>> positive but there was one thing that made me think: after the third
>> day they
>> told me that really like cForms, flow and pipelines but they didn't
>> find this
>> information in the docs in the way I told them. as bertrand said, we
>> have much more docs than we think but they do not *reflect* Cocoon in
>> 2004. you might also say that I have a different view on Cocoon than
>> others.
>
>
> I did a lot of teaching before. Among other things I gave several
> courses in C++. The first couple of times I used course materials
> developed of others, following the traditional idea that the more
> language constructs you learn the better. And that newly added language
> features are more advanced and are taught later in the course or not at
> all (probably reflecting the teachers layzyness in learning new stuff).
> Anyway, even if that was what people expected and that they where happy
> with it, I more and more realized that such a teaching methodology sucks
> and even is destructive.
>
> If you think about it, real competence in using a programming language
> of course involves familarity with basic language constructs, but whats
> more important is a number of idioms for expressing basic things, design
> patterns for more advanced stuff, thought patterns for how to think
> about programming, mental state control so that you don't approach
> debuging, testing and brain storming e.g. with the same mind set.
>
> So IMO a good programing course progress through a number of well
> choosen examples, that shows how you do typical stuff of increasing
> complexity. And during these examples you not only learn the most
> important subset of the language needed to solve the problems at hand,
> but you also learn the more implicit stuff. ideoms, design patterns,
> thought patterns, efficient attitudes etc.
can't agree more!
>
> --- o0o ---
>
> So why am I telling about this? While browsing
> http://www.orbeon.com/ois/ (Sylvain, please stop cracking their page so
> that people can have look ;) ), I suddenly realized that this is whats
> missing for Cocoon, a user guide that shows how you solve the basic
> tasks that more complicted webapps are built uppon.The current
> documentation is focused on describing so many features as possible and
> based on the implicit assumption that it is good to learn as many
> features as possible.
>
> What we, IMO, need is a list of basic use cases with a description of
> how to implement them in Cocoon, using preferably a small set of tools.
>
>> we should make our understanding of Cocoon explicit before we
>> move on with writing new docs or start to clean up blocks:
>>
>> The real question is:
>>
>> +-------------------------------------+
>> | WHAT IS APACHE COCOON CORE? |
>> +-------------------------------------+
>>
>> I try to give an answer in technical terms:
>>
>> - sitemap & side-effect-free pipelines
>> - continuation based controller
>> - xml templating
>> - forms framewrok
>>
>> based on the concepts of soc and ioc.
>
>
> Agree
>
>> i know this may sound controversial for some of you but we shouldn't
>> confuse our
>> users with old ways of doing things like xsp or pipelines that
>> generate content
>> by directly accessing datasources without an explicit controller.
>>
>> this has to be cleared - our first step.
>
>
>
> Yes, and it should IMO be based on a list of basic use cases, that in
> turn could be used as a base for a user guide as described above. From
> such a list we will, IMO, see that the components that you listed above
> needs some polishing, and some small aditions to really be enough for
> the basic use cases. And this is what I believe we should focus on:
> making our basic tools coherent and good enough for making them easy to
> learn force full enough for solving all basic use cases with. I'm
> working on such a use case list, and I think it is a good exercie for
> all of us to do.
as being said, we should make the tour block following the way how you teach
sftware development + docs explaining the base concepts (pipelines, flow, forms,
xml temlating) to the central point of the docs.
>
>> next step:
>> imo we should strip down Cocoon to a minimum:
>>
>> - cocoon servlet env
>> - basic pipeline components: fileGen, traxTrans, wildcMatcher,
>> htmlSer, xmlSer, cachingPipe, noncachingPipe
>> - flowscript
>> - jxtemplate
>> - cforms
>>
>> everything else should be factored out to other places. based on this
>> micro Cocoon we can start to write docs & beginner tutorials only for
>> this *from the scratch* - every single existing doc should be
>> evaluated, missing docs newly written.
>
>
> Exactly!
>
>> third step: reorganizing the rest.
>
>
> Involving a lot of pruning, (don't worry we don't need to throw away all
> of it and create incompabillity, but things that in practice is
> unsupported by the community, and that is quite a few components, should
> be marked as such).
yes
>
>>
>> (following this path also makes blocks dev easier).
--
Reinhard
Re: Cocoon, a Huge, Scary Beast?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
<snip/>
> before my accident
Havn't heard anything about that, what happended? Hope you are well again.
> I held a 3-days training on Cocoon. the feedback was very
> positive but there was one thing that made me think: after the third
> day they
> told me that really like cForms, flow and pipelines but they didn't
> find this
> information in the docs in the way I told them. as bertrand said, we
> have much more docs than we think but they do not *reflect* Cocoon in
> 2004. you might also say that I have a different view on Cocoon than
> others.
I did a lot of teaching before. Among other things I gave several
courses in C++. The first couple of times I used course materials
developed of others, following the traditional idea that the more
language constructs you learn the better. And that newly added language
features are more advanced and are taught later in the course or not at
all (probably reflecting the teachers layzyness in learning new stuff).
Anyway, even if that was what people expected and that they where happy
with it, I more and more realized that such a teaching methodology sucks
and even is destructive.
If you think about it, real competence in using a programming language
of course involves familarity with basic language constructs, but whats
more important is a number of idioms for expressing basic things, design
patterns for more advanced stuff, thought patterns for how to think
about programming, mental state control so that you don't approach
debuging, testing and brain storming e.g. with the same mind set.
So IMO a good programing course progress through a number of well
choosen examples, that shows how you do typical stuff of increasing
complexity. And during these examples you not only learn the most
important subset of the language needed to solve the problems at hand,
but you also learn the more implicit stuff. ideoms, design patterns,
thought patterns, efficient attitudes etc.
--- o0o ---
So why am I telling about this? While browsing
http://www.orbeon.com/ois/ (Sylvain, please stop cracking their page so
that people can have look ;) ), I suddenly realized that this is whats
missing for Cocoon, a user guide that shows how you solve the basic
tasks that more complicted webapps are built uppon.The current
documentation is focused on describing so many features as possible and
based on the implicit assumption that it is good to learn as many
features as possible.
What we, IMO, need is a list of basic use cases with a description of
how to implement them in Cocoon, using preferably a small set of tools.
> we should make our understanding of Cocoon explicit before we
> move on with writing new docs or start to clean up blocks:
>
> The real question is:
>
> +-------------------------------------+
> | WHAT IS APACHE COCOON CORE? |
> +-------------------------------------+
>
> I try to give an answer in technical terms:
>
> - sitemap & side-effect-free pipelines
> - continuation based controller
> - xml templating
> - forms framewrok
>
> based on the concepts of soc and ioc.
Agree
> i know this may sound controversial for some of you but we shouldn't
> confuse our
> users with old ways of doing things like xsp or pipelines that
> generate content
> by directly accessing datasources without an explicit controller.
>
> this has to be cleared - our first step.
Yes, and it should IMO be based on a list of basic use cases, that in
turn could be used as a base for a user guide as described above. From
such a list we will, IMO, see that the components that you listed above
needs some polishing, and some small aditions to really be enough for
the basic use cases. And this is what I believe we should focus on:
making our basic tools coherent and good enough for making them easy to
learn force full enough for solving all basic use cases with. I'm
working on such a use case list, and I think it is a good exercie for
all of us to do.
> next step:
> imo we should strip down Cocoon to a minimum:
>
> - cocoon servlet env
> - basic pipeline components: fileGen, traxTrans, wildcMatcher,
> htmlSer, xmlSer, cachingPipe, noncachingPipe
> - flowscript
> - jxtemplate
> - cforms
>
> everything else should be factored out to other places. based on this
> micro Cocoon we can start to write docs & beginner tutorials only for
> this *from the scratch* - every single existing doc should be
> evaluated, missing docs newly written.
Exactly!
> third step: reorganizing the rest.
Involving a lot of pruning, (don't worry we don't need to throw away all
of it and create incompabillity, but things that in practice is
unsupported by the community, and that is quite a few components, should
be marked as such).
>
> (following this path also makes blocks dev easier).
>
/Daniel