cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Cocoon, a Huge, Scary Beast?
Date Mon, 20 Dec 2004 13:33:40 GMT
Reinhard Poetz wrote:

> 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 (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:
>  +-------------------------------------+
>  +-------------------------------------+
> 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.

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.


> 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).

View raw message