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
