cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Cocoon, a Huge, Scary Beast?
Date Mon, 20 Dec 2004 13:49:43 GMT
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 
> (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.
> 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).


>> (following this path also makes blocks dev easier).


View raw message