cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: [RT][long] Cocoon 3.0: the necessary mutation
Date Sat, 03 Dec 2005 01:15:35 GMT
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

>

Mime
View raw message