Return-Path: Delivered-To: apmail-cocoon-users-archive@www.apache.org Received: (qmail 30639 invoked from network); 28 Oct 2003 21:59:18 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 28 Oct 2003 21:59:18 -0000 Received: (qmail 92239 invoked by uid 500); 28 Oct 2003 21:59:00 -0000 Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org Received: (qmail 91893 invoked by uid 500); 28 Oct 2003 21:58:57 -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 Delivered-To: mailing list users@cocoon.apache.org Received: (qmail 91879 invoked from network); 28 Oct 2003 21:58:57 -0000 Received: from unknown (HELO grid4.hypergrid.it) (80.22.58.138) by daedalus.apache.org with SMTP; 28 Oct 2003 21:58:57 -0000 Received: (qmail 19830 invoked by uid 1005); 28 Oct 2003 21:58:52 -0000 Received: from u.cei@cbim.it by grid1 with HyperGrid Anti-Virus System Processed in 0.282721 secs; 28 Oct 2003 21:58:52 -0000 Received: from unknown (HELO cbim.it) (ugo.cei@ymail.it@80.183.30.164) by 0 with RC4-MD5 encrypted SMTP; 28 Oct 2003 21:58:51 -0000 Message-ID: <3F9EE694.6050107@cbim.it> Date: Tue, 28 Oct 2003 22:58:44 +0100 From: Ugo Cei User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: users@cocoon.apache.org Subject: Re: JXForms vs. Woody vs. KISS References: <3F9C3E37.2050807@olegdulin.com> <3F9CF518.2000304@web.de> <3F9D54C7.7090102@olegdulin.com> <3F9D9F54.2030009@cbim.it> <3F9E7D8B.6050206@olegdulin.com> <3F9ED04B.4040103@cbim.it> <3F9EDAEE.6040400@virbus.de> In-Reply-To: <3F9EDAEE.6040400@virbus.de> 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 X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Joerg Heinicke wrote: > On 28.10.2003 21:23, Ugo Cei wrote: > I'm not convinced, Ugo. I'm sure it's possible to have a declarative > flow approach. Only the interpreter or generator must be intelligent > enough. Of course a declarative approach is always somewhat restricting, > but isn't this desired? It works for the sitemap itself. And there are > also workflow markup languages on the run. But such an XML based flow > interpreter engine might be a big thing and independent of Cocoon. Of course it's possible. It's just that XML syntax is so horribly verbose with respect to any decent programming language that it makes my skin cringe. I've seen (well, not seen, but heard of) Cocoon sitemaps growing to be a horrible mess of nested actions, matchers and selectors just because people didn't want to write any Java server-side code. Fortunately, flowscript blows all of this away. Does it require that more than a minimum of server-side code be written? Well, yes, so what? My opinion is that continuation-based flowscript is the greatest thing since sliced bread. It's a revolutionary way to write web apps and we've just started scratching the surface of what can be accomplished with it. It's simply natural that whatever forms framework Cocoon ends up with be intimately tied with the flowscript. After all, most web apps are nothing more than lots and lots of forms. Ugo --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org For additional commands, e-mail: users-help@cocoon.apache.org