Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 70477 invoked from network); 3 Dec 2005 01:16:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 3 Dec 2005 01:16:55 -0000 Received: (qmail 94556 invoked by uid 500); 3 Dec 2005 01:16:48 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 93994 invoked by uid 500); 3 Dec 2005 01:16:44 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 93839 invoked by uid 99); 3 Dec 2005 01:16:42 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Dec 2005 17:16:42 -0800 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: 64.151.110.219 is neither permitted nor denied by domain of Ralph.Goers@dslextreme.com) Received: from [64.151.110.219] (HELO mail.gosmtp.com) (64.151.110.219) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Dec 2005 17:17:14 -0800 Received: from [192.168.10.132] (adsl-66-51-196-164.dslextreme.com [66.51.196.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.gosmtp.com (Postfix) with ESMTP id 5F55C29E for ; Fri, 2 Dec 2005 16:45:03 -0800 (PST) Message-ID: <4390F1B7.1000006@dslextreme.com> Date: Fri, 02 Dec 2005 17:15:35 -0800 From: Ralph Goers User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [RT][long] Cocoon 3.0: the necessary mutation References: <43908B84.7070909@apache.org> In-Reply-To: <43908B84.7070909@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Sylvain, I must admit that I only skimmed your post but I will go back and re-read it. But this couldn't come at a more interesting time. I recently got a new manager from outside the company. His first week on the job he basically said "Why aren't we using struts. Everybody uses struts. We should too." Then he talked to some folks in one part of the company (we bought them a year or two ago) who are doing their own thing and want to use JSF. So now he thinks JSF is the way to go. If I don't quit first I am supposed to "re-evaluate" the choice for the presentation framework. Frankly, I looked at JSF it didn't see much I liked. But it has one thing that is appealing and is something that the "other" group insists they need. A stateful flow controller. They don't want to write flowscript or javaflow - they just want to configure the application flow. Frankly, this doesn't seem like too bad of an idea but I just don't like how JSF does it. From what I saw the forms directly invoke the actions which horribly mixes the model and the view. So I did some searching and found Spring webflow. It looks to be exactly what we need. So I am in the early stages of creating a WebflowInterpreter using a refactored portion of the JavaInterpreter. Now this may strike you as somewhat off the topic you were speaking to, but it occurred to me a while ago that the webflow configuration would actually be doing the vast majority of the controller logic. The only thing left in the sitemap would be the pipelines needed to render the views. And I am in absolute agreement that that is all that should be in the sitemap. Ralph >