Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 97759 invoked by uid 500); 9 Sep 2002 09:55:38 -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 97748 invoked from network); 9 Sep 2002 09:55:38 -0000 Message-ID: <3D7C70AF.966C5896@apache.org> Date: Mon, 09 Sep 2002 11:58:07 +0200 From: Stefano Mazzocchi X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [control flow] changes and new sample References: <384121EC-C300-11D6-9874-00039398D61E@apache.org> <3D7BB9A2.9030308@anyware-tech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Sylvain Wallez wrote: > I like very much this as it's the name used > traditionnaly in the MVC pattern. Cocoon shouldn't invent a new word > (map:flow) to designate a well-known concept. MVC is much hyped and is a > "magic word" for many customers (see how many of them want Struts > because it's MVC). And how many of them will *not* want it in the future when they realize the MVC pattern was invented for a statefull system and used by workforces with coherent skills? Please, people, let's try to have a little more perspective than this. We should *not* market Cocoon directly, we should think, implement and, hopefully, doing so, innovate. My point is: since there is *no* explicit and one2one way to map an MVC pattern on top of Cocoon, I see no reason why to force the 'flow' of our application to become a 'controller'. Think about it and try *not* to think at MVC: which is more abstract as a concept, a flow or a controller? You say that attaching a 'controller' label to the flow layer makes it easier for people to understand and easier for us to market Cocoon. But if this is true *now*, I wonder if this is going to be true tomorrow when more and more people realize that Strust is just *a better way to use JSP*, not a better way to write a web application. In my view, differentiating between 'flow' and 'controller' is healthy and possibly important even for marketing: 1) once people realize the concept of continuations, they'll start seeing MVC as a "poor man" technology invented to make it easier to write JSP-based applications, but the world doesn't stop at J2EE and many are already realizing it now (see the anti-EJB riots that are popping up everywhere). If that happens, how can we differentiate from that if our flow layer is still called (and perceived as) the 'controller'? 2) flow is a broader concept that includes workflows. It's pretty easy to imagine a stylesheet that transforms a 'workflow description language' markup (already existing and many workflow-describing tools are already exporting it) into a flow script. If we are talking about marketing, the ability to automatically describe a flow of a web application using a visual workflow editor is twice as killer as marketing us as MVC. 3) Cocoon is about separations of concerns. MVC is one way of separating concerns and was *not* invented for stateless distributed environments. 4) Marketing should *never* drive an open technology. The need to do the right thing should be our engine and I think that naming a new concept with a new term is appropriate because it will become recognized (think at 'sitemap') So, to resume, this is my proposal. With this we gain: a) we can still market Cocoon as MVC (or MVC++, MVC# or whatever) we just need a document explaining the different ways that Cocoon patterns can be used to implement the various parts of MVC. b) when MVC degrades because it shows its limits, we are not tight to their market because we are more abstract. c) the flow cannot only work as a controller but can work as a procedural way to map any transition-part of a FSM. This includes workflows and might include distributed web services. I know it would be easier *right now* to name it 'controller' and forget about all the above, but I ask you to think in 5 years from now, then place your vote. I vote for . -- Stefano Mazzocchi -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org