> > >> > > 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). -Andy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
