cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <>
Subject Re: We need a detailed comparison with Struts
Date Tue, 11 Jun 2002 16:03:39 GMT
> Do you think pushing the JSP integration would help Cocoon to have a 
> better acceptance by looking "more standard" ?

Yes.  We need examples of this (I'm not volunteering because I hate 
writing JSPs and JSPs in general).

> Good point here. But can't we make the assumption that the C2 
> architecture is solid and will last a long time ?

Thats a good question.  Can we?  Furthermore, when Cocoon moves on to 
the next iteration of JAXP, what kind of
headaches will someone have deploying the upgrade?  

>>     - Cocoon's codebase is much more complicated than Struts' and
>> depends/uses a lot of 3rd party stuff
> Right, but this 3rd party stuff (in lib/optional) is for features that 
> Struts doesn't provide.

yes, but this feeds into the marketing problem.  Just what IS Cocoon?  

> What about separation of concerns even for a non-multimedia 
> application ? Isn't this a cool feature also ?

What does seperation of concerns (thanks for not abbreviating it) mean 
to my boss?  (Yes I know what it means, but
its not a good high-level perspective.  MVC has caught on.  Many of the 
paycheck signers don't know what it means but
they now know its something they should have...) -- and by the 
way...sometimes I sell struts because its better than the
approach they have and Cocoon is way over their head or seems more 
risky.  I'd still categorize cocoon as an emerging
technology.  Struts has nearly achieved "standard" level.

(yes I think JSP sucks, I hate it, would far rather use Cocoon, but I've 
yet to see case studies for high volume and availability
sites, I see XML-jar-hell as a big problem in some environments, etc, 
etc -- so there are still situations that I'd use Struts for
instead of Cocoon).


To unsubscribe, e-mail:
For additional commands, email:

View raw message