cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Cocoon, a Huge, Scary Beast?
Date Sun, 19 Dec 2004 20:32:53 GMT
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


Mime
View raw message