Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41C6D877.8090306@apache.org>
Date: Mon, 20 Dec 2004 14:49:43 +0100
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Cocoon, a Huge, Scary Beast?
References: <329A68716B57D54E8D39FD3F8A4A84DF350EDE@um-mail0136.unimaas.nl>
 <0DE49E8C-5014-11D9-A995-000A958B684A@outerthought.org>
 <41C3063F.1080106@nada.kth.se> <41C5E575.6050107@apache.org>
 <41C6D4B4.9000905@nada.kth.se>
In-Reply-To: <41C6D4B4.9000905@nada.kth.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

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

yes

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


-- 
Reinhard