Discussions

News: TSS Article: Cocoon as a Web Framework

  1. TSS Article: Cocoon as a Web Framework (15 messages)

    In this article, Neal Ford looks at Cocoon, a web development and publishing framework built around the concepts of separation of concerns and component-based web development. Cocoon introduces component pipelines, where each component specializes in a particular operation, allowing you to 'hook together' components into pipelines without any required programming.

    Read Cocoon as a Web Framework

    Threaded Messages (15)

  2. Outdated review...[ Go to top ]

    It's good to see Cocoon make the TSS front page, but I can't refrain from stating how this review is outdated. First of all, the author is talking about Cocoon 2.0.4, with a 2.1.4 version around and a 2.1.5 version due RSN. But also, and maily, while actions and XSP are still fully supported and part of Cocoon, the newest Cocoon versions, from almost one year now, support a much better approach to web applications, with a powerful form framework and, most of all, web continuations which make building complex web applications a breeze. Cocoon isn't just XSL transformations any more, and I invite everyone to take a look at the newer versions of this powerful framework (mind you, I'm a Cocoon committer so I'm definitely, and willingly, biased).
    Anyway, Neal, thanks for taking the time to write about this subject. I sincerely hope that an updated version will follow up soon.
  3. question[ Go to top ]

    Hi Gianugo,

    In my company we've developed an entire application based
    on cocoon, webservices, stylesheet.

    We haven't use xsp pages, only plain pipelines, generators, transformer, serializer...

    We also have written a partial (very partial) porting of Cocoon on .NET
    because we need our applications to be portable on that platform too.

    Coming to the point, I'm interested in the new features of Cocoon you talk about, form handling, continuation, and the rest. Can you point me to some documentation on the web which describes these new features?

    Thank you very much,
    Carlo.
  4. question[ Go to top ]

    Hi Gianugo,In my company we've developed an entire application basedon cocoon, webservices, stylesheet.Coming to the point, I'm interested in the new features of Cocoon you talk about, form handling, continuation, and the rest. Can you point me to some documentation on the web which describes these new features?Thank you very much,Carlo.
    Carlo,

    I think that the Cocoon site (http://cocoon.apache.org) and, even more, the Cocoon Wiki (http://wiki.cocoondev.org) are good starting points for what you want. Alas, the Cocoon documentation, although improving, is not on par with the framework achievements.

    Another good source of information could be the audio/video/presentation material from the last Cocoon GetTogether, the annual gathering of Cocoon people around the world. You can find it at your favourite Apache mirror (look at http://cocoon.apache.org/mirror.cgi, go to "Material from Events", choose "gt2003" and browse from there. I'd suggest you to start from the "13 - woody flowscript" thing. Should you have any further questions, feel free to contact me: I'm also interested to hear from your recent Cocoon experience.

    Ciao,

    --
    Gianugo Rabellino
  5. I discovered Cocoon at version 2.0. It's always been disappointing that the power of cocoon and it's clean architecture has been overshadowed by frameworks like Struts. Cocoon also has a Portal framework which I believe is going to support portlets.
  6. Cocoon (2.1.4) makes Web development a blast. Its just incredible to read about the many other Web frameworks, which doesn't even fractionally come close to Cocoon's power and elegance. Cocoon for Web, reminds me what the Delphi VCL did for Windows development.

    Like the Delphi VCL, the Cocoon framework is not for the instant Web developer. It takes tine to understand Cocoon's complex engine that is based on the Avalon framework, another technical excellence hardly mentioned as well. Well, for an analogy, Struts is the McDonald's while Cocoon is like your Mom's home cooking.

    Cocoon and J2EE makes an phenomenal force for Web based development projects. Service Oriented Architecture (SOA), Web Services, XML, Portal, Separation of Concerns, Model View controller, Servlets, Object Oriented, Dynamic content, Legacy integration, Excel interface, PDF, Microsoft Word, Star Office, SQL, SAP, MIDI are just some components and supporting technologies you get Day 1 with Cocoon.

    This phenomenal force becomes even greater when used with a rules engine like Jess with Aspect Oriented extensions.

    Now, if only Fortune 1000 companies would hire real developers to realize the Cocoon potential. Perhaps, TSS could recognize Cocoon and give it more exposure like everything else - would be a great service to the Java community...
  7. Like the Delphi VCL, the Cocoon framework is not for the instant Web developer. It takes tine to understand Cocoon's complex engine that is based on the Avalon framework, another technical excellence hardly mentioned as well.
    Actually the thing that distinguished the Delphi VCL from the existing dev. environments at the time was its incredible ease of use and almost flat learning curve.

    I myself picked up Delphi 1 in no time after struggling with VC++'s monstrous MFC and giving up.

    I am about to check-out Cocoon, and sincerely hope the above is a valid analogy!
  8. Like the Delphi VCL, the Cocoon framework is not for the instant Web developer. It takes tine to understand Cocoon's complex engine that is based on the Avalon framework, another technical excellence hardly mentioned as well. Well, for an analogy, Struts is the McDonald's while Cocoon is like your Mom's home cooking.
    I beg to differ. Delphi and its VCL succeeded because of its incredible ease of use and flat learning curve. I looked at Cocoon years ago ( I am biased as well :-) ) and I found it hard to understand, extremely inefficient and totally unsuited for what is was promoted for at the time (web content provision). It was one of the "look at - crap - put away" kind of tools.

    Maybe this has changed now (or I looked at it while being in a bad mood).
  9. lack of efficient documentation[ Go to top ]

    I agree with that.
    I have studied Cocoon for several years, and I found the documentation on the website is not well-orgnized and completed (maybe I shouldn't so strict on an open source project), but on the other side, frankly, to fully understand and making use of Cocoon, one need many other knowledges like XML (every thing with XML like namespce, xlst, xpath...) / Java / J2EE / web technologies.
    Maybe that why Cocoon is hard to handle.
    Thanks for the great work!

    William Zhu
  10. XSLT is not complex[ Go to top ]

    Neal has provided a useful overview of Cocoon, and I look forward to further articles on TheServerSide about this system.

    As a "user" of the framework for a few years, I would like to disagree with one of the conclusions he draws as to it suitability for web development projects, where he says "XSLT is a complex transformation language and not much expertise or tools exist to mitigate that. It adds a significant layer of complexity to your web application to add transformations to your content generation."

    My opinion is that there no point in adopting XML if you are not willing to learn how to process it. XSLT is the tool designed to do just that. My experience with using XSLT over a few years leads me to these conclusions:

    1. XSLT is NOT complex if taught/learnt correctly. The key concept to it is that of recursion - "grok" that and the rest is simple. XSLT can also be learnt
    and applied in a layered approach - the fact that you are almost forced to have "subroutines" (matches) for each tag, leads you to create a logical sequence of code to process and transform the input files. The result of your work, over time, can LOOK complex to someone who has not been not been involved in its creation from the start - this might perhaps be a down side.

    2. The tools for using XSLT can be very basic; because it acts more like an interpreted language it is relatively easy to make and test changes. It also works with a simple command line tool as well as part of a bigger framework such as Cocoon. I believe that Altova's XMLspy allows debugging of XSLT but have not tried this as yet.

    3. XSLT does not "add complexity". My experience has been that it leads to code reuse and is strongly biased towards developing "patterns" of logic that can easily be applied in new situations. Indeed, most of my work in the more recent Cocoon sites I have worked on has NOT been in writing XSLT but in understanding flow logic and working on the "user view" of the site.

    I hope this provides another perspective on what otherwise might be perceived to be a "problem" with Cocoon.
  11. Cocoon and XSLT preprocessing[ Go to top ]

    Does Cocoon supports XSLT in preprocessing phase rather then using it for post processing XML content into HTML.
    For example could Cocoon XTP pages be fistrly transformed (styled) with XSLT into XHTML (with aditional tags for later embeding dynamic content). This way costly XSLT processing is not done per every request and a lot of CPU cycles will be saved.

    For example, XSLT preprocessing of JSPs is a very powerfull technique that has both, flexibility of XSLT and performance of JSPs and is not supported by any web framework I know.

    Mileta
  12. Cocoon and XSLT preprocessing[ Go to top ]

    Does Cocoon supports XSLT in preprocessing phase rather then using it for post processing XML content into HTML.For example could Cocoon XTP pages be fistrly transformed (styled) with XSLT into XHTML (with aditional tags for later embeding dynamic content). This way costly XSLT processing is not done per every request and a lot of CPU cycles will be saved.For example, XSLT preprocessing of JSPs is a very powerfull technique that has both, flexibility of XSLT and performance of JSPs and is not supported by any web framework I know.Mileta
    What you describe as preprocessing can easily be achieved with Cocoon as it uses a pipelining architecture at the core of its XML processing engine. Transformations at any stage of the pipeline can be cached, so that on the next request the pipeline processing just picks up from the last stage cached.
    Even better you don't even have to deal with that as Cocoon's caching mechanism (usually) does automatically for you.
    For a description how Cocoon's caching works look at:
    http://cocoon.apache.org/2.1/userdocs/concepts/caching.html

    Objectively things are not THAT easy with XSP as you have to account for caching yourself, have a look at:
    http://wiki.cocoondev.org/Wiki.jsp?page=XSPCachingWithCocoonHEAD
  13. Cocoon may be cool and have its supporters, but is it really suitable for a generic web framework? If you have a lot of xml already in your application, or you're dealing with something document-centric (like a publishing application, something that's content driven), then I suppose it makes sense. But for most data-driven web applications, either transactional or for information sharing, it seems to me to not be the best solution. Sort of an "everything looks like a nail" kind of tool.

    Consider that you have an application starting from ground zero, and it's purpose is to share contact information in a company (a sort of simple CRM). You can create Java objects for your contacts and users, map them to database tables, and then slap a framework like struts or webwork or even just the velocity servlet on top of that, and get up and running relatively quickly. I'm not a big fan of struts, so my choice would be webwork. In that case, it seems like you're addressing each layer of the application with the appropriate tool: a database to store your data, Java objects to encapsulate your data and business rules, and an MVC framework on top, to provide presentation and coordinate working with the business objects. Your presentation could be web pages, done either as JSP or velocity. Assuming your intended output was for the web, these JSP or velocity pages wouldn't look that different from blank, non-dynamic web pages in a simple application.

    Now consider cocoon. I haven't looked at it in a few years, but despite improvements to the core, I think I still understand the gist of it; if not, please correct me. You have your database and your java objects. You then need to provide some mechanism to serialize them into XML, since everything in cocoon (AFAIK) centers around XML. Then you need to create XSLT transformations to turn them into web pages. The XSLT looks very little like the resultant HTML, so it's difficult to debug. XSLT (despite what others say about it) is a horrible language to program in and maintain; nearly every other language used in web programming I've encountered is easier to pick up and learn, and most are certainly easier to debug. One proponent of XSLT here said that it's not that bad, and that he _thinks_ that XMLSpy can debug it. Not very encouraging. So you've already added work by having to serialize your business objects to XML, then you've got to deal with XSLT, which again looks very little like the resultant HTML (so it's hard to get a feel for what's going on at an initial glance) and it's much harder to get people to work with and understand.

    Then you get the performance hits. You have to serialize or deserialize with every operation, in addition to reading and writing from the database. That's a performance hit. Then you've got to do an XSLT transformation. Last I worked with XSLT, it was not the fastest arrow in the quiver. Unless you're using a C++ version of Xalan or something similar, I doubt that's changed much (due to the nature of what XSLT is doing). And good luck getting the C++ version running as part of your web application. Compare that to the relatively fast speed of JSP rendering (especially on good servers like Orion), or even Velocity, which just screams. I don't have exact numbers but I would be really interested in seeing a performance comparison. I would expect to see Cocoon (or any XSLT-based framework) dragging behind other frameworks.

    I'm sure this will raise hackles among the Cocoon zealots. Understand that I'm not saying that Cocoon is poorly designed, or that it is useless. It seems like a fine framework for what it is. But I think that far too often, it is pushed as a framework suitable for everyday purposes, and it's not, IMHO. For those types of applications where document-centric processing is necessary, or where you already have XML sources for just about everything, or where you need to do some funky things that only XSLT (and one of the few XSLT "wizards" out there) can do, then it's a good choice. But for most other business applications, such as transactional processing or data-centric information sharing, I think it's not the best choice and that it in fact adds unnecessary complexity and performance hits.
  14. Now consider cocoon. I haven't looked at it in a few years,
    You should. Cocoon not only improved but expanded from the XML publishing to the webapp space.
    but despite improvements to the core, I think I still understand the gist of it; if not, please correct me.
    Just a few corrections :-)

    XSLT isn't Cocoon's only "templating" mechanism. There are a bunch of templating engines available (including JSP and Velocity). JXTemplate (which partially borrows from JSTL) currently being the most popular one. Cocoon's view layer is based on SAX pipelines. That means there is no serialize/deserialize step at every stage (if being executed at all, see my other post about the caching system). Each transformation step may be based on XSLT or use any other of the >30 (more or less useful :-) available transformers (and it's not that hard to build a custom one). It's a piece of cake to build a multi-dimensional, multi-layered view. Or your view layer may be as simple as just using your favorite template engine and having no transformation step at all. In fact you can build your Cocoon application without a single XSLT stylesheet (however you would sacrifice some of the power coming from the strict seperation of concerns).

    What you call data-driven webapp might be build around a MVC model based around web continuations (a very powerful concept recently (and for sure continuing to) being picked up by other frameworks which I don't want to elaborate now) and Cocoon's comprehensive forms framework (recently renamed CForms and still in a state of flux).

    Cocoon doesn't impose any XML on the model or the controller.

    It is true that the learning curve is steep. But IMHO if you (or your company) are in the webapp business it's certainly worth the effort to have a look at it. Yes the documentation - although being improved recently a lot - still is suboptimal.

    That being said, if you don't want to deal with XML and XSLT (it's certainly not a good idea to build a Cocoon application while trying to stay away from XSLT) and if you are fine with your JSP approach, stay with that. There is no reason to switch to Cocoon.
  15. Adopting Cocoon[ Go to top ]

    Cocoon may be a very impressive framework, but this is what I'm hearing:

    - it has a sharp learning curve
    - the documentation is poor
    - it is not advisable to use it without using XSLT

    I have about two years of XSLT under my belt, last time I used it was 2002, and I can't imagine a situation where I'd ever want (not need, but want) to use it again. It was without a doubt the hardest "language" I've ever had to write. Debugging it was an absolute nightmare. Simple things like making every other row in an HTML table a different color were extremely difficult. Maybe the language has some new commands to make it easier, though I'm hoping I never have to find that out.

    I have no doubt that there are some situations where Cocoon is a great fit, but I am skeptical that it could really gain acceptance as an everyday webapp framework. I'm a Webwork user, and it's hard to imagine what benefits I would get from Cocoon that would be worth the aforementioned negatives.

    Rob
  16. Adopting Cocoon[ Go to top ]

    "I'm a Webwork user, and it's hard to imagine what benefits I would get from Cocoon that would be worth the aforementioned negatives."

    Well, of course, this is "your" opinion. My opinion is - I can't imagine developing a Web application without the benefits of Cocoon instead of all the other mickey mouse frameworks. Its just that simple, like you can go to McDonald's and eat all the Big Macs you want, its your body (mind)...