TSS Book Review: The Art of Java Web Development

Discussions

News: TSS Book Review: The Art of Java Web Development

  1. TSS Book Review: The Art of Java Web Development (58 messages)

    The "Art of Java Web Development" (Manning) is a guide to various topics required for state of the art web development. In this review, Kris Thompson, a Java framework expert, walks us through the different parts of the book. He discusses the evolution of frameworks, the various frameworks reviewed (Struts, Tapestry, WebWork, InternetBeans Express, Velocity and Cocoon), and framework best practices.

    Read the Book Review of The Art of Java Web Development

    Also visit the Art of Java Web Development home page on Manning's site

    Threaded Messages (58)

  2. Is Struts embarrassing?[ Go to top ]

    The author says, "I don’t publicly admit to knowing Struts". Is this because of embarrassment or is it because he doesn't know how to use it?

    Is Struts that bad? I kinda dig it. Is WebWork that superior to Struts that I should trash the time I have invested in Struts and pick up WebWork instead?

    What are those "other arguable issues"?

    Just curious.

    Michael
  3. Is Struts embarrassing?[ Go to top ]

    The author says, "I don’t publicly admit to knowing Struts". Is this because of embarrassment or is it because he doesn't know how to use it?


    This is more humor then anything.
     
    >
    > Is Struts that bad? I kinda dig it. Is WebWork that superior to Struts that I should trash the time I have invested in Struts and pick up WebWork instead?
    >

    It's not that bad that if your already using it don't throw it away. Hey, at least your using an MVC because it is amazing how many folks choose not to on complex applications. Is WebWork superior? Argh, I really don't want to turn this into another Struts vs. WebWork debate because in the scope of web frameworks they are more similar then they are different.
  4. Is Struts embarrassing?[ Go to top ]

    It's not that bad that if your already using it don't throw it away. Hey, at least your using an MVC because it is amazing how many folks choose not to on complex applications. Is WebWork superior? Argh, I really don't want to turn this into another Struts vs. WebWork debate because in the scope of web frameworks they are more similar then they are different.


    Oh, please :), can we turn it to another framework debate? Especially now we have; Struts, WebWork, Springframework, Shocks, Cocoon, Barracuda, Tapestry, Velocity, and coming soon: Hivemind. what else? May be there should be a project on sourceforge that would just be a repository of the same applications (not HelloWorld type of app) implemented in some/all of the available Open Source frameworks. This way anytime this topic comes up, just sendRedirect to the SF site. Any takers?

    -Mohammad.
  5. I like the way you're think'in[ Go to top ]

    Oh, please :), can we turn it to another framework debate? Especially now we have; Struts, WebWork, Springframework, Shocks, Cocoon, Barracuda, Tapestry, Velocity, and coming soon: Hivemind. what else? May be there should be a project on sourceforge that would just be a repository of the same applications (not HelloWorld type of app) implemented in some/all of the available Open Source frameworks. This way anytime this topic comes up, just sendRedirect to the SF site. Any takers?


    That would be great! Wait, this has already been done.

    Any takers on filling in the gaps on that project? Still need Spring, Shocks, Rife, and many more?
  6. Is Struts embarrassing?[ Go to top ]

    May be there should be a project on sourceforge that would just be a repository of the same applications (not HelloWorld type of app) implemented in some/all of the available Open Source frameworks. This way anytime this topic comes up, just sendRedirect to the SF site. Any takers?


    http://waferproject.org/index.html
  7. spring?[ Go to top ]

    just saw the waverproject. Think it is a great repository, but where is the spring framework?
    maybe I will join this effort. Keep that good work up.
  8. spring? Excellent!!![ Go to top ]

    just saw the waverproject. Think it is a great repository, but where is the spring framework?

    > maybe I will join this effort. Keep that good work up.

    The weblog has not been developed using Spring yet and to the best of my knowledge no one has yet to have signed up for that task.

    Join the mailing list on the wafer project or feel free to email me at kris at kristhompson dot us and maybe we can brew up a team for building with Spring.
  9. spring?[ Go to top ]

    you mean where is it located?

    main site:
    http://www.springframework.org

    downloads:
    http://sourceforge.net/projects/springframework

    I recommend checking out Spring whether you want to use it's MVC or not. Its a light framework that actually works well with others (such as Struts)


    -jp
  10. Is Struts embarrassing?[ Go to top ]

    Hi,
    I would really like to know as to whether struts is just good enough to be retained in existing applications as a MVC implementation....does it not hold anything for the future.

    I am on the verge to implementing a new framework and have to take up some open source for that....
    What would you suggest in such a scenario ???

    Regards
  11. Is Struts embarrassing?[ Go to top ]

    The author says, "I don’t publicly admit to knowing Struts". Is this because of embarrassment or is it because he doesn't know how to use it?


    But there must be a mistake. The author IS "a Java framework expert". How could he possibly not know every single detail about Struts?

    Sheesh.

    Sandeep.
  12. OK I'll admit to knowing Struts having used Struts for two projects then moving onto Expresso (a Struts extension) for two more projects. My intent was not to bash Struts. Sorry folks.
  13. Is Struts embarrassing?[ Go to top ]

    An excerpt from the author's (the reviewer, that is) weblog. This is from a post as recent as Nov 07 2003.

    "...Which framework should I target next? I feel that I need to move on past Strut-ish frameworks and try something way different like Tapestry, or maybe a declaritive based framework or maybe something AOP-ish, or maybe something geared to webservices..... I don't know. Give me some input folks..."

    Um, Dion, why would you categorize this author as a "Java frameworks expert"? Having cataloged frameworks is not the same as having mastered them.

    Sandeep.
  14. Is Struts embarrassing?[ Go to top ]

    I have used Struts on three comercial web site implementations over the last three years and I consider it a good framework. Last month we re-launched our web site http://www.virginmobileusa.com and as part of the project we moved the presentation layer from BEA Webflow to Struts 1.1. This was the first time I had used the new version and it rocked. Good documentation is also not hard to find with a whole list of books and on line articles.

    Of course it is not perfect but I would not consider your time wasted :-)

    David
  15. Is Struts embarrassing?[ Go to top ]

    we moved the presentation layer from BEA Webflow to Struts 1.1


    BEA use Struts in its new pageflow components (successor to webflow) which wrap Struts components. Workshop 8.1 uses annotations in javadoc and XDoclet style code generation to truly hide the ugliness of Struts.
  16. Is Struts embarrassing?[ Go to top ]

    I would advise people to think long and hard before using a vendor MVC product. We are running Weblogic 6.1 and Web Portal 4.0 (webflow) and wanted to look at moving to Weblogic 8.1 early next year. Basically the migration called for a whole new re-write of the web tier to use BEAs so called Struts+. I decided against using the BEA stuff as it seemed to me to be repeating the mistake the person who decided on Webflow made. If there is a good none vendor open source solution out there use it or be doomed to re-write your web app every time you wish to do a vendor required upgrade.

    David
  17. I am curious: why are you better off using an open source MVC library than a commercial one from a vendor? Aren't you facing the same risk of changing implementation? I know you are burned by WebLogic Portal, but to me that is a commercial Portal Server product, not just a MVC framwork. They changed from webflow to pageflow to use Struts, which IMHO is a step in the right direction. Expect more changes when they move to be JSR 168 Portlet Spec compliant. Your problem is one encountered by all early adopters of a particular technology, not because someone made a bad decision on a MVC framework.
  18. "I am curious: why are you better off using an open source MVC library than a commercial one from a vendor? Aren't you facing the same risk of changing implementation"

    To a much lesser degree. You have control over when you want to upgrade an open source framework. With a vendor implementation everything starts to depend on each other. Want to upgrade the app server well that requires you to change all this vendor specific stuff.

    "I know you are burned by WebLogic Portal, but to me that is a commercial Portal Server product, not just a MVC framwork."

    Of course Portal includes a lot of stuff beyond simple MVC. There are projects out their that use Struts for their base MVC framework and then use Portal functionality to implement things like discount management.

    "Your problem is one encountered by all early adopters of a particular technology, not because someone made a bad decision on a MVC framework."

    I feel you can out some of the blame on early adoption but at the end of the day we should have gone for a much more standard MVC framework and just used the Portal in areas we needed vendor extensions.

    David
  19. BEA Portal framework vs. Struts[ Go to top ]

    Having worked on three different BEA Portal versions and also on struts. I have a feeling that choosing the BEA's portal framework would prove to be a mistake. There are lot of changes from version 4 to 7 and now again 8.1. My experience tells me that they are trying to adopt all the latest J2EE technologies and they do not want to be left out which results in a lot of new changes/features in the new version and every other version is different from the previous one.

    We implemented two web applications and now when the client wants to upgrade it to the latest version in my view only path to take is a whole new implementation. I found weblogic portal to be very buggy too. I would recommend going for a framework like struts and using the in built libraries if you need them. If you are not using a lot of features of inbuilt libraries I would prefer to write those components on my own. You may thing why i want to reinvent the wheel...etc. etc... I can explain this with an example. Weblogic portal I thought implements some of the intefaces which are very open and transparent. That is not the case. I was working with commerce server component of it and to my surprise the shopping cart is not a ejb...I could see a home implementation for it but it was still not a ejb. I openend up the ejb jar file and wanted to modify some of the security permission but that was not possible. I was a proprietary implementation. Its has a very steep learning curve too.

    These are some of my comments. I have burnt my hands and so do not want other people to suffer.

    -srini
  20. BEA Portal framework vs. Struts[ Go to top ]

    Maybe Weblogic 9.2 will drop Struts and use Tapestry based on the comments in this forum.

    (Sorry couldn't resist).

    David
  21. Take my Tapestry ... please![ Go to top ]

    In all seriousness, that's what the Apache Software License is all about. If BEA wants to make use of Tapestry as part of the WebLogic server, that's fine. If they want to take the code, modify it and call it "BEA Web Components" or something ... that's fine too (though I'd rather, in such a hypothetical scenario that they work with us rather than fork the code).
  22. ...from BEA Webflow to Struts 1.1[ Go to top ]

    we moved the presentation layer from BEA Webflow to Struts 1.1. This was the

    > > first time I had used the new version and it rocked.
    >
    > BEA use Struts in its new pageflow components (successor to webflow) which wrap
    > Struts components. Workshop 8.1 uses annotations in javadoc and XDoclet style
    > code generation to truly hide the ugliness of Struts.

    I think it's the other way around: BEA needs Struts to hide the ugliness of WL Portal. For $50K per CPU you basically get Struts and a bunch of BEA extensions to lock you in so you wouldn't run away (when you realize you've been taken). IMO, go with Struts, if you can.
  23. Is Struts embarrassing?[ Go to top ]

    I have used Struts on three comercial web site implementations over the last three years and I consider it a good framework.

    <SNIP>
    we moved the presentation layer from BEA Webflow to Struts 1.1. This was the first time I had used the new version and it rocked. Good documentation is also not hard to find with a whole list of books and on line articles.
    >
    >
    >
    > David

    Agreed!

    I have been using Struts for a while and it is awsome.
    A good example app is PetStore 3 on iBatis.com

    I consider Struts best practices and it is VERY, VERY popular. Most clients know it, and ask for it, ex: "have you used Struts on a project?"

    Since it is open/free, vendors do not like it, they would rather you use a propriatory framework (such as JSF, or whatever IBM or BEA have)

    In future versions, Struts will swith to using chains, an upgrade to resource bundles, EL and hopefully IoC or Services.

    .V
  24. Is Struts embarrassing?[ Go to top ]

    For all the great goodies in Struts, it has several _fundamental_ flaws in its design. The biggest one is its lack of components and, as a result, its obsessive page-orientation. Since you are essentially discouraged to generalize common stuff in pages, writing web applications in Struts is like writing code in a programming language that lacks functions -- something that has long been considered a particularly bad practice in the programming world.

    Both Tiles and JSF attempt to resolve this to some extent, which clearly underlines the need for such functionality and its omission in the original Struts design. The problem with JSF, however, is that it requires a lot of effort -- creating an encapsulated component that can handle events independently, etc. is a major pain. You can extract commonality with it, but the effort involved means that the developer would not normally build the application in that way, and this automatically translates to lost scalability, maintainability, and reuse as a result. Contrast that with how things work in a framework that has been designed from the ground up with this in mind.

    But please don't take my word for it -- please create a page out of components in Tapestry and then try to do the same in Struts/JSF. Once you are done, it is unlikely that you would ever want to work in the second way again. If you care about better productivity, try that.
  25. Is Struts embarrassing?[ Go to top ]

    I'd love to try out tapestry but its horribly out of date documentation always stopped me
  26. Tapestry tutorial[ Go to top ]

    I'd love to try out tapestry but its horribly out of date documentation always stopped me


    There's a tutorial avaible for tapestry, with screenshots and all...

    Here's the link: http://www.dorffweb.com/index.htm?page=taptutorial

    Many thanks to Kevin C. Dorff for this work.

    Also there's a book coming next month: Tapestry in Action by Howard M. Lewis Ship

    No more reasons to stick with Struts.
  27. Is Struts embarrassing?[ Go to top ]

    IMHO - having used struts since v0.5 I think a lot of people here have missed the point of struts - struts is a not an application framework - it is a tool that allows you to implement the 'View-Controller' component of MVC in a web-based environment. It addresses very few of the other mandatory components of an application framework - ie. code layering and abstraction, logging, security, persistence, etc.

    The benefits I see of struts over heavyweight frameworks such as Tapestry is that it is very quick and easy to learn and allows you to have html/web designers build your presentation layer with minimal training in struts tags. If you want more complex components, build more taglibs (eg. the open source display taglib). Tapestry (as I see it) is an implementation of Swing for web pages - ie. it is a nice OO architecture but requires a lot of learning and common component construction to make it useful.

    It looks to me like most of the objections over struts are more issues with JSP and request based paradigms instead of event based paradigms.

    The only think I think could have been done better with struts is the implementation of forms - these could have been implemented as an interface but their existing implementation reduces their re-usability as value objects, etc. In addition, the validation methods (even with the new 1.1 validator stuff) don't give you a lot of flexibility for implementing multi-page workflows - they very much tie you to a Wizard style flow.
  28. "The benefits I see of struts over heavyweight frameworks such as Tapestry is that it is very quick and easy to learn and allows you to have html/web designers build your presentation layer with minimal training in struts tags."

    But with Tapestry, web designers need NO training. All they have to do is be aware of tags marked with "jwcid", and even then they can control certain aspects of their behavior.

    I like having my pages as HTML templates. I can modify look-and-feel with ease and I don't worry about a non-Java programmer modifying it. I can demonstrate how a template is going to present itself in a generalized sense, and I can even plug in static variables to mimic the Tapestry output. My actual user-viewable presentation layer can be demonstrated without the need for a web-server. It's flexible and extremely elegant.

    The learning curve is steep because it lacks documentation, but this is being remedied. Tapestry in Action is coming out soon, and I know there are plans for updating some of the documentation on the website such as tutorials and user guides. Though the API's and Component References are all current.

    However, I suspect that once more of the documentation is written and we begin to see more concrete documented examples outside of "Hello World" a lot of that learning curve will be reduced.

    Not only that, but while Tapestry might be hard to learn, it strikes me as easy to master. Much of my struggle is having to think differently than I normally do, and accept that sometimes the answer to a problem isn't as complex as I'm used to.
  29. JSP 2.0 : why bother with Tapestry[ Go to top ]

    I have been playing with TomCat 5 and its JSP 2.0 taglib support .

    I have also been looking at a bunch of other technologies incuding FreeMarker, Cocoon and Tapestry.

    My conclusion is that with JSP 2.0 support in Tomcat 5, I think Struts + Tiles + JSP 2.0 Taglibs pretty much covers all my Java web development needs. If I needed WML support, then I might consider Cocoon or JSP.

    I would be interested in hearing how Tapestry matches JSP 2.0 taglibs.
  30. It's the other way around; JSP 2.0 still hasn't caught up to where Tapestry was a year or two ago.

    The JSP expression language is not as easy or as powerful as OGNL (used by Tapestry and WebWork).

    Tapestry components are still easier to build and use than JSP taglibs.

    Tapestry component parameters are strongly typed and allow components to both read value from and write values to bound properties.

    Localization is still an afterthought in JSP 2.0. Its a core aspect of Tapestry.

    JSP 2.0 is just a templating technology. Tapestry is a full-featured web application framework. It manages server side state, it constructs URLs and decodes them (in later requests), it dynamically generates JavaScript, it allows components to be packaged as JAR files properly (even when they contain images or other assets), it has EXCEPTIONAL error handling and reporting including line-precise error reporting. And all of this occurs with a minimal amount of code (I mean really tiny amounts of code), minimal amount of HTML markup (we call it "invisible instrumentation"), and lean-and-mean XML specification files.
  31. I like the concepts of Tapestry but I have an issue with its scope.

    IMHO Struts does a great job with MVC -- it is the presentation tier of Struts that is a point of pain for me and perhaps others as well. The problem is that Tapestry while trying to solve the presentation tier problem inflicts a learning curve. Unlike other presentation tier technologies such as Velocity or Freemarker, Tapestry is uncompromising -- you cant use Tapestry in an existing Struts web application to replace your JSP.

    It would be nice to see Tapestry evolve as an alernative to JSP but without bringing baggage in the form of a whole new framework.
  32. I like the concepts of Tapestry but I have an issue with its scope.

    >
    > IMHO Struts does a great job with MVC -- it is the presentation tier of Struts that is a point of pain for me and perhaps others as well. The problem is that Tapestry while trying to solve the presentation tier problem inflicts a learning curve. Unlike other presentation tier technologies such as Velocity or Freemarker, Tapestry is uncompromising -- you cant use Tapestry in an existing Struts web application to replace your JSP.
    >
    > It would be nice to see Tapestry evolve as an alernative to JSP but without bringing baggage in the form of a whole new framework.

    That would not be Tapestry, that would be something else. Tapestry isn't a templating system, its a number of specific technologies for creating an entire web application. Removing any of these aspects cripples the entire system.

    I'm currently doing some consulting on an existing application, in Struts 1.1 (my prior job at WebCT was Struts 1.0). It's my deal with the devil (paying the bills while I get the independent consultant role up to speed). In any case, its not like I make comparison of Tapestry vs. Struts (vs. pure Servlets) in a vacuum. I get to see, day by day, not only my own code, but the code of other smart people around me, who happen not to be UI guys --- they just don't have the breadth of experience necessary to navigate the minefield of servlet/Struts development. So I see a huge number of anti-patterns that just don't happen using Tapestry.

    Even in the sections I've coded myself, from scratch, I'm appalled at just how much code is necessary to get simple things done.

    I've seen a number of people over the last three years who have voiced exactly the same opinion as you -- many just dropped off the radar, but those who've stayed have had their eyes opened to just what Tapestry offers; you need to really get into it to truly see just how much is going on and how elegant and seamless it is.

    It's unfortunate that this myth about the Tapestry learning curve has gotten out of control. The problem isn't specifically the learning curve of Tapestry --- it's the fact that the existing documentation hasn't kept pace with all the features in 3.0 meant to tame that learning curve. I've been overburdened writing Tapestry in Action while working full time (+) jobs. The upside is I'm very pleased with the book, and the MEAP (online PDF version) of the first couple of chapters will be available very soon (this week or next, with luck).
  33. I guess what would immesely help would be a tutorial like "Tapestry for Struts addicts" -- it would help us to get started with what I am beginning to believe is a better approach.

    Thanks for your feedback!
  34. JSP 2.0 : why bother with Tapestry[ Go to top ]

    Well, since you asked I think there are several problems.

    JSP's were designed with the promise of easy MVC design and to introduce an easy way to do dynamic web content that would allow web designers to design and developers to develop.

    Neither of these things happened in reality. So Struts was created with similar goals.

    While Struts did a much better job of enforcing MVC design, it introduced a lot of complexity even for relatively simple tasks. Not to mention, you still have to train web designers to understand what the tags are, and even then they may not be able to touch them aside from moving them around, in which case hopefully it wouldn't break the page formatting. Also, you could still abuse scriplets if you were so inclined.

    What became a reality was this constant passing back-and-forth of HTML templates between design and development teams. It's either designers having to learn a part of the developer's jobs or developer's learning part of the designer's job. While there are developers who can design and designers who can develop, it's not exactly a common occurence since these two specialities have very little in common.

    When I see things like "I can use Struts+Tiles+JSP 2.0 Taglibs" I kind of chuckle. While you have to learn three different, albeit related, technologies I just have to use Tapestry. With this kind of mindset, is it any wonder companies are looking to ASP for their front-ends?

    When I took my current position, I decided to use ASP to develop the front-end piece for similar reasons. Struts is too slow and cumbersome and I was looking at a rapid-development schedule which meant doing a lot of changes on the fly with little notice. It also meant rapid prototyping of new components with quick turnaround into production worthy code. The thought of trying to meet their rapid design requirements in Struts scared me enough to go the ASP route, simple because I believed it would be faster to learn ASP then try to develop in Struts. Plus I was not looking forward to the tedium of writing all the code necessary to do a Struts-based front-end.

    I was fortunate to find Tapestry before I started development in ASP. Not only did it allow for me to meet my goals, but I actually have fun developing now. I used to spend at least a day formatting and introducing the proper presentation logic into an application. What took a day now takes maybe a couple of hours. Performance is excellence, the MVC design couldn't be better, and no messy JSP compilations to worry about. Plus it's much easier to play "pass the HTML" than ever before. We can even do it with the same file. I don't have to "train" web designers, just make them aware of some attributes here and there.

    To me, simplicity with functionality is the greatest achievement of the Tapestry framework.
  35. JSP 2.0 : why bother with Tapestry[ Go to top ]

    OK. I'm convinced. I'm goint to dig into tapestry + hibernate for our next big new project.
  36. JSP 2.0 : why bother with Tapestry[ Go to top ]

    OK. I'm convinced. I'm goint to dig into tapestry + hibernate for our next big new project.


    Tapestry + Cayenne is also a killer combination.
  37. Think different[ Go to top ]

    Jason said it best:
    "Not only that, but while Tapestry might be hard to learn, it strikes me as easy to master. Much of my struggle is having to think differently than I normally do, and accept that sometimes the answer to a problem isn't as complex as I'm used to."

    This is really the crux of the learning curve claimed by folks trying out Tapestry - we just are not used to developing web interfaces in a component and event driven manner, so it feels foreign. It actually is quite easy to do after you have made this paradigm shift. If you are coming to it with a strong Swing background, it will seem quite straightforward.
  38. You can change your view tier[ Go to top ]

    I know exactly what you mean about the limitations of JSP. However you can use Velocity with Struts via the Velocity Tools subproject. I've found it v easy to create reusable client-side components with Velocity, none of the custom tag pain or labour. There's no big learning curve (as with e.g. Tapestry) either.
  39. we moved the presentation layer from BEA Webflow to Struts 1.1. This was the

    > first time I had used the new version and it rocked.

    You're lucky. WL Portal is a buggy and poorly designed POS but many people who bought it are stuck with it since it's just too damn expensive to throw away. Go with Struts, if you can.
  40. Review Comment[ Go to top ]

    The reviewer admits that he has little familiarity of Struts ["Although I don’t publicly admit to knowing Struts"], yet he is somehow able to comment on "many of the problems with the Struts framework". The astoundingly popular Struts Framework may have some imperfections, but I doubt that the reviewer is qualified to enumerate them.
  41. Tapestry coverage[ Go to top ]

    The Tapestry coverage in TAoJWD is ancient stuff. If you are contemplating Tapestry, please get Howard's upcoming book Tapestry in Action which does much better justice to this wonderful framework.

    You can thank me for ensuring the Struts coverage in this book is on 1.1. When I first reviewed it, the coverage was on 1.0 and I made sure that the author knew it was unacceptable to cover an outdated version.

    I'll jump in on the framework wars! :) I'm qualified, I think. WebWork2 is much more elegant than Struts ever will be. I'm using Tapestry now and loving it. Why Tapestry instead of WebWork2? The component reuse in Tapestry is just amazing. It is a complex framework to learn, but it really pays off for bigger projects that require lots of reuse and want to focus on development, not plumbing. Just yesterday within one hour I implemented a highly dynamic page that would would have taken over a day in Struts, and would have been far less extensible, flexible, and maintainable.
  42. Tapestry coverage[ Go to top ]

    I've also been using tapestry recently. The documentation sucks and it's a pretty steep learning curve but now that further along I'm really loving the framework. It's great how much can be done with so little.

    Better documentation in the future should help with the learning curve.
  43. Thanks[ Go to top ]

    I feel like my perspective on frameworks is much more complete now because of all the wonderful comments people made. I obviously need to work on my humor so here we go. I am going to print this out, tape it together and hang it over my desk...:^)

    Productivity, staying cutting edge, ease of learing are all important. I can't wait to grow out of Struts and use more sophisticated web app frameworks.

    Thanks again,
    Michael
  44. Maybe its just me, but I often wonder why Cocoon doesn't get a lot more publicity on TSS. I think it could be for a lot of reasons but most probably because people just don't know a lot about it. If they did I think it would be the clear choice for many people and projects and technology enthusiasts. Here are some points that might help clear things up:

    1. The first thing is that people say Cocoon is a "publishing" framework, this must be the worst kind of marketing Cocoon could have done for itself. Cocoon is really an XML-centric framework. But what is XML? It is the ability to model anything in your own way (your own language) and what could be more flexible than that? That combined with XSLT, the ability to transform any XML language into any other XML language, you can transform anything from a domain specific or project specific manner into another XML such as XHTML, XSP (like JSP), or even into non-HTML (like Java, CSS, Javascript, you name it). And should I mention the fact that web developers and even non-developers feel comfotable reading and editing human-readable XML?

    2. The things I often hear about Tapestry, which seems to be leading this debate over web frameworks is that it is the ultimate in component reuse, yet it has a great learning curve. Cocoon has literally a ton of components out of the box that take no effort whatsoever to use. You just specify one using its name in one of Cocoon's pipelines and it just works.

    3. It seems to me that the trend in web application development was originally going toward J2EE which was to use everything J2EE because it was "the way" to go. Now people have realized that it is not perfect for all situations and people are challenging assupmtions and using only what they "need" of J2EE. Similarly, people are questioning why they have to use Java to develop web applications. Yes you need it where project-specific business logic is concerned but for presentation, control flow, database access, and other mundane things that are often reptitive, why not use something easier? People are challenging this assumption too, and prefer using scripting languages (PHP, Python, JavaScript) so that they can see changes immediately without an IDE or an environment to rebuild Java classes. This is what Cocoon was born to do. Since everything is in XML and support exists for all of the other scripting languages, you can also change anything on the fly (even on a live server).

    4. In terms of reuse, Cocoon doesnt get much better. Cocoon is based on the concept of a pipeline. A request follows through pipeline stages that can be as varied as your imagination until processing is complete. Isn't this how normal Java processing works anyway? Except instead of having methods call other methods in a call stack, you can define your own pipeline stages in whatever granularity you like. Then you can move them around, reorder them, insert new ones, combine others, without writing one line of additional code.

    5. Another popular thing I see mentioned on TSS is the notion of AOP. People love it because its exciting and makes sense, but people still wonder about its application, its standardization, and the complexity of actually implementing with it. With Cocoon, AOP exists today and couldnt be easier to use. With pipeline request matching, you can apply a new pipeline stage to all or a subset of pipelines/requests, and with XSLT you can insert, replace, modify, or remove any code (XML, Java or what not) as it flies through the pipeline. That's the dream of AOP applying line item control to all code without actively changing any of it.

    6. Another thing I notice is for most simpler web applications, a majority of the effort is focused on the presentation (look and feel, style, usablity, content management). This is where Cocoon excels. It allows for what people really want in html that they had only been able to achieve with real programming languages like Java (polymorphism and inheritance). As long as two pipeline stages support the same input and output formats (interface), they are interchangeable (polymorphism). Sub-pipelines can expand a pipeline stage to consist of other pipeline stages (inheritance).

    7. Other things I should mention too are out of the box support for internationalization, xml-based generation of PDFs and Excel spreadsheets, JPGs, graphs and charts and any other component that people have added. Also multiple browser and device support (aka transcoding).

    8. Cocoon doesnt prohibit Java. On the contrary, it is entirely written in Java, so components can be added in Java to fulfill any desired function or requirement. Logicsheets (like taglibs) use XSLT to produce Java for XSP (like JSP). Pipeline stages in the form of actions can also be written in Java to help pipelines be selected or branched based on Java based criteria.

    9. Doesnt all of this flexibility come at a performance price? Isn't XSLT slow? Not at all with the ability of XML to produce anything (even Java) from anything else, an infinite number of pipelines and sub-pipelines can be rolled up during runtime, compiled and cached in a Java class that spits out html (or xml for web services) that retains only the logic necessary to compute what is dynamic for a given request. So at the end of the day it all reduces down to Java without having to write any Java. You get the best of both worlds.

    So my question is, what so wrong with that?
  45. So my question is, what so wrong with that?


    I think you hit the nail on the head, Cocoon is very XML-ish centric so I believe our knee jerk reaction to the framework is that if we don't have any XML data (or data intensive site) then why use it? The problem is most developers are trying to find a one-solution-for-all-problems framework. Once a developer learns their one-solution-for-all framework they rarely leave the comfort of it so sometimes they find it safer to simply use the wrong solution because they know it so well then to try and learn another tool. The unknown is risk and one of the goals of any leader is to reduce risk.

    Would you recommend Cocoon as a one-solution-for-all framework?

    Let me be clear, I don't think Cocoon needs to be that solution for all framework because it is like a specialist framework and does what it does well.
  46. I think you hit the nail on the head, Cocoon is very XML-ish centric so I believe our knee jerk reaction to the framework is that if we don't have any XML data (or data intensive site) then why use it?


    I may see things differently than others, but I can see that anything that can exist in a data structure can exist in XML. For example, if your database schema was represented in XML and your queries in an XML query language (not too unlike most descriptors) then you could write XSLT to automatically create your java from the combination of the two (not too unlike XDoclet and Velocity). You could abstract styles for web pages to be independent from the device/language (browser, CSS, PDA, HTML, WML, etc). XML can be used for validation (as in Schematron). Although extreme, it could be used to model anything and everything.

    > Would you recommend Cocoon as a one-solution-for-all framework?

    Because it can still be extended with Java, yet other frameworks could not be extended as easily to function the way it does, I do believe it to be a one-solution-for-all framework (for the presentation / Servlet / MVC side of a web application).
  47. Just because you CAN represent any data source as XML doesn't mean it's a good idea. The problem with an XML-centric framework as a "one-size-fits-all" solution is that everyone isn't using XML as their source, and if it's not your original source, it requires serialization time to convert your source to XML. That's additional overhead, converting efficient storage types (like a binary object) into one of the most verbose serialization formats out there, XML. You can cache all you want, but that serialization is still a big hit. Unless you're dealing with huge textual documents, or your data source is natively stored as XML, it seems to me to be a lot of unnecessary overhead.

    I think that a lot of people went XML-crazy a few years ago, especially back when Cocoon was first written. XML was the hammer and absolutely everything around was a nail. I was guilty of this myself on a pretty large EAI project, where my recommendation to use XSL transforms for moving from one data structure to another in a pipelined architecture ended up biting us all in the ass. The data structures were extremely complicated (telecom provisioning orders), and XSL just wasn't up to the task. At least, not in a way that was easy to understand, write, or debug. We also found XSL to be a bottleneck; it's not only extremely unintuitive, it's also a lot slower than alternatives. You can get it to work, but god help you in trying to maintain it, especially when you need to maintain a large number of transformations and have someone besides an XSL expert work with them.

    On an unrelated note, webwork (2) is definitely my favorite out of the frameworks discussed. It's easy to pick up and extremely powerful. The combination of a command-pattern framework and interception allows for some pretty cool things. This is after a year or so of struggling with Struts; webwork was like a breath of fresh air. And it's easy to test, too.
  48. "recommendation to use XSL transforms for moving from one data structure to another in a pipelined architecture ended up biting us all in the ass. "

    I agree with your assesment 100%. XSLT is very good for some problem domains (excuse the hackneyed phrase). But using it as the backbone for large systems that are less than trivial can be tricky.

    I do think, though, that dealing with XML directly from the data providers has merit. Instead of dealing with an access layer written in, enter favorite language/platform/tool here, the XML can be used or coerced in any number of ways.

    The title of this thread highlights some of what is wrong with technology today. "The Art of Java Web Development" suggests that web development is too difficult and costly. I believe both are true. Paradoxically, the number of choices is good yet bad that there is a lot of confusion over the best ways to do things.
  49. I can agree with everything that you've said here. The idea is not to just use XML and XSLT for their sake. I wasnt meaning that you should dump your entire database into XML just so that you can manipulate it with XSLT.

    The idea is to use XML to describe things where there is not a more efficient mechanism available to do so. And if something is going to end up in XHTML or HTML then getting it to an intermediate XML state before it eventually becomes HTML makes sense.

    For example, defining a website with a Navigation frame. Specifying the entire Site Map in XML would allow you to build the navigation frame based on the context of the current request all in XML/XSL and with no java. Also if you are defining lots of views or reports where the format stays the same, but the content differs, specifying the content with XML and converting that eventually to Java to fulfill the request also makes sense.

    And again, with regard to speed, the idea is not to use a ton of transformations per request as they come in. The idea is to roll-up a ton of transformations into static xml / xhtml / html, etc and then only evaluate what is dynamic when the request comes in. I am sure most people follow this paradigm regardless of what framework they use.
  50. If your starting state is a database, and then maybe a Java representation (which is pretty common), then I still don't see the point in doing an intermediary transformation to XML prior to HTML. It doesn't really grant you anything. It's much easier outputting from the object directly to the page, using either jsp tags or my personal favorite, velocity. So I don't think that getting data into an intermediary state makes much sense at all. It's additional overhead for little benefit.

    As for a navigational frame, you could just as easily represent your navigation as a Java object, and again save yourself the serialization cost going to XML. Just because XML is hierarchical doesn't mean it's always the best thing to use for hierarchical menus; a well-designed abstraction layer in Java can achieve the exact same thing, and do it much more quickly. You can model your menu structure, because object hierarchies can just as easily represent a menu structure as XML. And, in my opinion, the result is easier to maintain. It's far easier to show developers a Java model of a menu system and include methods on the objects to ease manipulation than it is to show them a bunch of XML schemas, then show the XSL scripts to do the transformations. I just don't think that XML/XSLT is an easily maintained development framework unless you're doing a lot of document-centric activity (like a publishing framework). There are other constructs out there that are far better suited for general web development, and they are hands down more easy to maintain. As a simple example, how easy is it to unit test XSLT? Not very, without a pretty complicated framework that has to change whenever your menu constructs change, and without the benefit of compile-time checking to help find errors.
  51. XML transformations (XSLT) is an overhyped technology.
    You can do same thing much easier, with much more simple, clean and readable code than with horrible xslt. For example using python for constructing html output from xml documents is way better than doing it with xslt.
  52. "If your starting state is a database, and then maybe a Java representation (which is pretty common), then I still don't see the point in doing an intermediary transformation to XML prior to HTML. "

    [playing contrarian here]
    One reason is that data will outlive Java. Why tie yourself to a language/platform when empiricism suggests that a language/platform has a definite lifespan?

    If you work directly with data (could be XML) the world is much more open. If you couple tightly to Java, or any other specific language/platform, then you've painted yourself into a corner.

    I've seen many relational models that have outlived more than 1 platform. The model remains much the same but everything around it changed.
  53. ...then you could write XSLT to automatically create your java from the combination of the two...

    The problem is, that it's just easier to write the java than the xslt. Even for simple tasks. For complex tasks, the XSLT becomes practically impossible. Lots of nice functionality in cocoon though.
  54. <quote>People are challenging this assumption too, and prefer using scripting languages (PHP, Python, JavaScript) so that they can see changes immediately without an IDE or an environment to rebuild Java classes.</quote>

    I find that the XML templates (XTP) pages that come with Resin server is a nice way to produce web pages without having to compile Java classes. They are very efficient and make very clean templates for easy creation and updating.

    For those that dont want to use Resins XML templates then Cocoon or even JSP is better than Java classes.

    Really, if people have front end templates coded as Java classes then they are only making it overly complex on themselves.

    Dan
  55. Struts and Tapestry[ Go to top ]

    The comments regarding Tapestry have intrigued me enough to go check it out; never worked with it.

    Regarding Struts, I agree with the reader who stated that it's great for what it was designed to control (control flow)...I agree the Forms implementation is not good and stay away from it...I think Struts 1.1, augmented (properly) with other frameworks and tools, is great for web app dev...

    Anyway, does anyone have experience with melding the two, Struts and Tapestry? Forgive if that's a nonsensical question, I haven't used Tapestry...is Tapestry a framework primarily for the View layer? I'd like a better way of doing that, certainly...cheers, all.
  56. Struts and Tapestry[ Go to top ]

    Tapestry 3.0 includes JSP tags that allow a JSP to create a URL that calls into a Tapestry application. On the flip side, a Tapestry application can always forward to a JSP or servlet rather than rendering a response using a Tapestry page.

    Tapestry is its own MVC environment ... it's not a templating system like Velocity. Tapestry applications consists of pages and components which are all stateful objects. Like an application server, Tapestry uses object pools to allow objects to naturally contain state AND behavior (unlike the artificial split in normal servlets, or with Struts Actions). Having a true component object model (which allows every piece of the application to "know its place" and its relationship to the rest of the application) allows Tapestry to do all the tedious work.

    Then end result is that you can build a web application without a thought about HTTP, HttpSession, HttpServletRequest, query parameters and such. All of that is shifted onto the framework.

    Jason's note is right: we've all been beaten down, convinced that coding web applications has to be painful and awkward. It doesn't.

    Comparing Tapestry to Swing is somewhat of a misdirection. There's some of the flavor of building a desktop application (configurable, reusable components; objects with state and behavior) but, unlike Echo (for example), we don't try to replicate the Swing API. In Tapestry, presentation is king, which is why having markup in the HTML templates be invisible is such a key design consideration.

    Tapestry represents my personal experiences building web application using teams of mixed developers: HTML and different levels of Java experience. Part of that experience is that you need to be able to "sweat the pixels" easily, preferably without having to run the entire application -- since the HTML guys often don't have that option.
  57. My answer to the second question is no, neither Struts nor any Model 2-based framework really supports MVC.
    More specifically, Model 2 doesn't fully support the concept of the "View", at least the way I understand it, which is:

    In MVC, the View is the set of UI aspects in all pages (or screens) which define what the user sees. These aspects are of two types:
    1) The display of UI elements (or controls) in individual pages.
    2) The static navigation links between pages/screens.

    So, the problem with Model 2 is that it doesn't acknowledge the second type of aspect as being a part of the View, leaving it instead as a responsibility of the MVC Controller.

    Any ideas? Does it make any sense, or have I missed something important?
  58. Don't make me get out the hose...[ Go to top ]

    Thanks to TheServerSide for doing a review of my book. While I don't agree with everything the reviewer says, I think it was fair and balanced.

    What's interesting is the massive <insert your favorite modifier here> storm it has caused, all over which framework is best. OK, everyone, take a deep breath...they are just tools! This is like hearing carpenters arguing over which kind of hammer works best. Sure, there are lots of distinguishing characteristics of these different frameworks...enough to write part of a book about! However, what I also write in the book is how to evaluate the framework for the job at hand. That's one of the key messages from Part 2 of the book -- evaluate the framework based on the type of job you have. I tend to use different frameworks for different jobs because they are better suited for a particular task. No one is inherently better than the other except in extreme cases.

    OK, I'm done, you can all start fighting again...
  59. Anybody use InternetBeans Express?[ Go to top ]

    I wonder why no one mentioned InternetBeans Express here? It's an amazing framework that makes building web application a breeze and really achieves seperation of logic and presentation. It's the closest thing to what .net guys gets Uncle Bill's Visual Studio. I used it in 3 projects and we were able to achieve so much in so little time and with no problems at all. However its biggest problemes are that 1) its propreietary 2) costs money and 3) ties you to one IDE but It's very robust and solves many problems. I wonder what are the closest open source frameworks in concept to InternetBeans?