Discussions

News: Xwork 1.0 and WebWork 2.0 Released

  1. Xwork 1.0 and WebWork 2.0 Released (38 messages)

    Opensymphony's Xwork 1.0 and WebWork 2.0 have been released. This is the first release of a complete rewrite of WebWork, a hierarchical pull-MVC framework. Xwork is a generic command pattern implementation with no dependencies on web specific libraries. WebWork 2.0 sits on top of Xwork to provide the "web" stuff.

    Xwork

    "Xwork is a generic command pattern implementation with no dependencies on web specific libraries. Xwork adds powerful features to command processing including interceptors, the OGNL () expression language, an IoC (Inversion of Control) container, flexible type conversion, and a powerful validation framework."

  2. Interceptors allow arbitrary code to be included in the call stack for your Action before and/or after processing of the Action, which can vastly simplify your code itself and provide excellent opportunities for code reuse. Many of the features of XWork and WebWork 2 are implemented as Interceptors and can be applied via external configuration along with your own Interceptors in whatever order you specify for any set of Actions you define.
  3. OGNL is used throughout XWork to allow dynamic object graph traversal and method execution where needed and can transparently access properties from multiple beans using our ValueStack.
  4. XWork IoC allows for code dependencies to be made explicit and centrally managed while simplifying your Action code. Components required by your actions will be instantiated and maintained in a
    hierarchy of three scopes (application <- session <- request) and will be provided to your actions automatically, removing the need for boilerplate code to lookup required services from a registry or hardwired dependencies on a service implementation class.
  5. The XWork Validation Framework allows you to define your validations for a class in external XML files and have them applied at runtime automatically (using an Interceptor). It is very flexible framework, allowing for different validations for the same class in different contexts with defaults and inherited validations. Passing the validation context on to your domain objects to allow them to be validated using their own validation definitions is also supported. The Validation Framework also ties in with XWork’s excellent i18n
    localization for multi-language messages.


  6. "XWork is completely generic, and can be applied to any request/response paradigm. The JPublish project has added support for XWork Actions in addition to its internal command pattern implementation. Possible future implementations built on XWork include a JSR-168 Portlet implementation as a Dispatcher for XWork, a JMS dispatcher, a command line dispatcher, and JSF integration."

    WebWork

    "WebWork2 is built as a set of Interceptors, Results, and Dispatchers on top of XWork. WebWork2’s view technologies include JSP, Velocity, JasperReports, XSLT, and FreeMarker. WebWork2 comes with a small but powerful set of JSP tags and Velocity macros which make use of OGNL’s expression parser and XWork’s ValueStack to provide for easy and expressive web page development. WebWork2’s JSP tags and Velocity macros are built upon a flexible templating system, allowing you to customize the output of the tags by providing your own set of templates. WebWork2 also comes with powerful pre-built components to make web application development faster and easier such as a combination of a token JSP tag / macro and an Interceptor which prevent duplicate form submissions. WebWork2 also provides the standard web application framework features such as servlet redirect and request dispatcher results and multipart file uploading support."

    Links

    Xwork and WebWork Release Announcement

    Xwork: home page, docs
    WebWork: home page, docs

    Congrats to Jason, Pat, and the entire team!

