Return-Path: Delivered-To: apmail-cocoon-users-archive@www.apache.org Received: (qmail 93165 invoked from network); 29 May 2007 12:24:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 May 2007 12:24:29 -0000 Received: (qmail 61501 invoked by uid 500); 29 May 2007 12:24:28 -0000 Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org Received: (qmail 61430 invoked by uid 500); 29 May 2007 12:24:28 -0000 Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: users@cocoon.apache.org List-Id: Delivered-To: mailing list users@cocoon.apache.org Received: (qmail 61418 invoked by uid 99); 29 May 2007 12:24:28 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 May 2007 05:24:28 -0700 X-ASF-Spam-Status: No, hits=2.8 required=10.0 tests=HTML_MESSAGE,INFO_TLD X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [146.64.10.166] (HELO wabe.csir.co.za) (146.64.10.166) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 May 2007 05:24:22 -0700 Received: from cs-emo.csir.co.za (cs-emo.csir.co.za [146.64.10.40]) by wabe.csir.co.za (8.13.8/8.13.8) with ESMTP id l4TCNmmY014603 for ; Tue, 29 May 2007 14:23:49 +0200 Received: from GW-EMO-MTA by cs-emo.csir.co.za with Novell_GroupWise; Tue, 29 May 2007 14:23:48 +0200 Message-Id: <465C3762020000D4000061CF@cs-emo.csir.co.za> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Tue, 29 May 2007 14:23:30 +0200 From: "Derek Hohls" To: Subject: Re: Cocoon Productivity References: <9baa770d0705290314p22a31351l675801b1f7a57093@mail.gmail.com> In-Reply-To: <9baa770d0705290314p22a31351l675801b1f7a57093@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part3B1C2C52.0__=" X-CSIR-MailScanner-Information: Please contact sys-admin at csir dot co dot za for more information X-CSIR-MailScanner: Found to be clean X-MailScanner-From: dhohls@csir.co.za X-Virus-Checked: Checked by ClamAV on apache.org --=__Part3B1C2C52.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Bart I am not sure what a 'jojo' is... but otherwise ***** for your post (5 star grading). I have a feeling this reflects what most of the 'typical' Cocoon users feel (not the power users who even dream in Java... :-) >>> "bart remmerie" 2007/05/29 12:14:28 PM >>> I've been a 'jojo' cocoon user for some years now and a convinced addict. The learning curve is rather steep, but with nices 'plateaus': repeated steps of steep learning followed by rather easy mass-production. What has frustrated me the most are 2 things: lack of evident documentation & upgrading With lack of evident documentation, I basically mean the existence of docs that go just that one step further. for example, in CForms, explaining the insert-bean stuff just a little bit more than just a couple of lines in the documentation. Now you have to combine a lot of sources: mailing lists, wiki, docs, api-docs, ... It's true that the user who persists learns a lot about cocoon when trying to find out everything by her/himself, ... but 'easy to use' should be replaced by something like 'satisfying to learn on your own'. Upgrading to a next version has never been a smooth process so far. I'm currently using 2.1.10 and the YourCocoonBasedProject ant scripts from the wiki. One day, I'll shift to 2.2, but so far, trying to set it up out of curiosity has brought me nothing but frustration. As a cocoon user, learning yet another framework (Maven) is not what I'm looking for. If is can make development easier, I'm interested to learn, but please explain the benefits & basics to get people going before pushing them into a direction (they didn't ask for in the first place). Or replace the 'easy to use' by 'easy to use, ... if you are an experienced user of spring, maven and other related frameworks like hibernate, ...) If cocoon has the ambition to be used, please pay attention to what the (potential) user wants (and documentation might be just one of the priorities). Bart 2007/5/29, Martijn C. Vos :Niels van Kampenhout wrote: > > But I just have a strong feeling that for someone without years of > Cocoon experience it is too easy to screw up. It depends a lot on what you want to do. Cocoon is brilliant at simple stuff. My problem when learning Cocoon was that the documentation on the website discussed XSP, Actions and dozens of other things that you simply shouldn't use. Cocoon is all about generator->transformer->serializer, and everything that fits into that model is easy to learn, once you realise that this is actually what it's all about. > Some people get > it, some need a little longer to understand, others possibly > never will. > This is OK I guess. But once they "see it", the difficulties really > start. Where to go from here? How to develop a real, complex > application with Cocoon? I think the most important thing to realise about Cocoon is that it's a framework of Java components. Cocoon is great at the simple generator/aggregator->transformer->serializer pipeline, but I think all the really complex stuff should be done in Java components as much as possible. In too many projects I've seen people trying to do complex stuff in XSLT, or using flowscript to do all the stuff that the pipeline can't. The problem is that while flowscript is very powerful, it doesn't quite fit in the pipeline way of working, and that makes lots of things more complex than they should be. > Of course all the software engineering principles apply as much to > Cocoon applications as to any other, but most people find it > difficult > to abstract away from the "traditional" frameworks for which they > learned their patterns, and apply their knowledge to Cocoon. > And that's > no surprise, because Cocoon is so big, you can do so much > with it, and you can do it in so many ways. And many of those ways are IMO too complex and too inefficient. I think the basic pipeline is really easy to understand, as are the basics of how XSLT should be used ( i.e: not for logic and calculations, but only for changing the structure of the XML). Everything more complex than that should be done in Java, which immediately makes more use of "traditional" programming experience. mcv. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org For additional commands, e-mail: users-help@cocoon.apache.org -- Bart Remmerie -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to CallCentre@csir.co.za. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --=__Part3B1C2C52.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Bart
 
