Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 16519 invoked by uid 500); 16 Feb 2003 20:59:37 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 16504 invoked from network); 16 Feb 2003 20:59:36 -0000 Message-ID: <3E4FFC75.8080209@apache.org> Date: Sun, 16 Feb 2003 22:02:45 +0100 From: Stefano Mazzocchi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: cocoon usability References: <014901c2d512$d6b774b0$0100a8c0@MAUCHI> <3E4E809E.1090706@anyware-tech.com> <3E4E81E9.9090608@a1.net> <3E4E9849.7040702@anyware-tech.com> <3E4E99B0.1090005@verizon.net> In-Reply-To: <3E4E99B0.1090005@verizon.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Christopher Oliver wrote: > Just wondering, why isn't the "average cocoon user" reluctant to write > complex xpath or xslt code as well as Java? This is a damn good question. I think Cocoon is starting to suffer from 'over-RAD-ness', meaning that people love the fact that they can have something to show their bosses real quick (RAD stands for Rapid Application Development, if you don't know the acronim), then they continue to work on those hacky-shaped RAD mock-ups and create the whole web application from them. Cocoon users tend to think lego-ish so much that they'd rather spend time finding strange and creative ways of mixing the current existing components gluing the pieces with hard-core XSLT, rather then spending a few lines of code to write their own. The reason, IMO, is the fast try/fail cycle of sitemap+XSLT compared to custom java code. XSP improves the speed of the try/fail cycle, but since some major cocoon developers/evangelists dislike XSPs, users get the same impression and run away from them and jump into those pre-build half-baked components we ship. I expect flowscript to bring some balance back on this. Also, one of the compliments I receive from cocoon users is that cocoon forces you to think at what you're doing. Unfortunately, this thinking stops at how to compose the existing components, rather than thinking at how to componentize your web application and *then* look for prebuilt components that do what you need. I expect blocks to build some balance back on this. There is a lot of work to do and I'm not happy about the overall usability of what we have right now. But I think that better build system + flow + block + refactored documentation will do it. Let's get back working. -- Stefano Mazzocchi Pluralitas non est ponenda sine necessitate [William of Ockham] -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org