Threaded Messages (38)

  • why XML configuration?[ Go to top ]

    Could someone talk a bit about why XML configuration
    files are used in all the frameworks? It turns something that
    could be lite weight into something heavy weight.

    An application really knows all this stuff at runtime
    and could do all the registrations at runtime without
    complex configuration files. I wonder if the extra
    flexibility is really needed or even used once an
    app is working.
  • why XML configuration?[ Go to top ]

    Well, for us if you're using a config file of some sort it needs to be XML because our config is not a simple flat structure, but a hierarchical structure.

    If you want, you can configure it via code, and many of our unit tests do just this. Just implement ConfigurationProvider and go to it...
  • why XML configuration?[ Go to top ]

    Well, for us if you're using a config file of some sort it needs to be XML because our config is not a simple flat structure, but a hierarchical structure.

    >
    > If you want, you can configure it via code, and many of our unit tests do just this. Just implement ConfigurationProvider and go to it...

    The real question is why do you need any config at all?
    What is configing that isn't done more easily as just
    a normal part of the application?

    The documents dis singleton's pretty heaviliy, but it's quite
    obvious in my code to set a reference by going and getting
    a reference from somewhere rather than using a magic layer
    using a magic config file to ioc them.

    Is this a case of being too clever, or is there a real win? If there's
    a real win, what is it? I am concerned that we have ever less visibility
    into what's happening, especially with AOP and configuration.
  • Declarative programming - simpler code[ Go to top ]

    XML configuring just makes your business logic code much more simple. It removes all that plumbing, technical, not related to business domain logic from your code, and thus makes your code more readable, more simple, more maintainable. Yes it becomes "less visible", but hey, you do not see what OS is doing with your code anyway. Why do you need complete visibility, if you have to pay for that with obscured spagetti code ?
  • why XML configuration?[ Go to top ]

    The real question is why do you need any config at all?

    > What is configing that isn't done more easily as just
    > a normal part of the application?
    >
    > The documents dis singleton's pretty heaviliy, but it's quite
    > obvious in my code to set a reference by going and getting
    > a reference from somewhere rather than using a magic layer
    > using a magic config file to ioc them.
    >
    > Is this a case of being too clever, or is there a real win? If there's
    > a real win, what is it? I am concerned that we have ever less visibility
    > into what's happening, especially with AOP and configuration.

    We're not talking AOP or IoC in the xwork.xml configuration file... In the xwork.xml file you configure the Action classes to be executed and map them to names, which will be part of the URL. You also map logical results to some result class, for instance an "error" result can be mapped to an error.jsp page or a "success" result can be mapped to chaining to another Action class. You also configure Interceptors to be executed before and/or after your Action is executed. You wouldn't want to reference this in your Action code, because this would decrease the value of Interceptors as external code which can be transparently applied to the call stack of your Action without the Action having to know about it. Interceptors in WebWork 2.0 are a lot like basic AOP, without the proxy or classloading magic.

    There's a separate configuration file for the IoC container. It's pretty simple too, and just tells the container what the components are, and how to identify clients of that component which need to have it supplied.
  • What about documentation, tools?[ Go to top ]

    Well this is great but my main concern is that now that struts has been around for a while there are a number of tools out there which help build a struts application that are not available for WebWork. I know this is a catch22 situation but the framework must be a whole generation better than struts for me to switch because switching would mean giving up on the struts tools I've come to love (MyEclipse in my case).
  • What about documentation, tools?[ Go to top ]

    Well this is great but my main concern is that now that struts has been around for a while there are a number of tools out there which help build a struts application that are not available for WebWork. I know this is a catch22 situation but the framework must be a whole generation better than struts for me to switch because switching would mean giving up on the struts tools I've come to love (MyEclipse in my case).


    I can assure you that we ARE a generation ahead... actually, WebWork 1.x was a generation ahead of Struts, and this is the next go-round of WebWork, so maybe you should say we're more than one generation ahead ;-)

    Also, many of the tools needed for Struts are needed because of the complexity and extra work forced on you by Struts. We prefer to make things simpler, so tools are not as necessary. That said, Jon Lipsky made a cool Xwork.xml editor GUI app that ships with XWork.
  • Xworks similar to Spring ?[ Go to top ]

    Looks like Xworks+WebWork and Spring have a lot in common.
    I adopted Spring recently to use in new project.
    So far I'm happy with it and especially with AOP featurs and Hibernate integration.

    Can somebody comment on what's common/different in these 2 frameworks ?
  • Xworks similar to Spring ?[ Go to top ]

    Looks like Xworks+WebWork and Spring have a lot in common.

    > I adopted Spring recently to use in new project.
    > So far I'm happy with it and especially with AOP featurs and Hibernate integration.
    >
    > Can somebody comment on what's common/different in these 2 frameworks ?

    WebWork is a web application MVC framework. XWork is a generic command pattern implementation with nifty features for processing requests (i.e. web requests, command line, JMS, etc.). WebWork is built on XWork.

    In this way, WebWork overlaps with Spring's MVC framework.

    XWork also contains a simple IoC container. This is really meant for small apps where you have a few components you want to automatically provide to your Actions (and you don't need more than one of the same type). It's really really handy for these situations because you don't need any per-Action configuration. It falls short of the capabilities of a Spring or Picocontainer IoC container.

    So there is some overlap, but there is more synergy, I think. There is good integration between WebWork and Spring, much of it done by the guys at Atlassian. They are building their new product, Confluence, on WebWork 2, Spring, Hibernate, Sitemesh, Lucene, Quartz, etc... They have the power of WebWork and XWork as a powerful Web MVC front end, along with the power of Spring to automatically wire components together, and Hibernate's transparent persistence. From the feedback I've heard from them, it's an awesome combination.
  • Xworks similar to Spring ?[ Go to top ]

    First of all, congratulations to Patrick, Jason & co for getting the final release out!

    Seconding Jason, there's indeed a lot of synergy between web frameworks and Spring. Spring is a strictly layered framework and strives for maximum reusability, be it as plain core container, as data access library, as full-fledged middle tier framework, or as comprehensive application framework that also covers the web tier. It lends itself nicely to all those scenarios.

    So while Spring provides its own web MVC framework (applying the same configuration style as the rest of the framework), its core focus is on lightweight container and middle tier services, in particular transaction management, data access, and lightweight remoting. We have numerous users that combine a Spring middle tier with Struts, WebWork, Tapestry, etc.

    With Spring, it's all about choice. Choose your data access strategy, choose your transaction strategy, choose your remoting strategy, choose your web framework. Besides the pre-built integrations for JDBC, JDO, Hibernate, iBATIS SQL Maps, JTA, RMI, JAX-RPC, etc, it is straightforward to integrate other data access strategies and - in particular - web frameworks.

    The Spring sample apps illustrate a selection of choices: Petclinic has a Spring web tier with alternative Spring JDBC and Hibernate web tiers. JPetStore has alternative Struts and Spring web tiers, with iBATIS SQL Maps as data access strategy. Furthermore, JPetStore exports the same remote service via Hessian, Burlap, JAX-RPC/Axis, and transparent RMI.

    Juergen
  • WW + Spring[ Go to top ]

    Congratulations to the WebWork team.

    >The Spring sample apps illustrate a selection of choices...JPetStore has alternative Struts and Spring web tiers...
    Maybe we should work together to provide a XW/WW2/Spring sample application, as there's a lot of interest in this combination.

    WW's command pattern web framework offers a different programming model to Spring or Struts. It's great to have different choices, and from what I've seen of it, WW2 has an elegant architecture.

    Regards,
    Rod
  • WW + Spring[ Go to top ]

    Maybe we should work together to provide a XW/WW2/Spring sample application, as there's a lot of interest in this combination.


    That would indeed be nice. As far as I've seen, today's WebWork2 release contains the ExternalReferenceResolver mechanism but unfortunately not the Spring implementation of it that's used in Confluence (and hardly any docs on it). I haven't been able to find anything on the OpenSymphony Wiki either.

    Of course, the ExternalReferenceResolver is just an option, but I think it would be appropriate for a WW2/Spring sample app. (The other option is to explicitly access the Spring root web application context from within WebWork2 actions, via the ServletContext).
     
    > WW's command pattern web framework offers a different programming model to Spring or Struts. It's great to have different choices, and from what I've seen of it, WW2 has an elegant architecture.

    Good point: XWork/WebWork2 are entirely built on the command paradigm, while Struts and Spring web MVC focus on servlet-style reusable controller instances. Both approaches have their merits (and so has the page-centric approach of Tapestry); it's good to have a number of choices here.

    I'm impressed by the flexibility of XWork/WebWork2 too. Generally, it's an interesting way to model a web tier, and a good indication that there are multiple viable ways to approach web MVC (servlet-style controllers vs command-style controllers vs page controllers etc).

    Juergen
  • WW + Spring[ Go to top ]

    Maybe we should work together to provide a XW/WW2/Spring sample application, as there's a lot of interest in this combination.

    >
    > That would indeed be nice. As far as I've seen, today's WebWork2 release contains the ExternalReferenceResolver mechanism but unfortunately not the Spring implementation of it that's used in Confluence (and hardly any docs on it). I haven't been able to find anything on the OpenSymphony Wiki either.
    >

    Yes, the ExternalReferenceResolver is in there. We didn't want to include any specific integrations in XWork / WebWork at this time, so those will be in a separate project (either webwork-extensions or Conductor, which I plan to start working on now that XW / WW are out the door). We need to hit Atlassian up for the latest Spring integration code and get going ;-)

    I think it's definitely a good time to look at an example app with these technologies, and I'm thinking Conductor is a good place to build it.

    >
    > I'm impressed by the flexibility of XWork/WebWork2 too. Generally, it's an interesting way to model a web tier, and a good indication that there are multiple viable ways to approach web MVC (servlet-style controllers vs command-style controllers vs page controllers etc).
    >
    > Juergen


    Yep, choices are good. Personally I think new instances of Actions per request give a lot of flexibility over reusable controllers, since you don't have to worry about thread safety, etc. Tapestry, of course, is a whole other beast :-)
  • WW + Spring[ Go to top ]

    Yep, choices are good. Personally I think new instances of Actions per request >give a lot of flexibility over reusable controllers, since you don't have to >worry about thread safety, etc. Tapestry, of course, is a whole other beast :-)


    Actions presumably invoke operations on domain objects,
    so thread safety is as much a concern.

    I thought i've had lately is to do away with methods completely
    and have only actions.
  • Xworks similar to Spring ?[ Go to top ]

    Does WebWork 2 have the equivalent of Spring's MultiActionController? I've found it very useful for building Controllers around Use Cases, where one controller handles all the events for small to moderate sized Use Cases. This design provides a lot of coherence, where otherwise there might be a bunch of isolated Action sub-classes.

    SZ
  • Xworks similar to Spring ?[ Go to top ]

    Does WebWork 2 have the equivalent of Spring's MultiActionController? I've found it very useful for building Controllers around Use Cases, where one controller handles all the events for small to moderate sized Use Cases. This design provides a lot of coherence, where otherwise there might be a bunch of isolated Action sub-classes.

    >
    > SZ

    I assume this means you have multiple execute methods on one Action class? Yes, WebWork supports this. In the Action mapping in xwork.xml you specify both the Action class and, optionally, the method on that class to execute (it defaults to execut()). You can have multiple Action aliases mapped to the same class with different methods to be executed.
  • Xworks similar to Spring ?[ Go to top ]

    I assume this means you have multiple execute methods on one Action class? Yes, >WebWork supports this. In the Action mapping in xwork.xml you specify both the >Action class and, optionally, the method on that class to execute (it defaults to >execute()). You can have multiple Action aliases mapped to the same class with >different methods to be executed.


    Spring provides an interface called MethodNameResolver which allows you to implement your own getHandlerMethodName(HttpServletRequest request) method. What is nice about this is you don't need to have Struts-like configuraton file entries for every method. Instead you can map request parameters, using your own patterns, to the method names. When you have many event-handling methods for a very large system, this simplifies configuration significantly.
  • Xworks similar to Spring ?[ Go to top ]


    > Spring provides an interface called MethodNameResolver which allows you to implement your own getHandlerMethodName(HttpServletRequest request) method. What is nice about this is you don't need to have Struts-like configuraton file entries for every method. Instead you can map request parameters, using your own patterns, to the method names. When you have many event-handling methods for a very large system, this simplifies configuration significantly.

    You could easily implement this as an Interceptor in WebWork, or just use the configuration to automatically call the method named in the configuration.

    Jason
  • javascript validation[ Go to top ]

    first of all, congratulations!!

    Does Webwork supports client-side validation with javascript ?

    will it be implemented?
  • javascript validation[ Go to top ]

    first of all, congratulations!!

    >
    > Does Webwork supports client-side validation with javascript ?
    >
    > will it be implemented?

    The current release does not. See my blog entry at http://jroller.com/page/jcarreira/20040205#webwork2_answers for more info on how this could be implemented...
  • The download link is too hard to find[ Go to top ]

    The download link is too hard to find
  • The download link is too hard to find[ Go to top ]

    The download link is too hard to find


    XWork 1.0 Final : http://xwork.dev.java.net/files/documents/709/2885/xwork-1.0.zip

    WebWork 2.0 Final : http://webwork.dev.java.net/files/documents/693/2886/webwork-2.0.zip
  • Hibernate + WebWork2 Demo App[ Go to top ]

    In case anyone missed it, we have a Hibernate/WebWork2 demo application at:

    http://hibernate.org/Documentation/OnlineDocumentation

    Enjoy :)
  • WebWork2+Spring+Hibernate[ Go to top ]

    I'm using WebWork2,Spring,hibernate to develop new products and components. All are great and combine fine.
  • WW2+Spring[ Go to top ]

    I'm using WebWork2,Spring,hibernate to develop new products and components. All are great and combine fine.


    Could you please share your experience in integrating WebWork2 & Spring.

    Any documentation would be much help full.

    SH
  • WW2+Spring[ Go to top ]

    This is my experience:
      I first using Hibernate in some project. Every project is B/S and under high load. Fortunately, all passed and work well. Cache is very useful.
      But there are two issues:
      1. some project need global transaction and some need local transaction.
      2. some database can't maaping or mapping is a diffcult job.
      So I looking for a solution that can configure it. I found Sping that can solve it. It can configure as your porject need and no coding.
      I using struts in some project. But I found that if you using struts, web developing need more time. The most that I wanted is that form can map a object. So I found that WebWork2 can do it. Also it combine Velocity good and web developing need less time.
      After I detail research almost every framework, I found that WW2+Spring+Hibernate is best solution.
  • please have a little mercy[ Go to top ]

    Now that I have sacrificed a whole week-end to study Spring then come this. I never catch up! In this way I will never get any work done but is forever and forever doomed to learn new tools.

    Regards
    Rolf Tollerud
    (BTW is Richard Öberg still involved with Webwork?)
  • please have a little mercy[ Go to top ]

    Now that I have sacrificed a whole week-end to study Spring then come this. I never catch up! In this way I will never get any work done but is forever and forever doomed to learn new tools.

    >

    Why? Looking for quality code to port to .NET?

    > Regards
    > Rolf Tollerud
    > (BTW is Richard Öberg still involved with Webwork?)
  • please have a little mercy[ Go to top ]

    (BTW is Richard Öberg still involved with Webwork?)


    Rickard is involved as a user. His product uses WebWork 1.x right now, but he just said on the mailing list that he's planning to move to 2.0 when they can schedule the time.

    AFAIK Rickard hasn't been involved in any Open Source projects this last year, because he's been very busy building a product and a company (completely understandable).
  • please have a little mercy[ Go to top ]

    Now that I have sacrificed a whole week-end to study Spring then come this. I never catch up! In this way I will never get any work done but is forever and forever doomed to learn new tools.

    >
    > Regards
    > Rolf Tollerud
    > (BTW is Richard Öberg still involved with Webwork?)

    try running a bit faster Rolf :)
  • Xwork 1.0 and WebWork 2.0 Released[ Go to top ]

    In Rickard we trust.
  • WebWork 2 Demo App[ Go to top ]

    Over the last few months, I've upgraded from WebWork 1.3 to WebWork2/XWork and started using Hibernate in my open source project OpenReports. Both projects have saved me a lot of time, and I would like to thank the developers for their hard work.

    If anyone is interested in a demo application that uses WebWork2, Hibernate, Velocity, and a number of other open source components, take a look at OpenReports. The code can be found at http://sourceforge.net/oreports

    Erik
  • The link doesnt work[ Go to top ]

    The open reports source forge link is not working. please give the correct link.
  • The link doesnt work[ Go to top ]

    The open reports source forge link is not working. please give the correct link.


    Sorry about that, the link should be:

    http://sourceforge.net/projects/oreports
  • Xwork 1.0 and WebWork 2.0 Released[ Go to top ]

    Congrats to the whole xwork/ww2 team. It truly is a great product. There are few tools out there that offer such a great combo of simplicity and depth. It's pretty simple to get basic things going (MUCH simpler than struts, IMHO). There's also a lot of depth behind the covers so you can deal with much more complex issues. The interception framework alone is worth the price of admission (FREE!).

    It's projects like this (and hibernate) that keep my faith in the open source community. It's amazing to think back even five years ago and think about how much money you would have to spend on rolling your own tool or buying some proprietary vendor thingie to get less functionality than you can get now for free.
  • Still not a lot of documentation[ Go to top ]

    WebWork2 does not compare well with other projects as far as documentation and examples. Hard to judge it from sketchy reviews here and there, although it sounds good from the reviews.

    In contrast, OpenReports has terrific documentation.
  • Implicit action mappings[ Go to top ]

    In WebWork 1.x, the example views.properties configuration file(s) typically included explicit mappings between an action "alias" and a Java class. For example:
    formtest.action=com.foo.action.FormTest
    formtest.input=formtest.jsp
    formtest.success=formtest.jsp
    formtest.error=formtest.jsp

    However, at some point I realized that I could avoid having to include these mappings by carefully naming and locating my Java class files. So, if I defined the following property in my webwork.properties file:
    webwork.action.packages=com.foo.action
    and I created a class named com.foo.action.formtest (note the all-lowercase class name), I could go without the explicit action alias mappings, as such:
    formtest.input=formtest.jsp
    formtest.success=formtest.jsp
    formtest.error=formtest.jsp

    I've always loved this very undocumented ability of WebWork 1.x, because 90% of the time (probably even more often), your action name and your class name are more or less equivalent (aside from the conflicts caused by the disjoint between Java camelcap naming conventions and the usability gains from using all lowercase URL's).

    Bottom line: can I still get away with this in WebWork/XWork 2.0?
  • great work[ Go to top ]

    Webwork is so far the best web framework I ever used. I can see there are a lot of improvement in WW2.0. It gives me exact what I need. Compared with Struts, its simpler, faster, and nicer. But need to improve on Documentation. Sometime I have to dig into the source code to find out the answer. However, I am surprised to find out the source code is very well written.

    Well done job!!! and Many congra!!!!