From: "Andrew C. Oliver" <[EMAIL PROTECTED]> > >> > > > > 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).
<quot>I hate writing JSPs and JSPs in general</quot> - you're not alone in this ;) JSP is somewhat integrated with Cocoon and the JSP samples are available at: http://localhost:8080/cocoon/samples/jsp/ , but I don't think that it's the way to go, cause one of the frequent questions that I've seen in Struts Users list was: "How do I use XML/XSLT with Struts" and a little less often: "Can I use Struts with Cocoon". I don't think that there will be technical problems in Struts - Cocoon tandem, where Struts will be used a the front processor (controller) and Cocoon as the presentation layer. Struts is a rather simple servlet and can simply forward requests to Cocoon after input processing. But I'm quite sure that everything that can do Struts is possible with Cocoon too. > > > > > 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? I can't make such assumption. Cocoon is much more advanced than Struts, but moves very fast and sometimes in a backward incompatible way, while Struts' architecture (maybe because of its simplicity) is quit stable and the core does not change much. > > > > >> - 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? > This one will be solved when Cocoon Blocks are available and every installation can be customized depending on the needs and 3rd party stuff can be provided as blocks and not with the core. > >> > > > > 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. Though, our system architects understand either the MVC or the SoC very well, but the main reason that Cocoon was not choosed for our product is that Cocoon is really an emerging technologie and quite difficult to learn (most of our developers are good in JSP/Servlets, but they have never used neither XML nor XSLT, I don't even mention more advanced/complicated things, such as DTDs, Schemas, entity catalogs, XML namespaces, etc.). > > (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). So, to conclude, we need: - better compatibility (J2EE compatibility)*) - Cocoon blocks - more stability in architecture - more/better learning stuff: docs, tutorials, how-tos - good show cases: success stories, real-life/demo applications and I'd add also a more user friendly interface. Look at the Cocoon welcome page (/cocoon/welcome) - would you think from the first glance that it's a start page of a most innovative, advanced and best publishing system? ;) *)J2EE compatibility - this doesn't mean that we should better support JSP, though. We should allow JSP integration with Cocoon, but not support it very much, IMO. As I could see, the classloader problem was solved. Now the JAXP problem is next. Btw, Struts also uses JAXP, so Struts has similar problems on some app servers (I can say for sure about the IONA Orbix E2A App server, aka IONA iPortal). -- Konstantin P.S. I could speak infinitely about the pros and cons of Cocoon and Struts, but have to be back again to a JSP taglib specification writing :( > > -Andy > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