I am not sure what a 'jojo' is... but otherwise *****
for your post (5 star grading).  I have a feeling this reflects
what most of the 'typical'  Cocoon users feel (not the power
users who even dream in Java... :-)


>>> "bart remmerie" <remmerie@gmail.com> 2007/05/29 12:14:28 PM >>>
I've been a 'jojo' cocoon user for some years now and a convinced addict.
The learning curve is rather steep, but with nices 'plateaus': repeated steps of steep learning followed by rather easy mass-production.

What has frustrated me the most are 2 things:
lack of evident documentation &
upgrading

With lack of evident documentation, I basically mean the existence of docs that go just that one step further.  for example, in CForms, explaining the insert-bean stuff just a little bit more than just a couple of lines in the documentation. Now you have to combine a lot of sources: mailing lists, wiki, docs, api-docs, ... It's true that the user who persists learns a lot about cocoon when trying to find out everything by her/himself, ... but 'easy to use' should be replaced by something like 'satisfying to learn on your own'.

Upgrading to a next version has never been a smooth process so far.  I'm currently ! using 2.1.10 and the YourCocoonBasedProject ant scripts from the wiki.  One day, I'll shift to 2.2, but so far, trying to set it up out of curiosity has brought me nothing but frustration.
As a cocoon user, learning yet another framework (Maven) is not what I'm looking for.  If is can make development easier, I'm interested to learn, but please explain the benefits & basics to get people going before pushing them into a direction (they didn't ask for in the first place).
Or replace the 'easy to use' by 'easy to use, ... if you are an experienced user of spring, maven and other related frameworks like hibernate, ...)

If cocoon has the ambition to be used, please pay attention to what the (potential) user wants (and documentation might be just one of the priorities).

Bart

2007/5/29, Martijn C. Vos <m.vos@hippo.nl>:
Niels van Kampenhout wrote:
>
>  But I just have a strong feeling that for someone without years of
>  Cocoon experience it is too easy to screw up.

It depends a lot on what you want to do. Cocoon is brilliant at
simple stuff. My problem when learning Cocoon was that the
documentation on the website discussed XSP, Actions and dozens
of other things that you simply shouldn't use. Cocoon is all
about generator->transformer->serializer, and everything that
fits into that model is easy to learn, once you realise that
this is actually what it's all about.

>  Some people get
>  it, some need a little longer to understand, others possibly
>  never will.
>  This is OK I guess. But once they "see it", the difficulties really!
>  start. Where to go from here? How to develop a real, complex
>  application with Cocoon?

I think the most important thing to realise about Cocoon is that
it's a framework of Java components. Cocoon is great at the simple
generator/aggregator->transformer->serializer pipeline, but I
think all the really complex stuff should be done in Java components
as much as possible. In too many projects I've seen people trying to
do complex stuff in XSLT, or using flowscript to do all the stuff
that the pipeline can't. The problem is that while flowscript is
very powerful, it doesn't quite fit in the pipeline way of working,
and that makes lots of things more complex than they should be.

>  Of course all the software engineering principles apply as much to
>  Cocoon applications as to any other, but most people find it
>  difficult
>  to abstract! away from the "traditional" frameworks for which they
> &n bsp;learned their patterns, and apply their knowledge to Cocoon.
>  And that's
>  no surprise, because Cocoon is so big, you can do so much
>  with it, and you can do it in so many ways.

And many of those ways are IMO too complex and too inefficient. I
think the basic pipeline is really easy to understand, as are the
basics of how XSLT should be used ( i.e: not for logic and
calculations, but only for changing the structure of the XML).
Everything more complex than that should be done in Java, which
immediately makes more use of "traditional" programming experience.


mcv.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org




--
Bart Remmerie

--
This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice.
Views expressed herein do not necessarily represent the views of the CSIR.

CSIR E-mail Legal Notice

CSIR Copyright, Terms and Conditions

For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice
send a blank message with "REQUEST LEGAL" in the subject line to CSIR CallCentre


This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. --=__Part3B1C2C52.0__=--