Announcing WebWork 1.0 Web Application Framework


News: Announcing WebWork 1.0 Web Application Framework

  1. I'm proud to announce the release of WebWork 1.0! WebWork is a HMVC web application framework in Java, developed as Open Source (BSD license) and designed to help create dynamic websites using minimal effort and maximum flexibility. WebWork is also being primarily used in the upcoming new release of

    It's architecture is easy to learn and understand, yet has features that allow for complex applications to be built.

    For more information, read the entire release message or download WebWork (including documentation) from:

    One of the main features is it's total separation between the controller and view aspects of an application, thus allowing for a multitude of view technologies to be utilized. Out of the box WebWork has support for JSP (and comes with an extensive tag library that covers most needs), XSLT, and the template engine Velocity. Adding support for more such tools is very easy (the velocity "integration" was done in hours), allowing you to have maximum flexibility with regard to how you structure your application.

    You also get to choose whether you want to use a Model-1 or Model-2 approach to building applications, although we'd
    recommend using both as is described in our comprehensive documentation that includes reference sheets (for the tag library and expression language) and many useful tips&tricks sections.

    WebWork comes with a comprehensive set of examples that are both used to test the functionality of the framework, as well as showcase how it can be used. Many examples are conversions from other frameworks (such as Struts) so that you can see firsthand how WebWork differs from the rest of the crowd.

    One of the most important tasks when working with frameworks like this is the configuration step, which is where Java classes are mapped to logical names (used for invocation) and where the connection between controller and view (such as a JSP or Velocity template) is made. This configuration can be done manually, but to ease this process there is an XDoclet extension available (through the XDoclet project, see that will allow you to specify all such configuration directly in your Java code using custom WebWork-specific JavaDoc tags.

    XDoclet is also used to generate HTML documentation of your application, which helps to serve as a
    communication channel between the Java developer and web designer (if those roles are separated into
    several team members).

    There are a multitude of other unique and interesting features that we are very excited about, but we'd encourage you to download and find out about those yourself. So get it now from:

    Documentation can be found in the download, or online at:

    We encourage you to try WebWork together with the wonderful SiteMesh ( and XDoclet tools, a combination which can give you an amazing productivity and clean application architeture.

    This is an OpenSource project, developed using an open development process, and is hosted by SourceForge. If you have any questions we recommend the user mailing list, and if you have suggestions for improvements we're all ears on the development mailing list, both of which can be found on the project homepage at:

    If you are attending JavaOne this year, then you might want to stop by our WebWork developer meeting on Wednesday March 27, 6.30pm at Fourth street Bar & Deli (across from the Metreon). See ya there :-)

    /Rickard Öberg, WebWork project manager
    Chief Architect,

    Threaded Messages (54)

  2. I *just* downloaded it and installed the examples on Orion. This is *very* good stuff! I can't wait to dig deeper. (Which I am going to do right now!)

  3. Good work
    the documentation is awsome
  4. This looks VERY promising.

    I am just getting started on a large project that makes heavy use of XSLT, and Struts on the presentation tier.

    I may have to revist that Struts decision now.

    Not to mention that I develop with Intellij IDEA. Bonus!

    Funny. I now have projects in the pipeline using JBoss, XDoclet, and now possibly WebWork. Damn, Rickard, I feel like I owe you a consulting fee!

    Oh well. That feeling will eventually pass. ;-)

    Keep up the great work!
  5. Jason,

    Not sure why you've chosen XSLT but personally my choice would always be either JSP with SiteMesh or Velocity with SiteMesh. YMMV as usual though.

    As for the fee, just gimme a beer some time and I'll be happy. ;-)

  6. RIckard,

    The XSLT is part of a legacy system that was inherited. As such, I am forced to deal with it. Blech. No time to replace thousands of lines of XSLT, unfortunately.

    But I will still check out SiteMesh.

    -- Jason

  7. Rickard, any chance you might be able to arrange for a single HTML or PDF file to hold the docs, for those who like to print it out and read it more easily? It would be much appreciated.
  8. In the spirit of doing for oneself :-), I've gone ahead and made a PDF of all the HTML files into one 58-page long PDF document. That'll make it easier for me to print it out, but I'd be happy to share the result with others who may want it. Rickard, is that OK to do? I realize that a slight dilemma is that if the docs are updated, this PDF won't be in synch with that, but at least for this first release it seems better than nothing.

    If you do want to offer this and can provide me an email address to which to send it, I'll be happy to do so. If you'd rather not reply publicly, my email address is carehart at systemanage dot com.

  9. We did dabble with making PDF's but never managed to make it a part of the build system so we scrapped it for now. One thing we could easily do is both generate the chunked version and a single long HTML document (for printing). That could work.

    If you can get the PDF to be a part of the build system, that'd be ok too.

  10. A single HTML version in addition to the chunked one would certainly be a great step. As for getting PDF creation to be a part of the build process, I imagine that could be challenging if you don't have someone on-hand in the team to create such PDFs. Since I've only just started looking at WW, I hope you'll understand that I don't want to offer to take on that role just yet. :-)

    But, again, would you want the PDF file for now, at least for benefit of those who could use it until the next doc rev comes out? Or are you concerned that it would set an unfortunate expectation if it couldn't be kept synched with future updates?
  11. Charles, yes I guess it's better than nothing :-) Send me the PDF and I'll add it to the binary.


  12. Rickard

    If you can generate html, then you certainly can generate the pdf on the fly.

    take a look at htmldoc

    thanks for webwork. I'm going to check it out next week.


  13. Thanks Tien, I used the tool. Very nice.

    I post a new binary which includes a full length HTML and a PDF of the docs.

  14. you can convert html files to pdf using a tool called "htmldoc". As far as I remember htmldoc available as binaries & source code, although I am not sure if it is open source.
  15. Rickard,

    we are just evaluating web frameworks for our current project. (A web portal for a bank) If I would've made a decision some hours before I read your message, I would've chosen Struts, because it seems very powerful and has a big community of users. The only problem I see is, that Struts is a little bit "too powerful" and maybe not so easy to handle. Apache Turbine is worse, of course, but Struts seems to be complicated, too.

    So, what would you say are the main advantages of WebWork over Struts? I read in the FAQ that you focused on easy usage...I like that and will try it this weekend.

    Thank you,

  16. Mirko,

    As I'm not a Struts user myself (duh) I really couldn't give you any good answer to that. However, I'm fairly sure that this question has come up for other users as well, so send it to our webwork-user mailing list. Subscription is available over at

    AFAIK you can simulate many of the things Struts "does for you" in WebWork (e.g. form beans), although to be honest there seems to be other easier patterns available that perform pretty much the same thing without having any specific support for it in WebWork. WebWork is a rather generic tool in that sense, without getting overcomplicated mind you.

  17. <quote>
    As I'm not a Struts user myself (duh) I really couldn't give you any good answer to that.

    I'm not a Struts expert either but it appears that WW duplicates a lot of functionality already provided in Struts, e.g. jsp tags, forms, actions. Why? If Struts is good, why not use it? If Struts is bad, why duplicate it?

    Expression Language example is really not a convincing one. See Struts Forms and FormBean Interactions for details.

    My $.02
  18. I'm not a Struts expert either but it appears that WW

    >duplicates a lot of functionality already provided in Struts,
    >e.g. jsp tags, forms, actions. Why? If Struts is good, why not
    >use it? If Struts is bad, why duplicate it?

    Admittedly, when I first started out with this web application framework I thought that Struts was the best one already available, but it wasn't quite up to scratch. It could be done better. Why settle for a Ford when you can get a Porsche, sort of.

    So, WW has what I considered good from Struts, skips the bad parts, and adds many unique features that (taken together) makes it one-of-a-kind on the web app framework scene (which is fairly crowded).

    >Expression Language example is really not a convincing one.
    >See Struts Forms and FormBean Interactions for details.

    The EL in WW is waaaay more capable than was shown on the Struts page. If you're not convinced I doubt that you really looked.

  19. One question I have that struts never answered and I couldn't find in the last CVS copy of webwork that I looked at:

    How do you format dates and numbers in the output? Struts' <bean:write> tag doesn't allow specifying formatting for currency or dates, only using the built-in toString() formatting of whatever type the property is. I ended up having to use a nasty little piece of scriptlet that calls MessageFormat.format() instead.
  20. Jakarta Datetime Tag[ Go to top ]

    One question I have that struts never answered and I couldn't find in the last CVS copy of webwork that I looked at:

    How do you format dates and numbers in the output? Struts' <bean:write> tag doesn't allow specifying formatting for currency or dates, only using the built-in toString() formatting of whatever type the property is. I ended up having to use a nasty little piece of scriptlet that calls MessageFormat.format() instead.

    Check out Jakarta Datetime Tag to see if it solves your problem.
  21. Struts 2 datetimepicker example[ Go to top ]

    HI, Learn how to use datetimepicker in your Struts 2 Application. Read more at Thanks
  22. Mattias,

    Excellent question, thank you for asking. This is indeed solved quite nicely by our ingenious <webwork:text> tag that delegates to MessageFormat.

    Here's an example:
    <webwork:text name="myformat" value0="name" value1="postDate"/>
    The action has a properties file with the following line:
    myformat=$0 posted a new message on ${1,date,yyyy-MM-dd}
    and the action has methods getName()/getPostDate().

    You can also specify the format in the JSP directly (if you're in a hurry), or you can specify it in a standalone properties file (using the ResourceBundle style for naming conventions) and wrap the above in the <webwork:i18n> tag that allow you to specify the bundle containing the messages.

    Look in the bundled "text.jsp" file for more examples.

  23. Wow, nice, didn't know that. However, if you're using the Velocity integration, is there an equivalent? This is something I've been a bit confused about for a while, the documentation seems a bit thin wrt this. Are there 1-1 mappings between the JSP tags and velocity macros/tags/directives, or do we need to implement something ourselves?

    Congratulations on the release of 1.0, I hope it gets all the recognition it deserves. Currently I'm using Struts at work and WebWork at home - I'd much rather be working at home ;)
  24. Chris, yes this is a tricky issue. I've tried to promote as heavily as possible that all tags are just syntactic sugar for regular beans, so that the functionality would be available regardless of view technology. We're not quite there yet (and I guess this is one of those points), but I can assure you that this is where it's heading. And it's not exactly technically difficult to do either, so.. the more people we have us bugging about it, and helping out with their favourite view technology (I'm a JSP buff myself) the better. There's a certain natural evolution happening here, although we do try to push it in the right direction if possible.

  25. [No offense anybody, deliberately heating up a bit to move away from PDFs... ;) ] -- After having read the WebWork doc, I fail to see that WebWork would be the "light at the end of the tunnel" in terms of Web-based MVC frameworks.

    An easier (?) Struts then... e.g. that Expression Stack and the Expression Language EL (BSF, huh?) are nice, but what IMHO this is mostly used for, to "navigate" through JBs, is possible with most such frameworks. Also nice idea to keep the "view technology" open, but reality is examples & documentation are heavily leaning towards JSP.

    We want Web COMPONENTS, real ones that could even distributed as JARs including view, control, resources, the promised Lego land of web-components, for the Web at last! Like Swing components, but not a dumb Web implementation of the Swing API. Some day we'll be "dropping" Web components from an HTML WYSIWYG editor's visual toolbar into an HTML template...

    Tapestry IMHO is one open source framework that got it right! Also see this thread on Tapestry has no JSPs at all but only HTML templates instead, pretty similar to the WebWork/Velocity scenario actually, but with the nice idea of "informal parameters". And it's definitely HMVC; who made up this term anyway? ;) Give Tapestry a try, you'll love it!

    Let's hope JSR127 (Java Server Faces) is moving down that road; anybody attending JavaOne willing to give a summary here? I hear Barracuda from Enhydra may also be worth a look but haven't had the time, anybody able to compare Barracuda/WebWork/Tapestry? Last but not least, anybody knows/any resources/comparisons where M$ .NET Forms fits into all of this?
  26. What you're talking about (MVC Push) is a valid architectural decision but like many such decisions it has its drawbacks. Have a a look at for a discussion on why the Turbine project migrated to MVC Pull.
  27. <quote>
    Also nice idea to keep the "view technology" open, but reality is examples & documentation are heavily leaning towards JSP.

    Don't let the docs fool you. The heavy JSP slant is mainly because the authors were JSP users. However, we do plan to revise the docs to incorporate more Velocity examples, etc. We have quite a few heavy Velocity users that have built extensively on top of WW. 1.0 provides rich support for JSP but keep an eye on CVS for more Velocity support.

  28. It's gratifying to see more people speaking up for Tapestry that just the author (me). Hopefully the next major release will get as much attention.


    Michael mentioned true components, components that can package their assets (images, stylesheets, etc.) with the classes in a JAR file, and they are still usable by an application. Tapestry will either dynamically expose the assets using an engine service (roughly analogous to a servlet), or copy the files from the classpath to a portion of the static web site (preferred in production).

    The end result is you can do very complicated components, such as the Palette.

    In fact, everything in Tapestry is a component; pages are just big components. You can often create new components with no code, just by combining existing components in interesting ways.


    I absolutely agree that a pull framework is the only way to go. The contract between the view side and the controller side becomes the JavaBeans properties exposed by the controller. Using property paths allows the view side to navigate the object graph, through the controller and to business/domain objects.

    IDE Integration

    Coming soon is a very advanced Eclipse plugin for Tapestry called "Spindle". I've used an advanced version of it and its going to be very, very slick. Tapestry is a natural for this kind of utility, because its specifications are very structured (and validated against a DTD) and the Tapestry impact on the HTML is minimal.

    HTML templates vs. JSPs

    In the consulting situations I've worked in, the production line starts with a graphic artist, who uses Photoshop to create what a page should look like. These are passed to a HTML producer, who creates images, stylesheets and HTML templates. These are passed to the Java developer, who must instrument them, to make them dynamic instead of static.

    In the JSP world, instrumentation is very much one-way: once the JSP tags have been put in place, the pages no longer preview in a WYSIWYG editor such as HomeSite. If you are using JSP tags for the "navigational border" that typically surrounds each page, then you will be stripping out a lot of the HTML producer's code, to place it in a common include ... again, crippling the ability of the WYSIWYG editor.

    This is bad, since when the customer demands late changes, it involves a lot more work ... often, having to run the application just to see minor formatting changes. I call this "sweating the pixels".

    For Tapestry, a goal was to support WYSIWYG. Instrumenting the HTML template involves adding "jwcid" attributes to existing tags, and often adding a few new tags (typically <span> tags) to identify dynamic content. The jwcid attributes are used to identify which elements are dynamically generated by components. jwcid is ignored by HomeSite, so the the pages still preview properly. You can also mark sections of the template to be ignored (an idea I appropriated from Barracuda).

    Forms and Validation

    Tapestry froms are unlike anything I've seen elsewhere (exception for WebObjects, of course). The components that render the HTML form element are also involved when the form is submitted. All form and form element names are generated dynamically, which allows for looping inside a form.

    Tapestry includes an extermely sophisticated form validation subsystem. Various pre-defined and user-defined constraints can be added to fields, and fields automatically modify thier appearence to reflect any errors (the exact form of modification is typically a change in CSS style and/or a decorative icon).

    Examples of validations are to make field required; to interpret a field as a date or number, to enforce a date or numeric range, to set a minimum length for a field. However, it very open-ended, and I expect to see more complex validations, such as validating against a regular expression. The component stays the same, just a different validation is plugged in.

    JavaServer Faces

    I tried to get in on this, but my then company was going down the tubes and I couldn't get signoff to join. Should have joined as an individual in the first place.

    Pure conjecture: I expect this to be Struts++ rather than something more radical like Tapestry. Sun never likes to admit a mistake, and JSPs (like nearly all technology based on code generation) are a mistake. Sun prefers to compound their mistakes by adding new levels of abstraction.


    If you think you have to compile code (ala JSPs) for performance, you are wrong. Equivalent Tapestry and JSP applications have virtually identical performance curves, though JSPs do better once the server reaches saturation (see Java Report, Sept. 2001 issue for details). The presentation layer is not the bottleneck: app servers, EJBs and databases are.
  29. I couldn't agree more with the design goals of Tapestry. I'm an avid Struts user, and have experienced "sweating the pixels" stated in Howard's post. However, once I really took a look at what Tapestry is actually doing for the web developer I was blown away.

    I'm sure many of you have seen what Microsoft is doing with component based development in ASP.NET--you do evaluate the competition don't you :) Regardless of what you think of .NET in general, Microsoft's new model for web development is compelling. Have no doubt--It WILL bring RAD, VB style development to the web. And that means that the legions of VB programmers out there will very easily bring their skills directly to web development with little or no training.

    Tapestry is similar, but better! What Tapestry is doing is basically shielding developers from the idiosyncrasies of HTTP and stateless web development. What they see is an application development platform. For all intensive purposes, they could care less that their application is "executing" on the web. They focus on the app and its logic, not the problems or issues with maintaining state, generating URLs, blah blah blah. This stuff is light years beyond what Struts and WebWork are doing (and I like Struts!) for developing applications quickly and logically.

    Take a look at it--seriously. If you like tinkering and playing around with the plumbing of your apps, then go ahead and use Struts--heck use straight JSP for that matter. But if you want to quickly build stuff that you can maintain and extend, then you owe it to yourself to check out Tapestry.
  30. Hi all

    Is Tapestry better than Struct and WW? I haven't used any of these frameworks before. But recently I want to spend some time on trying it out. At first I believe WW is the best but now I am confused. It seems that now no one in the forum advocates for WW after people mentioned Tapestry

  31. <quote>
    It seems that now no one in the forum advocates for WW after people mentioned Tapestry

    I wouldn't be so sure about that. Ultimately, you need to investigate and decide for yourself and get beyond marketing hype and developer bias. Also, note that the new TSS portal will use WW along with other open source products. So, instead of asking what is better you should read/investigate and try them out for yourself.

  32. I'm in the same situation as you are, Edmond. Looks like no one have used all 3 frameworks extensively and can give a relatively unbiased views.

    I'm starting to evaluate tapestry. Got the tutorials to run on tomcat with no major problems. Now to dig deep into code.
  33. was there anything special you did to get the tutorials running on tomcat? I was quite disappointed to find everything closely tied to Jetty (the Jetty runtime is even included in the distro), and no doco pointing elsewhere..

  34. The FAQ in the Developer's Document includes some notes about working with Tomcat instead of Jetty. At this point, they're probably not even relevant ... a year ago there were some conflicts in the version of JAXP used by Tapestry and Tomcat, but I'd suspect they're both 1.1 by now.

    There is a dependency on some Jetty code to deal with multipart form submissions.

    Tapestry works around a couple of nuances in Tomcat as well.

    I use Jetty because it is smaller and very easy to embed.

    Using Jetty (well, and Ant) you can have the tutorial running as soon as you unpack the Tapestry distribution. Or you can download JBoss 2.4.3 and be running the Tapestry home page on your computer in less than a minute.
  35. problem is, I dont want to introduce yet another servlet engine, not even for the purpose of the demo. I already have a running setup of JBoss 2.4.4/Tomcat 4.01 on my machine. My final deployment platform will be Resin 2.1.

    What you're saying makes me wonder how deeply you are tied into the different servlet engines, and why.

    (we're kinda offtopic on this thread, I guess. After all, the purpose was to promote WebWork - hail WebWork -, not Tapestry. Lets move this to tapestry-developer)
  36. There were 2 missing jars, com.primix.tapestry-1.0.10.jar and log4j-core.jar that I added to the lib dir. I'm using tomcat 4.0.1.

    Mind you though, I have only reached the border tutorial and do not know whether the rest will work fine or not.
  37. Take a last beta of the Struts 1.0.2 - it contains <bean:write> tag with ability to format date and time values according to the user locale or use format string from additional attribute - format. It also can take a formatKey attribute as key to choose format string from application resources according to the current user locale.
  38. snip
    > WW has what I considered good from Struts, skips the bad > parts, and adds many unique features

    Why would you choose not work with Struts group directly ?(not to mention other open source projects) to improve it via your input and participation in the collaborative process thus improving the weak or perceived bad parts?

    You could choose to then add you unique features as a value add project much like the Expresso Framework is to Struts.

    Our Strength is in standing united and building on other open community standards. I believe we can do much to strengthen Java (against MS) by standing united on developing standards that make web components more interoperable and integrated (Lego Style). Your approach to create another framework I feel is destructive to strengthening the Java market.

    My 2 cents.

  39. Did you use Struts on the real project - I mean hands on ?

    I think if you would you would understand that although Struts is pretty good, does have a problems, the problems come from approach not from lack of extensions.

    >> approach to create another framework I feel is destructive to strengthening the Java market

    Well, if the world would work like this we would still be single-cell organisms. Based on the experience of last 4 billion years diversity and competition seem to work the best ;-).

    My 0.02


  40. I think Struts is better[ Go to top ]

    Did you use Struts on the real project - I mean hands on ?

    I think if you would you would understand that although Struts is pretty good, does have a problems, the problems come from approach not from lack of extensions.

    Care to explain how WW is better than Struts?

    Struts is a mature, well-established product. There are real and successful projects developed using Struts. WW, on the other hand, is a new product that appears to duplicate a lot of Strut's functionality.

    I'm sure that given time and resources, WW may become someday what Struts is now. This is somewhat regretful since this time and resources could have been more productively spent developing NEW features for Struts ... instead of duplicating the old ones.

    My $.02
  41. I think Struts is better[ Go to top ]

    Although WebWork 1.0 was just released, that by no way means that it is an immature product. I've been using WebWork for over a year now. This 1.0 release just now happened because the release was waiting on things like documentation and small tweaks.

    I have used Struts and WebWork, and they aren't "the same thing" as everyone seem to be claiming. Go try both, then come back and say that. In my opinion, the small footprint and limited complexity of WebWork makes it a huge winner over Struts.

    Anyone else actually use WebWork _AND_ Struts? Care to share your thoughts?

  42. I think Struts is better[ Go to top ]

    I have used Struts and WebWork, and they aren't "the same thing" as everyone seem to be claiming. Go try both, then come back and say that. In my opinion, the small footprint and limited complexity of WebWork makes it a huge winner over Struts.

    Anyone else actually use WebWork _AND_ Struts? Care to share your thoughts?


    Patrick - I have used both. I agree with you 100%.

  43. I think Struts is better[ Go to top ]

    Well, thats One Way of looking at that ;-).
  44. <quote>
    Your approach to create another framework I feel is destructive to strengthening the Java market.

    My 2 cents.

    I couldn't disagree more. In fact I think one of the strengths of open source is the fact that someone can at least try and build a better mousetrap without being bound to another product. Sometimes it is better to work outside existing frameworks (no pun intended). In my mind, no one has the definitive solution - why not let others give it a shot?

  45. Fortunately, that's not the way Open Source works. If anybody wants to implement something that is already there in a different, in his or her opinion, better way, there is no management that says "wait, you need to protect our investment in this, so don't start from scratch ..." - and IMHO this ensures that innovations occur, even if they don't promise the usual ROI.
  46. Great improvement in documentation. Honestly when I saw all the TODOs in the RC3 docs, I did not hope you will manage to fill them in before rel 1.0 - but you did !

    Should not be called HMVC, but E2MVC (Exceeding your Expectations MVC)

  47. Michael,

    Well, sometimes pigs do fly in a frozen hell. ;-) Although seriously, the majority of the documentation (which is excellent) was not done by me but by other WebWork developers. This has been a great team effort, and we're all very proud and happy users of our own dogfood. As noted in the release message I'm using it for the new portal code, and it's just amazing how easy yet powerful this stuff is, especially when put together with XDoclet and SiteMesh. God, I can't imagine life without it almost... oh ehm I'm getting religious here 8-)

  48. What about EJB?[ Go to top ]

    One of the problems I have always had with Struts the lack of EJB integration. In struts you basically have to copy all of the data out of your entities into a struts form object before you could do anything useful. As the developer of JBossCMP, this really bugs me, because it basically removes my ability to do optimized loading in the entity tier. I have the same problem with value objects (maybe the dynamic value object patter will help here).

    Anyway, will WW hook up directly to an entity?

  49. What about EJB?[ Go to top ]

    Dain, of course you can do that. Not a problem at all.

    But, consider the consequences. If you let the values end up in the entity directly you'd have problems with rolling back changes if there's a validation error. I.e. let's say 3 parameters from the form are passed successfully directly into the entity, but the fourth fails. Then there's no way to get the old data back, except doing a manual rollback. Also, if your entity has a direct reference to another entity this cannot be resolved directly since form parameters are only strings (unless you make a property editor or something).

    This is where value objects (or something equivalent, there's many ways to boil this water) helps as an insulation. By using XDoclet to generate the extra objects you don't have to worry about extra tedious programming.

  50. Personally, given that there is a JSR working on standard tag library, I would put my money on that, just as a matter of strategy. But it's nice that there is competition among tag libraries because the final result will improve.
  51. The focus of the framework is not the tag libraries. These are just a means to an end. Obviously you are free to create and use your own or none. When the JSR finishes its tag library, we will look and see if it is a fit.

  52. I spent the weekend going over the WW source code. The one problem I see is the same one I have with struts (although it's being addressed in 1.1). That is, neither framework allows mulitple dispatcher servlets in the same servlet context.

    Oh sure, you can define them, but the configuration stuff is global to the context and assumes only one. I don't know why all these frameworks assuem that there should only be one controler per servlet context.

    I know you can run multiple "apps" with one dispatcher, but then your config turns into a monolithic mess. Instead, I should be able to have multiple dispatchers in one context, with seperate configs for serving seperate apps.

    A common response is that, "seperate apps should go in seperate contexts." However, if I want to share global services like security, templating, etc. then it makes much more sense to keep the seperate "apps" in one servlet context so it can provide those services.

    That's my rant... :)

  53. Yikes[ Go to top ]

    Maybe I should spell check before posting... Whoops!
  54. People like me how are not good at GUI would like to use resuable components(something like VB or Swing where we can just drag or drop) without converning about server side which can be EJB or simple java classes.

    The whole bunch of frameworks are based around JSP which itself is not based on sound architecture (in my opion).

    Webobjects given me that flexiability but
    unfortunately it is custom framework using its own java

    I am still on hunt for another good one using standard java classes (tapestry seems to close to that).
  55. Hi there,
    I would like to know exactly why WebWork is bound to Servlet 2.3, as I want to use it to extend an existing system running on Servlet 2.2. I am thinking maybe specific parts of Webwork are tied to Servlet 2.3, in which case I could still use its other parts in my system. Thank you for your help. Eva