cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Cocoon, a Huge, Scary Beast? (was: Re: Orbeon vs Cocoon? - Live version available?)
Date Fri, 17 Dec 2004 16:15:59 GMT
Steven Noels wrote:

> 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, 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: 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 :/


View raw message