|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 15
Messages: 15
Messages: 15
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
TSS Article: Cocoon as a Web Framework
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
|
|
|
Message #115845
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Outdated review...
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.
|
|
|
Message #115846
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS Article: Cocoon as a Web Framework
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.
|
|
|
Message #115863
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS Article: Cocoon as a Web Framework
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...
|
|
|
Message #115904
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
XSLT is not complex
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.
|
|
|
Message #115905
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
question
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.
|
|
|
Message #115911
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
question
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
|
|
|
Message #115916
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Cocoon and XSLT preprocessing
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
|
|
|
Message #115918
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS Article: Cocoon as a Web Framework
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!
|
|
|
Message #115925
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Cocoon and XSLT preprocessing
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
|
|
|
Message #115941
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS Article: Cocoon as a Web Framework
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).
|
|
|
Message #115993
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
lack of efficient documentation
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
|
|
|
Message #115994
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS Article: Cocoon as a Web Framework
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.
|
|
|
Message #116003
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TSS Article: Cocoon as a Web Framework
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.
|
|
|
Message #116082
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Adopting Cocoon
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
|
|
|
Message #116087
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Adopting Cocoon
"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)...
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
