WebWork merging with Struts to become Struts Ti

Home

News: WebWork merging with Struts to become Struts Ti

  1. Patrick Lightbody, in "WebWork joining Struts," has announced that WebWork is going to merge into Struts, becoming the "Struts Action Framework 2.0." The main benefit for WebWork, he says, is the Struts community, while Ted Husted says (in an email, "Merger with WebWork") that the intention for Struts Ti was to use WebWork as the core for the action framework.

    Some WebWork users are happy with the merge, with the potential for the use of the Apache name being a huge benefit for recognition and support. Others have questioned the need, since WebWork is self-sustaining (and, in fact, has recently picked up momentum, with a new book being published and more committers joining the development team.)

    Struts has undergone a lot of activity lately, with Shale, Struts 1.3, a scripting extension, and other things as well.

    Is there a push for a "single web framework" in Java? The JCP has produced a specification, JavaServer Faces, for web frameworks, which clearly doesn't address all use cases (i.e., WebWork is an extension of XWork, an action framework, with web functionality, and JSF doesn't address the AJAX pattern of having all user flow downloaded as required.) Some have said that it would be an advantage for Java to have a single framework, as Microsoft does, to reduce conflict and code invested merely to fulfill feature comparisons. Is that what you think? Is the merger of frameworks a good thing for web developers?

    Threaded Messages (129)

  2. I think that is a good idea.
  3. +1

    I've been using both Struts and Webwork for a couple of years and I've always liked Webwork better. However, I think Struts has a some advantages and they are user community, documentation and examples. Webworks documentation has always been flooded with "todo" and "write something here" while the Struts docs have been, how should I put it, hmmm, yeah, better! :-)

    If we, with this merge, get Webworks functionallity with Struts community, documentation and examples I'm all for it!

    Regards Peter
  4. This is exactly the opportunity we saw when the idea originally came up. We've had the technology, but we've struggled with all of the stuff around it to make it useful for a larger community (i.e. it's only useful to someone else if they can figure out how to use it). <shameless_plug>The book is helping<\shameless_plug>, but we needed to bring the message to a larger audience to get more activity around docs, tools, etc.
    +1I've been using both Struts and Webwork for a couple of years and I've always liked Webwork better. However, I think Struts has a some advantages and they are user community, documentation and examples. Webworks documentation has always been flooded with "todo" and "write something here" while the Struts docs have been, how should I put it, hmmm, yeah, better! :-)If we, with this merge, get Webworks functionallity with Struts community, documentation and examples I'm all for it!Regards Peter
  5. Do you forsee existing WW2.2 users to be able to upgrade? Is it an "upgrade" or is it a lateral move to another architecture?
  6. Do you forsee existing WW2.2 users to be able to upgrade? Is it an "upgrade" or is it a lateral move to another architecture?

    It's the same architecture. It may be a lateral move to another set of packages, i.e.

    com.opensymphony.webwork may become org.apache.something...

    The upgrade path for existing WebWork users should be minimal. The main goal of the first phase of Struts Ti will be to add OPTIONAL backwards compatibility code to support existing Struts AF Classic users.
  7. Congrats for this move[ Go to top ]

    MO this move was overdue. Struts technology side could be highly enhanced by WebWorks technology and WebWork is almost useless with the current momentum and userbase. So the merger makes perfectly sense.
    I do not see it as a direkt rival for JSF. JSF is more component based and there will be enough frameworks emerging on the JSF-Side, coping with limitations of JSF and enhancing it.
    So Struts/WebWork is rather the JSF counterpart which is needed.
    I wish the Struts and WebWork teams the best in joining forces.
  8. This has to be a good thing![ Go to top ]

    I think a single MVC2 web framework is definitely something we need in the Java world because they are quite similar anyway, but we still have room for other kinds of web frameworks, such as, Tapestry and RIFE.

    /Tommy
    VisionProject
    Issue tracking and project management made easy
  9. This has to be a good thing![ Go to top ]

    I think a single MVC2 web framework is definitely something we need in the Java world because they are quite similar anyway

    I really disagree. Java has always been (in my opinion) about choice - choices of frameworks, choices of VMs from different vendors, and choices of deployment platforms. Although debate about different frameworks for things such as mvc2/web and pojo persistence in Java can get rather intense at times, I think it does nothing but good for Java as a whole.
  10. This has to be a good thing![ Go to top ]

    I think a single MVC2 web framework is definitely something we need in the Java world because they are quite similar anyway
    I really disagree. Java has always been (in my opinion) about choice - choices of frameworks, choices of VMs from different vendors, and choices of deployment platforms. Although debate about different frameworks for things such as mvc2/web and pojo persistence in Java can get rather intense at times, I think it does nothing but good for Java as a whole.

    Well, then we don't have the same opinion in this matter... I absolutely agree with you that choice *is good thing* but today I think we have learned enough to be able to create one single good request-based web framework. Webwork is in my opinion the best in this arena so this merge can be a really, really good thing.

    /Tommy
    VisionProject
    Issue tracking and project management made easy
  11. This has to be a good thing![ Go to top ]

    ... I think we have learned enough to be able to create one single good request-based web framework.
    That is hardly the point, though. The goals of Java as a platform are not those of Microsoft - there is indeed not one way to do a web framework (or anything else for that matter). There always needs to be choice. Now, something like WebWork or the as-yet-to-arrive Ti might be considered the core of a generic action-style web framework (might it go JSR?), but there would still need to be different implementations with various value adds, etc.
  12. This has to be a good thing![ Go to top ]

    Well, then we don't have the same opinion in this matter... I absolutely agree with you that choice *is good thing* but today I think we have learned enough to be able to create one single good request-based web framework. Webwork is in my opinion the best in this arena so this merge can be a really, really good thing.

    You illustrate my point of view well. It is your opinion that Webwork is the best in this arena. Java is about the freedom to have a range of opinions.
  13. This has to be a good thing![ Go to top ]

    Well, then we don't have the same opinion in this matter... I absolutely agree with you that choice *is good thing* but today I think we have learned enough to be able to create one single good request-based web framework. Webwork is in my opinion the best in this arena so this merge can be a really, really good thing.
    You illustrate my point of view well. It is your opinion that Webwork is the best in this arena. Java is about the freedom to have a range of opinions.

    I agree with you. As soon as someone says "X is the best" I get worried. If Webwork was the best for *me*, I would be using Webwork, not Struts. I think that there is from for several web frameworks based on user preference, not an ejb-ish all knowing standard.
  14. This has to be a good thing![ Go to top ]

    Shut your primitive yappers and let natural selection take its course. You are but voiceless amoebas in the primordial soup that is computing today.
  15. This has to be a good thing![ Go to top ]

    This is definetly a good news about choice in the Java world. IT managers no longer *have* to choose committee designed JSF just because Struts is dated and WebWork does not have much community, especially when request driven MVC2 is more natural in many Web applications than event driven / component based JSF or Tapstry (or even ASPNET on that matter).
  16. This has to be a good thing![ Go to top ]

    IT managers no longer *have* to choose committee designed JSF just because Struts is dated and WebWork does not have much community

    Whatever the merits or otherwise of the different frameworks, I sense some sort of implied criticism of committee design here. Maybe it is just me, but I find the idea of a standard that has been devised by a range of industry experts, and so is likely to be supported over the long term by a number of vendors to be of benefit for developers. There are valid criticisms of JSF, but I just can't see the fact that it evolved as proposal from a JSR committe to be one of them. Quite the reverse.
  17. This has to be a good thing![ Go to top ]

    Quoted from someone else's post:
    I think that there is from for several web frameworks based on user preference, not an ejb-ish all knowing standard.
  18. This has to be a good thing![ Go to top ]

    Whatever the merits or otherwise of the different frameworks, I sense some sort of implied criticism of committee design here. Maybe it is just me, but I find the idea of a standard that has been devised by a range of industry experts, and so is likely to be supported over the long term by a number of vendors to be of benefit for developers. There are valid criticisms of JSF, but I just can't see the fact that it evolved as proposal from a JSR committe to be one of them. Quite the reverse.

    I agree with most of the posters in the thread: TSS Asks: Are standards a bad thing? who thinks standards should be established when a technology has matured. As I said before, I like choices as well but, again, we know enough about request-based web frameworks to be able to "create" a de-facto standard and this merge looks very promising... and vendors will support a de-facto standard as well...

    /Tommy
    VisionProject
    Issue tracking and project management made easy
  19. This has to be a good thing![ Go to top ]

    As I said before, I like choices as well but, again, we know enough about request-based web frameworks to be able to "create" a de-facto standard and this merge looks very promising... and vendors will support a de-facto standard as well...

    Again, I disagree, in many respects. Firstly, I see no evidence that vendors will support de-facto standards. Secondly, I think that Java needs more than just de-facto standards. If you look at the way things have progressed, you will see that there is move to consolidate such approaches into JSRs (think of Hibernate and JSR 220). Thirdly, I don't think we know anything like enough about web frameworks yet to think about having one standard, de-facto or not. The strong (healthy) debate on this matter shows that there is far from a broad agreement about what such frameworks should be like. Personally, I think even talking about 'web' frameworks is too limiting. (For example, JSF is not just a web framework, it is a general server-side UI framework that can be used with a range of remote UI technologies).

    I would like to see a range of JSR standards for handling a range of approaches to web and server-side development. Even as a strong supporter of JSF, I accept that there are other ways to do things and they should be supported.
  20. This has to be a good thing![ Go to top ]

    As I said before, I like choices as well but, again, we know enough about request-based web frameworks to be able to "create" a de-facto standard and this merge looks very promising... and vendors will support a de-facto standard as well...
    Again, I disagree, in many respects. Firstly, I see no evidence that vendors will support de-facto standards.

    Are you serious? This is the single biggest reason we wanted to merge with the Struts team. Hell, there are more tools supporting Struts than there are supporting JSF, and JSF was designed by tool vendors FOR tool vendors.
    Secondly, I think that Java needs more than just de-facto standards.

    Because Sun has such a great track record building applications and web applications? Or because design by committee is such a wonderful boon to the industry?
    If you look at the way things have progressed, you will see that there is move to consolidate such approaches into JSRs (think of Hibernate and JSR 220). Thirdly, I don't think we know anything like enough about web frameworks yet to think about having one standard, de-facto or not. The strong (healthy) debate on this matter shows that there is far from a broad agreement about what such frameworks should be like.

    So then what are you arguing for? Did you want us to submit Struts Ti to the JCP for standardization? Why tout JSF on this thread if you think we should have more than one "standard"?
    Personally, I think even talking about 'web' frameworks is too limiting. (For example, JSF is not just a web framework, it is a general server-side UI framework that can be used with a range of remote UI technologies).

    Yes, and WebWork is built on XWork, which is a generic command-pattern framework. There's a couple of Portlet implementations on top of it, a mail processing framework, and I even built a JMS framework to execute Actions based on JMS message headers.
    I would like to see a range of JSR standards for handling a range of approaches to web and server-side development. Even as a strong supporter of JSF, I accept that there are other ways to do things and they should be supported.

    I don't see the need for standards here... Is there a pressing need? Are there several different implementations we need to standardize? I'm not a fan of standards for standards sake.
  21. This has to be a good thing![ Go to top ]

    Are you serious?

    Always.
    This is the single biggest reason we wanted to merge with the Struts team. Hell, there are more tools supporting Struts

    What I meant was alternate implementations. Having support for a de-facto standard (in the form of tools etc) is not the same as supporting the standard itself.
    than there are supporting JSF, and JSF was designed by tool vendors FOR tool vendors.

    No. JSF was, of course, designed for developers. Many developers like me like component based development. JSF was designed for developer like me.
    So then what are you arguing for? Did you want us to submit Struts Ti to the JCP for standardization? Why tout JSF on this thread if you think we should have more than one "standard"?

    Because posters are promoting the use of a single de-facto standard. I am responding to this. I am not keen on a single standard, de-facto or not.
    I don't see the need for standards here... Is there a pressing need? Are there several different implementations we need to standardize? I'm not a fan of standards for standards sake.

    Well I am. I have dealt with too many non-standard but highly popular products in the past that have ended up without support several years later.
  22. This has to be a good thing![ Go to top ]

    IT managers no longer *have* to choose committee designed JSF just because Struts is dated and WebWork does not have much community
    Whatever the merits or otherwise of the different frameworks, I sense some sort of implied criticism of committee design here. Maybe it is just me, but I find the idea of a standard that has been devised by a range of industry experts, and so is likely to be supported over the long term by a number of vendors to be of benefit for developers. There are valid criticisms of JSF, but I just can't see the fact that it evolved as proposal from a JSR committe to be one of them. Quite the reverse.

    LOL If you really think that design by committee is the best way then... well, I guess I'm speechless. JSF may have some things going for it, but I don't think I'd play up the fact that it was designed by delegates from several vendors, each with their own agenda to defend and existing tools to try to make necessary.
  23. This has to be a good thing![ Go to top ]

    This is definetly a good news about choice in the Java world. IT managers no longer *have* to choose committee designed JSF just because Struts is dated and WebWork does not have much community, especially when request driven MVC2 is more natural in many Web applications than event driven / component based JSF or Tapstry (or even ASPNET on that matter).

    It's a dicotomy market. You can eventually reach the point with application functionality where managing state in a RESTful manner (request) just won't cut it. Then frameworks like JSF or Tapestry can do a lot to 'just make things work' for complex requirements. I'm not saying where the fault lies in the hypothetical case, but to state that 'request driven' is much more natural-- more natural for what? The standard Servlet Spec?
  24. This has to be a good thing![ Go to top ]

    more natural for what?

    For many applications to be developed and maintained.
  25. This has to be a good thing![ Go to top ]

    Quoted from an earlier post:
    let natural selection take its course
  26. This has to be a good thing![ Go to top ]

    You can eventually reach the point with application functionality where managing state in a RESTful manner (request) just won't cut it. Then frameworks like JSF or Tapestry can do a lot to 'just make things work' for complex requirements.

    WebWork != Struts. Understanding Struts does not mean you understand WebWork, though that's a common misconception. WebWork is just as capable of supporting component-oriented designs as JSF and Tapestry and it has a smaller learning curve.
  27. This has to be a good thing![ Go to top ]

    You can eventually reach the point with application functionality where managing state in a RESTful manner (request) just won't cut it. Then frameworks like JSF or Tapestry can do a lot to 'just make things work' for complex requirements.
    WebWork != Struts. Understanding Struts does not mean you understand WebWork, though that's a common misconception. WebWork is just as capable of supporting component-oriented designs as JSF and Tapestry and it has a smaller learning curve.

    So Webwork manages the idea of component state on a per-view basis over multiple requests and responses? Or is the assumption that I just throw everything into the session?
  28. This has to be a good thing![ Go to top ]

    You can eventually reach the point with application functionality where managing state in a RESTful manner (request) just won't cut it. Then frameworks like JSF or Tapestry can do a lot to 'just make things work' for complex requirements.
    WebWork != Struts. Understanding Struts does not mean you understand WebWork, though that's a common misconception. WebWork is just as capable of supporting component-oriented designs as JSF and Tapestry and it has a smaller learning curve.
    So Webwork manages the idea of component state on a per-view basis over multiple requests and responses? Or is the assumption that I just throw everything into the session?

    So to generate a simple list of items to populate a drop down list via an AJAX call I have to deserialize the state of 20 UI components and go through the JSF processing lifecycle? We do things differently, I think we understand that.

    Personally, I like to maintain my state to be closer to the business process at hand, rather than spread through a bunch of UI components. Then I can scale my UI up or down and have it be context-sensitive to the session state for this usecase.
  29. This has to be a good thing![ Go to top ]

    So to generate a simple list of items to populate a drop down list via an AJAX call I have to deserialize the state of 20 UI components and go through the JSF processing lifecycle? We do things differently, I think we understand that.

    I know some large ASPNET project forbid the use of ASPNET view state and build their own in-house MVC capabilty similar to Struts/WebWork. Even MSDN has articles (and the DOTNET design pattern book)published a few years ago about mimic Struts MVC in ASPNET (in the glorious days of Struts). The DOTNET design pattern book actually suggests this should only be for large applications.

    Is the Java world so mad about catching up with .NET?
  30. This has to be a good thing![ Go to top ]

    So to generate a simple list of items to populate a drop down list via an AJAX call I have to deserialize the state of 20 UI components and go through the JSF processing lifecycle? We do things differently, I think we understand that.
    I know some large ASPNET project forbid the use of ASPNET view state and build their own in-house MVC capabilty similar to Struts/WebWork. Even MSDN has articles (and the DOTNET design pattern book)published a few years ago about mimic Struts MVC in ASPNET (in the glorious days of Struts). The DOTNET design pattern book actually suggests this should only be for large applications. Is the Java world so mad about catching up with .NET?

    yeah, I know projects that've done this. The funny part is that I've heard that .NET 2.0 will include a front controller framework like Struts or WebWork (but I'm biased so I'll say probably not as good :-) ).
  31. This has to be a good thing![ Go to top ]

    Just did a google search with "ASP.NET 2.0 front controller". Instead get ASP.NET 2.0 master page.
  32. This has to be a good thing![ Go to top ]

    Just to clear the FUD around JSF....

    JSF is Front Controller oriented! What do you think is the FacesServlet that handles every request? You can plugin applicaton wide functionalities there (in fact Shade already offer that). Don't compare to ASP.NET, wich uses a PageController and not a FrontController.

    From Core J2EE patterns :
    FrontController
    Use a controller as the initial point of contact for handling a request. The controller manages the handling of the request, including invoking security services such as authentication and authorization, delegating business processing, managing the choice of an appropriate view, handling errors, and managing the selection of content creation strategies.

    The differences is the servlet don't dispatch control to custom actions but to the Faces Lifecycle. The Faces Lifecycle is APPLICATION WIDE. On every phase, it traverses the view tree to provide the "component model".

    So please, I like diversities and I understand some people prefer using Model2 based frameworks. But stop spreading FUD around JSF technology. If it's really that bad, people will just stop using it, so no need to make a religious debate out of it. Just my 2 cents.
  33. I'd like to go from project to project and have an idea as to how to debug it for clients, so it be nice if we used similar designs so I know where to starts.

    Lets look as to why we need a popular standard:
    http://jcp.org/en/jsr/detail?id=244
    J2EE standard is JSF 1.0! that does not work w/ JSP 2.0
    (one needs JSF 1.2 and JSP 2.1 but that is not J2EE 5!)
    JSF is built out of the gate to work w/ Portlets 168, but Portlets are not a part of J2EE 5. WTF?
    This means that vendors expect developers to integrate JSF into Portlets and JSP? That does not sound like fun me explaining this to the clients.
    "Use tiles becuase....."
    Is webstart a blueprint?
    There is : http://java.sun.com/reference/blueprints
    Enough said.

    So we use Spring or Struts or XYZ.
    But if we could unite:
    http://groups.yahoo.com/group/java_web_alignment
    and just like most vendors supported Struts which was like 70% market share, when we developers go to client sites we could seem inteligent and competent (instead of "well we don't want to integrate portlets and it's hard to jsp w/ jsf and ajax, well.... "

    It has nothing to do w/ C#, look at Spring:
    http://springframework.net/doc-1.1-P2/api/html/index.html

    It's just an alternative to J2EE5, so Steve Zara could have another popular choice.

    JSF will kill J2EE5. PHB's got screwed in EJB back end, and now... the front end will seal it.

    Hani, tell them you'll hold you breath until JSF 1.2, JSP 2.1 and Portlets 168 are in!
    Fine if they ship an EJB3 server, but if it's J2EE5 it should work.
    J2EE5 DOES NOT WORK!

    Good forbit J2EE framework had client side rendering, only Shale has Ajax module AFAIK.


    .V

    http://pointcast.com (built in Netbeans, Groovy, COR, JDNC!)
  34. Vendor Standard and a popular Standard[ Go to top ]

    J2EE standard is JSF 1.0! that does not work w/ JSP 2.0(one needs JSF 1.2 and JSP 2.1 but that is not J2EE 5!

    Yes they are.

    "... the specifications that make up JEE 5..."
    http://java.sun.com/j2ee/5.0/

    includes:
    JSR252: JSF 1.2

    and
    JSR245: JSP 2.1
  35. This has to be a good thing![ Go to top ]

    So to generate a simple list of items to populate a drop down list via an AJAX call I have to deserialize the state of 20 UI components and go through the JSF processing lifecycle?

    No, you don't. Asynchronous requests can be handled outside of the processing lifecycle.
  36. This has to be a good thing![ Go to top ]

    You can eventually reach the point with application functionality where managing state in a RESTful manner (request) just won't cut it. Then frameworks like JSF or Tapestry can do a lot to 'just make things work' for complex requirements.
    WebWork != Struts. Understanding Struts does not mean you understand WebWork, though that's a common misconception. WebWork is just as capable of supporting component-oriented designs as JSF and Tapestry and it has a smaller learning curve.
    So Webwork manages the idea of component state on a per-view basis over multiple requests and responses? Or is the assumption that I just throw everything into the session?
    So to generate a simple list of items to populate a drop down list via an AJAX call I have to deserialize the state of 20 UI components and go through the JSF processing lifecycle? We do things differently, I think we understand that. Personally, I like to maintain my state to be closer to the business process at hand, rather than spread through a bunch of UI components. Then I can scale my UI up or down and have it be context-sensitive to the session state for this usecase.

    You know where I stand :-) You guys should talk to Gavin and the JBoss group about opportunity to piggy back on their scope management over business objects with Seam. While Seam was delivered to work with JSF and its *pluggable* lifecycle, it's very clear to me that it would also work for Webwork's interceptor stack if you guys could incorporate token passing over get/post requests. Then the answer simply wouldn't be 'throw it in the session and pray'
  37. This has to be a good thing![ Go to top ]

    You know where I stand :-) You guys should talk to Gavin and the JBoss group about opportunity to piggy back on their scope management over business objects with Seam. While Seam was delivered to work with JSF and its *pluggable* lifecycle, it's very clear to me that it would also work for Webwork's interceptor stack if you guys could incorporate token passing over get/post requests. Then the answer simply wouldn't be 'throw it in the session and pray'

    I don't remember saying it was 'throw it in the session and pray'. Personally I built an extension to Spring to support session-scoped components which get autowired into my Actions. With Spring 1.3 session scoped components are going to be supported out of the box, so the programming model will be the same IoC programming model for application-scoped and session-scoped components, letting you easily define what is maintained in session state in terms of POJO business objects.
  38. This has to be a good thing![ Go to top ]

    With Spring 1.3 session scoped components are going to be supported out of the box, so the programming model will be the same IoC programming model for application-scoped and session-scoped components, letting you easily define what is maintained in session state in terms of POJO business objects.

    Yes, and also in the Spring 1.3 timeframe Spring will add first-class support for "conversational scope", allowing POJO state to be associated with a multi-step 'application transaction' in a transparent fashion. This is what Spring Web Flow brings to the table.

    Keith
  39. Scoping code added to CVS[ Go to top ]

    The scoping code that's going to be released with Spring 1.3 is now available in Spring CVS.
  40. SWF has to be simplified[ Go to top ]

    to be accepted by the community. Simplify the flow model and eliminate the XML for a starter...
  41. This has to be a good thing![ Go to top ]

    You know where I stand :-) You guys should talk to Gavin and the JBoss group about opportunity to piggy back on their scope management over business objects with Seam. While Seam was delivered to work with JSF and its *pluggable* lifecycle, it's very clear to me that it would also work for Webwork's interceptor stack if you guys could incorporate token passing over get/post requests. Then the answer simply wouldn't be 'throw it in the session and pray'
    I don't remember saying it was 'throw it in the session and pray'. Personally I built an extension to Spring to support session-scoped components which get autowired into my Actions. With Spring 1.3 session scoped components are going to be supported out of the box, so the programming model will be the same IoC programming model for application-scoped and session-scoped components, letting you easily define what is maintained in session state in terms of POJO business objects.

    What Seam w/ Gavin, Richard, Thomas, etc have come up with translates to much more pertinant scopes aside from Session scope (I was very surprised when I started using WebWork and saw that you guys were 'encouraging' Spring use for components without session support). Much of what you guys are coordinating would translate well into Seam, I'm not sure about extending ActionSupport though-- is that still a requirement for executable Actions?
  42. This has to be a good thing![ Go to top ]

    What Seam w/ Gavin, Richard, Thomas, etc have come up with translates to much more pertinant scopes aside from Session scope (I was very surprised when I started using WebWork and saw that you guys were 'encouraging' Spring use for components without session support). Much of what you guys are coordinating would translate well into Seam, I'm not sure about extending ActionSupport though-- is that still a requirement for executable Actions?

    It's actually never been a requirement. We used to require actions to implement the Action interface (with the one execute() method), but even that is no longer required.
  43. This has to be a good thing![ Go to top ]

    What Seam w/ Gavin, Richard, Thomas, etc have come up with translates to much more pertinant scopes aside from Session scope (I was very surprised when I started using WebWork and saw that you guys were 'encouraging' Spring use for components without session support). Much of what you guys are coordinating would translate well into Seam, I'm not sure about extending ActionSupport though-- is that still a requirement for executable Actions?
    It's actually never been a requirement. We used to require actions to implement the Action interface (with the one execute() method), but even that is no longer required.

    I wasn't sure on that one, I was just going by examples. Then it would be presumable that I could write a custom ActionMapper for WW that would invoke methods on POJOs from any IoC container, given proper variable management-- object factory implementation?
  44. This has to be a good thing![ Go to top ]

    I wasn't sure on that one, I was just going by examples. Then it would be presumable that I could write a custom ActionMapper for WW that would invoke methods on POJOs from any IoC container, given proper variable management-- object factory implementation?

    Yep. Basically if you can take a name (either a classname or whatever you've put in the config file) and a Map of parameters and spit back an Object, then you can implement the ObjectFactory and build all of the things that WebWork uses (interceptors, results, actions, etc). We do this with Spring already. I'm not sure if the Pico integration people have done this with an ObjectFactory or not (I think they may just use interceptors to populate the objects after creation).
  45. Arent they competing frameworks?[ Go to top ]

    So far from what I read about Webwork, it does the same job as STRUTS but differently hence a diff framework. I am not sure how it will benefit either community (Struts or WebWork). From what I know WebWork encourages users to configure Spring for middle tier support, IoC etc.
  46. This has to be a good thing![ Go to top ]

    So Webwork manages the idea of component state on a per-view basis over multiple requests and responses? Or is the assumption that I just throw everything into the session?

    Ideally you keep all of the state in your domain model. For cases where you would normally as you say, "throw everything onto the session," I created an interceptor and custom result to support what Gavin calls "conversation state" in Seam.
  47. This has to be a good thing![ Go to top ]

    So Webwork manages the idea of component state on a per-view basis over multiple requests and responses? Or is the assumption that I just throw everything into the session?
    Ideally you keep all of the state in your domain model. For cases where you would normally as you say, "throw everything onto the session," I created an interceptor and custom result to support what Gavin calls "conversation state" in Seam.

    Thanks for providing an excellent example though: you've needed to create an interceptor and a custom result to do what's already built into JSF and Seam? Would you expect the average person to come up with the same solution within WW such that it's an expected methodology or standard that translates well to fledgling programmers? Do you now see the niche that JSF provides as a standard body for vendors with the problems it solves?
  48. This has to be a good thing![ Go to top ]

    Thanks for providing an excellent example though: you've needed to create an interceptor and a custom result to do what's already built into JSF and Seam? Would you expect the average person to come up with the same solution within WW such that it's an expected methodology or standard that translates well to fledgling programmers? Do you now see the niche that JSF provides as a standard body for vendors with the problems it solves?

    Ummmmmm... JSF doesn't provide this either so far as I know. That's why you need Seam.
  49. This has to be a good thing![ Go to top ]

    Thanks for providing an excellent example though: you've needed to create an interceptor and a custom result to do what's already built into JSF and Seam? Would you expect the average person to come up with the same solution within WW such that it's an expected methodology or standard that translates well to fledgling programmers? Do you now see the niche that JSF provides as a standard body for vendors with the problems it solves?
    Ummmmmm... JSF doesn't provide this either so far as I know. That's why you need Seam.

    And JSF was a standard that JBoss, the vendor, could build upon to piggy back stateful view management which supports Seam's ability to handle conversation state across the board for all users in a 'standard' way.
  50. This has to be a good thing![ Go to top ]

    And JSF was a standard that JBoss, the vendor, could build upon to piggy back stateful view management which supports Seam's ability to handle conversation state across the board for all users in a 'standard' way.

    Ha ha. Trying to detract from the fact that you just made a completely false statement about JSF? Do you even use JSF?

    Following your logic, I can a) write clean code with WebWork or b) write crappier code using JSF but have the option of switching vendors? I'll take WebWork.

    Did Gavin choose to build Seam on JSF because JSF is a standard? He probably chose the framework he thought would achieve the greatest adoption. Before this announcement I would have agreed.
  51. This has to be a good thing![ Go to top ]

    (please excuse me for replying to myself)
    Do you even use JSF?

    Oops. You're on the JSF expert group. I guess you could say you're a little biased. ;)

    As a designer of a web framework, have you taken a close look at the competition, namely WebWork? I was on a panel with another member of the JSF expert group (who shall remain nameless) a few years back. He openly and shamelessly admitted he hadn't. I personally don't understand that. When I design an API, I try to learn everything I can from what's already available.
  52. This has to be a good thing![ Go to top ]

    (please excuse me for replying to myself)
    Do you even use JSF?
    Oops. You're on the JSF expert group. I guess you could say you're a little biased. ;)As a designer of a web framework, have you taken a close look at the competition, namely WebWork? I was on a panel with another member of the JSF expert group (who shall remain nameless) a few years back. He openly and shamelessly admitted he hadn't. I personally don't understand that. When I design an API, I try to learn everything I can from what's already available.

    Big oops.

    Biased, no. I'm using WebWork on a project right now... yet another oops. Like I said, there are niches that JSF solves, very well, and there are cases where you don't have a complex UI and you can pursue WebWork or Struts. As for Gavin's reasons for using JSF with Seam, well, I have brought up Seam integration with WebWork's interceptor stack and the initial response was negative. So Bob, what other pointent comments can you share?
  53. This has to be a good thing![ Go to top ]

    Big oops. [...] So Bob, what other pointent comments can you share?

    Actually, I was trying to be nice about the fact that you're on the JSF expert group and you don't even know how JSF manages state. I think that was generous considering you insulted me first. Also, I think you mean "poignant."
    Like I said, there are niches that JSF solves, very well, and there are cases where you don't have a complex UI and you can pursue WebWork or Struts.

    Perhaps you aren't using WebWork effectively. I've always found that I could do more with less code compared to JSF. Maybe I haven't worked on any "complex" UIs. ;)
  54. This has to be a good thing![ Go to top ]

    Big oops. [...] So Bob, what other pointent comments can you share?
    Actually, I was trying to be nice about the fact that you're on the JSF expert group and you don't even know how JSF manages state. I think that was generous considering you insulted me first. Also, I think you mean "poignant."
    Like I said, there are niches that JSF solves, very well, and there are cases where you don't have a complex UI and you can pursue WebWork or Struts.
    Perhaps you aren't using WebWork effectively. I've always found that I could do more with less code compared to JSF. Maybe I haven't worked on any "complex" UIs. ;)

    I no how to programm, not spel, and have been enjoying wisconsin-brewed beverages after dinner ;-)

    Seriously though, I think there's lots of merit with webwork and have been watching the clarity and struts ti discussions.

    There are cases where you do need to manage state across multiple facets of the page-- a sortable table, a tree menu, a form-- all at once. If I choose to use WebWork or Struts, my first issue is how am I going to manage or control the lifecycle of the view in relation to subsequent requests. The first thing I could do is handle this page as a special case and code for parameter management across the board, secondly, I could just throw everything into the session, but then I worry about re-use. Would I take the above situation and believe that an entry level programmer could correctly manage all of those concerns correctly-- probably not.

    Enter JSF or Tapestry or Wicket-- component/event based frameworks. Their capabilities in managing these issues for you come at a price, as Jason reminds us, but they do a lot of heavy lifting, logically, for you. The project I'm working on right now, is very RESTful with requests with a high number of users, so I've opted to use WebWork over Struts because it works well with the same POJO concepts that I've enjoyed and promoted with JSF.
  55. This has to be a good thing![ Go to top ]

    There are cases where you do need to manage state across multiple facets of the page-- a sortable table, a tree menu, a form-- all at once. If I choose to use WebWork or Struts, my first issue is how am I going to manage or control the lifecycle of the view in relation to subsequent requests.

    Thank you Jacob. I think when you talk about JSF being better at managing "complex" UIs and action frameworks being bad at it you raise a lot of hackles. When I think what you really mean is, to be verbose, "UIs with several independent or inter-related stateful components". I agree that managing pages like that can be quite tedious in action oriented frameworks. But those are just one flavor of "complex" UIs. I've built extremely complex UIs using action frameworks, but they do tend to have a single focus, or a set of components that work with the same data.

    Since you tend to make this point a lot (or at least that's my impression from reading the TSS threads), it'd be great to see you make it in this manner more often.

    -Tim Fennell
    Stripes: Because web development should just be easier.
  56. This has to be a good thing![ Go to top ]

    There are cases where you do need to manage state across multiple facets of the page-- a sortable table, a tree menu, a form-- all at once. If I choose to use WebWork or Struts, my first issue is how am I going to manage or control the lifecycle of the view in relation to subsequent requests.
    Thank you Jacob. I think when you talk about JSF being better at managing "complex" UIs and action frameworks being bad at it you raise a lot of hackles. When I think what you really mean is, to be verbose, "UIs with several independent or inter-related stateful components". I agree that managing pages like that can be quite tedious in action oriented frameworks. But those are just one flavor of "complex" UIs. I've built extremely complex UIs using action frameworks, but they do tend to have a single focus, or a set of components that work with the same data.Since you tend to make this point a lot (or at least that's my impression from reading the TSS threads), it'd be great to see you make it in this manner more often.-Tim FennellStripes: Because web development should just be easier.

    It can be challenging, and it sounds like something we can improve on. I'll say that with the WebWork Action tag, this can be pretty simple now. Each of these actions will get the request parameters and be able to update their own state while we're rendering the page.

    With AJAX, though, I see this sort of "full page refresh updating independent state of different UI components" being much MUCH less important. I can make the different parts of my page as different DIV panels which can automatically refresh themselves and hook into in-page eventing to send updates, etc. The server-side of the calls needed to update the page is, IMO, better suited to be handled by an action-based framework than a component-based one.
  57. With AJAX, though, I see this sort of "full page refresh updating independent state of different UI components" being much MUCH less important. I can make the different parts of my page as different DIV panels which can automatically refresh themselves and hook into in-page eventing to send updates, etc. The server-side of the calls needed to update the page is, IMO, better suited to be handled by an action-based framework than a component-based one.
    I have a different feeling regarding this. IMO, having components greatly helps solve some situations like, for example, having a combobox selection which replaces another combobox's values dinamically using AJAX. Having components makes it clear where and how events and changes happen through the page. How's an action based framework going to deal with this? IMO it would require a complex client-side framework for mapping responses to actual page changes. Having a server-side component-oriented framework may simplify it a lot, since both sides are "talking in the same language", no impedance mismatching.
  58. With AJAX, though, I see this sort of "full page refresh updating independent state of different UI components" being much MUCH less important. I can make the different parts of my page as different DIV panels which can automatically refresh themselves and hook into in-page eventing to send updates, etc. The server-side of the calls needed to update the page is, IMO, better suited to be handled by an action-based framework than a component-based one.
    I have a different feeling regarding this. IMO, having components greatly helps solve some situations like, for example, having a combobox selection which replaces another combobox's values dinamically using AJAX. Having components makes it clear where and how events and changes happen through the page. How's an action based framework going to deal with this? IMO it would require a complex client-side framework for mapping responses to actual page changes. Having a server-side component-oriented framework may simplify it a lot, since both sides are "talking in the same language", no impedance mismatching.

    Take a look at Dojo's dojo.event.Topic... Ok, so I wrote it and I'm biased, but I think decoupled publish-subscribe messaging inside a web page is one of THE killer things about Dojo as an AJAX framework. You can have your tree widget publish messages when a node is selected and have 3 other parts of your page listen for those messages and update themselves appropriately. Remember, at this point we're talking about client-side UI components and, with the Dojo work we've been doing, I think we have at least as good a story for client-side UI components as anyone. Our new AJAX theme allows you to define sections of your page in a DIV tag and provide as one of the tag parameters the topic to listen to for messages. When a message comes on that topic, that part of the page will refresh itself from the server. How much easier could that be?

    The real question is whether you need to re-constitute a component tree for each call to the server in order to populate data on your AJAX page. I think "no", since it fits a RESTful request / response much better and you know you're within the scope of ONE of your on-page components, rather than refreshing the whole page and needing to figure out which of the components needs updating.
  59. action based x component based[ Go to top ]

    Take a look at Dojo's dojo.event.Topic... Ok, so I wrote it and I'm biased, but I think decoupled publish-subscribe messaging inside a web page is one of THE killer things about Dojo as an AJAX framework. You can have your tree widget publish messages when a node is selected and have 3 other parts of your page listen for those messages and update themselves appropriately. Remember, at this point we're talking about client-side UI components and, with the Dojo work we've been doing, I think we have at least as good a story for client-side UI components as anyone. Our new AJAX theme allows you to define sections of your page in a DIV tag and provide as one of the tag parameters the topic to listen to for messages. When a message comes on that topic, that part of the page will refresh itself from the server. How much easier could that be? The real question is whether you need to re-constitute a component tree for each call to the server in order to populate data on your AJAX page. I think "no", since it fits a RESTful request / response much better and you know you're within the scope of ONE of your on-page components, rather than refreshing the whole page and needing to figure out which of the components needs updating.

    I don't know if long term you want to consider client side as your only source of refresh events. A usecase could be a separate component fires some action on the server (RESTful), but in that response, the Java code decides it wants to refresh some other parts of the page. I realize Dojo helps solve this case, but you are assuming that all possible action/refresh combinations will be coordinated on the initial render.
  60. action based x component based[ Go to top ]

    Take a look at Dojo's dojo.event.Topic... Ok, so I wrote it and I'm biased, but I think decoupled publish-subscribe messaging inside a web page is one of THE killer things about Dojo as an AJAX framework. You can have your tree widget publish messages when a node is selected and have 3 other parts of your page listen for those messages and update themselves appropriately. Remember, at this point we're talking about client-side UI components and, with the Dojo work we've been doing, I think we have at least as good a story for client-side UI components as anyone. Our new AJAX theme allows you to define sections of your page in a DIV tag and provide as one of the tag parameters the topic to listen to for messages. When a message comes on that topic, that part of the page will refresh itself from the server. How much easier could that be? The real question is whether you need to re-constitute a component tree for each call to the server in order to populate data on your AJAX page. I think "no", since it fits a RESTful request / response much better and you know you're within the scope of ONE of your on-page components, rather than refreshing the whole page and needing to figure out which of the components needs updating.
    I don't know if long term you want to consider client side as your only source of refresh events. A usecase could be a separate component fires some action on the server (RESTful), but in that response, the Java code decides it wants to refresh some other parts of the page. I realize Dojo helps solve this case, but you are assuming that all possible action/refresh combinations will be coordinated on the initial render.

    I could certainly add / remove subscriptions from topics as the need arises via JS. The point of using the ww:action tag along with our AJAX refreshing is that you can have portions of your page rendered by actions called by the ww:action tag in the page, then, when that part of the page refreshes, it will call that SAME action URL on the server to get the content. That way if you refresh the whole page you'll still get the same thing.
  61. This has to be a good thing![ Go to top ]

    Ideally you keep all of the state in your domain model. For cases where you would normally as you say, "throw everything onto the session," I created an interceptor and custom result to support what Gavin calls "conversation state" in Seam.
    I think it is good idea to manage this state using "state mashine" or workflow engine. Http Session is shared by multiple threads and it comlpicates scalable state management.
  62. This has to be a good thing![ Go to top ]

    I'd have to disagree here. I've used Webwork since way back (I was very happy to have dumped Struts for webwork over 3 years ago and now I seem brilliant!). I've also got 2 tapestry applications in production for a client. While webwork supports something called "components", it's completely different from how Tapestry handles components. Tapestry handles components much more like Swing does. Webwork's components are really more like JSP tags done right rather than fully reusable, distributable components like Tapestry and Swing components.
  63. This has to be a good thing![ Go to top ]

    I'd have to disagree here. I've used Webwork since way back (I was very happy to have dumped Struts for webwork over 3 years ago and now I seem brilliant!). I've also got 2 tapestry applications in production for a client. While webwork supports something called "components", it's completely different from how Tapestry handles components. Tapestry handles components much more like Swing does. Webwork's components are really more like JSP tags done right rather than fully reusable, distributable components like Tapestry and Swing components.

    Remeber Swing has never broken much ground?
  64. Swing has not broken much ground?![ Go to top ]

    Remeber Swing has never broken much ground?
    Hmm... You lost me there -- the contents of your post state clearly that you live in an alternate reality, but the fact that I can read it tells me that you somehow managed to post it in this reality as well. ;-)

    Now, honestly, either you are quite new to Java development and thus to date have come into contact with web applications only as you missed the golden age of two-tier client-server apps in the late nineties, or you have (willingly or not) suppressed any information like the Swing Sightings from your perception.

    The Swing framework actually has broken quite a lot of ground, alas Java's effort on the client side was hampered (among other things) by the fact that for every application installation you have to maintain a JRE installation as well, while Sun's license policies forbid bundling the JRE with your own application. However, Java's slow adaption on the client side is not due to the fact that the component architecture of the Swing framework was insufficient.

    'Nuff said,
    Lars :-)

    --
    The Mind Mill
  65. Swing has not broken much ground?![ Go to top ]

    Now, honestly, either you are quite new to Java development and thus to date have come into contact with web applications only as you missed the golden age of two-tier client-server apps in the late nineties,


    I was actually there amazed by the "simplicity" of Swing while in the dark tunnel of VisualAge C++, hoping it (Swing)would be the only GUI development framework I would ever need to learn. The reality is, it broke little ground against MFC, not to mention those much simpler GUI tools, the likes of VB/PowerBuilder/OracleForms etc etc. In fact, at my next job after VA C++ it turned out to be VB(client)/Visual J++ COM (server) using a Sybase JDBC. No, it was 3-tier. (And it was boasted to be a major Java/COM integration success story).

    Were you really there or just dream being there?
  66. Swing has not broken much ground?![ Go to top ]

    The reality is, it broke little ground against MFC,

    The key phrase here is 'broke' - past tense. Things are very different now. The NetBeans 5 GUI designer is an awesome tool.
  67. Re: Swing has not broken much ground?![ Go to top ]

    And still it looks, like Sun is not using it behind its Java Studio Creator Or has it just been hidden well?

    The Professional and Enterprise version use it, but for the Entry edition (though free) it is not mentioned.
  68. Re: Swing has not broken much ground?![ Go to top ]

    And still it looks, like Sun is not using it behind its Java Studio Creator Or has it just been hidden well?The Professional and Enterprise version use it, but for the Entry edition (though free) it is not mentioned.

    I'm not sure what you mean. Java Studio Creator 2 is based on NetBeans 4.1.
  69. Re: Swing has not broken much ground?![ Go to top ]

    Actually Java Studio Creator is based on Netbeans 4.1, which itself is 100% pure Swing, if you have not noticed that, that is a good indicator, that Swing was fast enough ;-)

    anyway, I am not sure if the ui swing builder made it into JSC because the target of the JSC is entirely J2EE.
  70. This has to be a good thing![ Go to top ]

    While webwork supports something called "components", it's completely different from how Tapestry handles components. Tapestry handles components much more like Swing does. Webwork's components are really more like JSP tags done right rather than fully reusable, distributable components like Tapestry and Swing components.

    I wasn't referring to WebWork's UI components. I was talking about the general idea of reusing code. If you're not getting as much reuse out of WebWork as you do Tapestry, then there's a good chance that you're treating WebWork like Struts which is a lot like treating Java like C.
  71. This has to be a good thing![ Go to top ]

    This is definetly a good news about choice in the Java world. IT managers no longer *have* to choose committee designed JSF just because Struts is dated and WebWork does not have much community, especially when request driven MVC2 is more natural in many Web applications than event driven / component based JSF or Tapstry (or even ASPNET on that matter).
    It's a dicotomy market. You can eventually reach the point with application functionality where managing state in a RESTful manner (request) just won't cut it. Then frameworks like JSF or Tapestry can do a lot to 'just make things work' for complex requirements. I'm not saying where the fault lies in the hypothetical case, but to state that 'request driven' is much more natural-- more natural for what? The standard Servlet Spec?

    +1

    Good response.

    BTW Facelets ROCKS! Thanks!
    We are (most likely) going to use it on our current project. We did some prototypes and just loved the concepts and implmentation.

    Great stuff. Facelets seems to bring out more of the full potential of JSF.
  72. This has to be a good thing![ Go to top ]

    This is definetly a good news about choice in the Java world. IT managers no longer *have* to choose committee designed JSF just because Struts is dated and WebWork does not have much community, especially when request driven MVC2 is more natural in many Web applications than event driven / component based JSF or Tapstry (or even ASPNET on that matter).
    It's a dicotomy market. You can eventually reach the point with application functionality where managing state in a RESTful manner (request) just won't cut it. Then frameworks like JSF or Tapestry can do a lot to 'just make things work' for complex requirements. I'm not saying where the fault lies in the hypothetical case, but to state that 'request driven' is much more natural-- more natural for what? The standard Servlet Spec?

    I don't agree. Where is this line where action based frameworks "just won't cut it"? I, and the thousands of other developers who've developed using Struts, WebWork, and the other action-based frameworks don't seem to have run into it yet.

    On the other hand, I can think of lots of cases where component based web frameworks are ridiculously over-engineered for the problem at hand. I'd guess that it's about 85-90% of pages in every application.
  73. STi[ Go to top ]

    a very unfortunate acronym
  74. STi[ Go to top ]

    a very unfortunate acronym
    WRC proves you wrong.
  75. What a (great) surprise![ Go to top ]

    In my opinion this is a great idea - for both frameworks, and for the J2EE community.

    I hope that OSS community will be mature enough to use this, and not be snobish about the name Struts.

    I am really hoping to see something architecturally sound come out of this "marriage".
  76. Great!![ Go to top ]

    This is a great move,i think.It will be a synergy between good technology and community.

    I think/hope Webwork users will benifit from already proven tooling efforts from Eclipse/MyEclipse , DreamWeaver etc.?!?

    XWork is a command-pattern framework with support for inversion of controle/dependancy injection,interception,transparent type conversion,validation,expression language etc.,Webwork,MessageWork,SMTPWork,MyChannelSpecifiC*Work etc. on top of it can be built. Which is basically addition of channel-agnostic feature on top of all the xWork's features.Imagine as a developer i have to write only Action,irrespective of target usage!Its great isnt it? I think/hope these beneifits will be preserved ?!?

    How is it related to Struts Shale? Is it also going to be merged with these union?
  77. Great!![ Go to top ]

    How is it related to Struts Shale? Is it also going to be merged with these union?

    Shale will continue to be developed, as part of the Struts community, in parallel with the Struts Action Framework. There will certainly be opportunities to share technologies, Shale will continue to focus on leveraging existing JSF functionality as its core architecture.

    Craig
  78. Shale Snail[ Go to top ]

    Shale is an unfortunate, nearly pathetic, attempt by a failed architecture to hitch itself to a worthwhile community. "Parallel" shamarallel, my foot!
  79. nice move[ Go to top ]

    I think its a smart move to unify both frameworks. I still cant see how the migration of old struts apps will be achieved though. Seems like a big deal to deliver an upgrade path without major pains involved.

    At all those "Struts is dead commenters" i can only say, go out and work for real companies, then you will see how dead struts is.

    Regarding JSF vs ActionFrameworks discussion: I think jacob explained it quite well, JSF can be a win for complex GUIs like Tree+Table+Form screens with a lot of interaction and stuff, nothing which couldnt be handled well on top of struts/webwork too, but you definitely need to apply one more framework or code it yourself. But on the other hand, for classic web applications (most of them simply dont have that complex GUIs), JSF is a pain because its overkill. Alone the fact that modifying the output takes A LOT more time than doing the same with a taglib approach.

    JSF is there and it will stay. This is ok because Java is known of having different solutions for the same problem. But people should stop entering every thread and praise JSF as if it could cure cancer. Its just another framework with some more abstraction on top of the Servlet API, which is sometimes evil for people doing web app development for some years. Abstraction comes at a price as we all know.

    Marc Logemann
    http://www.logemann.org
  80. nice move[ Go to top ]

    JSF is a pain because its overkill. Alone the fact that modifying the output takes A LOT more time than doing the same with a taglib approach.

    Sorry to pick up on this - I may simply be showing my ignorance - but I don't understand what you mean here. I use JSF because I find it pretty simple even on the smallest web projects. If anything, I think JSF alone is underpowered for complex sites, which is why I am interested in the potential of projects such as Shale.
    But people should stop entering every thread and praise JSF as if it could cure cancer

    In my view the exact opposite is happening. In threads relating to web frameworks there is a frequent tendency to dismiss JSF, and I don't think anyone defending it has been saying JSF is perfect.
  81. Complex uis not needed in webapps[ Go to top ]

    Actually, first of all, all the webapps I had to deal with in the recent past, had more than a handful of complex interactions and uis.
    The last project I had to do in Struts was a perfect candidate to be moved over to JSF (or being refactored into smaller entities). Struts simply did not beat it anymore for that project (backend project very complex forms, highly interactive)

    It is true, JSF does more heavy lifting than other frameworks (Serialisation, Deserialsiation, IOC handling, phases, phase listeners etc...)
    but is the price too high, for the benefits you get.
    (Serialisation/Deserialisation has been used for scoping systems, phase listeners are extremely flexible for anything, IOC can bet combined with other IOC systems easily, phases give a good granularity in your backend processing, events simply give you the power of a rich client ui in a webapp etc...)

    We talk about web applications there where 99.9% of performance problems usually come from the database or lousy caching. The impact of the view technology usually is neglectable, even more if you can save time in coding.

    Perfect example Ruby/Rails. Face it Ruby is not the fastest language there is, but they also see it like I do, less coding, is more important than having the fastest UI layer there is.

    If you want that on the java side, omit MVC, and go for a pure servlet based approach, but adding a cluster often is cheaper than having the additional coding effort, if things become tight.

    But beating on the UI rendering speed as choice criterion for a web framework in my opinion is totally wrong and you basically try to solve a problem which does not really exist. You should choose a webframework on a handful of criteria:

    * can I get the job done fast
    * is the thing maintainable
    * does it scale if things become tight
    * how much time does it save me in my current szenario
    * are there others who can take over the code
    * how good is the tool support

    But none of those goes into the rendering speed which is a non issue nowadays anyway.
  82. regarding the coding efforts[ Go to top ]

    that complex GUIs), JSF is a pain because its overkill. Alone >the fact that modifying the output takes A LOT more time than >doing the same with a taglib approach.JSF is there and it will

    Actually, the effort is somewhere between struts and a pure jsp approach, it definitely is much less coding than going for a plain struts approach (which some people still prefer, probably because they never looked into the frameworks outside of struts) and a pure jsp approach, where anything goes without having to do anything on the backend side.

    In Struts, you usually do following in a simple case:

    write a form,
    write a series of actions
    write an xml validator
    write an xml entry for the form
    add some additional javascripts which are often needed (mostly for multi targets)
    add the navigation code (which is usually twice as much as in jsf)
    write the jsp code

    You do not gain too much additional functionality, you still
    do not have more advanced components out of the box, you do not have anything regarding more advanced scoping, the mvc paradigm is not very clean etc...
    Struts simply shows its age.

    in jsf you are there:
    write a backend bean with all the controller and model logic
    write an xml entry for the backend bean
    write an xml entry for the navigation
    write the jsp

    and most of the times you are set, the validation is handled within the jsp usually automatically
    it is very rare that you have to do some additional stuff

    in Seam it is even easier:
    write a backend bean
    write an xml entry for the navigation
    write the jsp

    The xml entry for the backend bean is not needed, due to EJB3 session beans automatically becoming backend beans, also additionally to that scoping is added automatically which otherwise you have to achieve with for instance the t:saveState tag of myfaces (or shale Dialogs)

    in JSP:
    write the JSP logic in the simplest case and you run into a maintenance nightmare, but it is the quickest way for small things. (things become much more nasty as soon as you move away from a handful of pages)
  83. regarding the coding efforts[ Go to top ]

    >that complex GUIs), JSF is a pain because its overkill. Alone >the fact that modifying the output takes A LOT more time than >doing the same with a taglib approach.JSF is there and it will Actually, the effort is somewhere between struts and a pure jsp approach, it definitely is much less coding than going for a plain struts approach (which some people still prefer, probably because they never looked into the frameworks outside of struts) and a pure jsp approach, where anything goes without having to do anything on the backend side.In Struts, you usually do following in a simple case:write a form,write a series of actionswrite an xml validatorwrite an xml entry for the formadd some additional javascripts which are often needed (mostly for multi targets)add the navigation code (which is usually twice as much as in jsf)write the jsp codeYou do not gain too much additional functionality, you stilldo not have more advanced components out of the box, you do not have anything regarding more advanced scoping, the mvc paradigm is not very clean etc...Struts simply shows its age.in jsf you are there:write a backend bean with all the controller and model logicwrite an xml entry for the backend bean write an xml entry for the navigationwrite the jsp and most of the times you are set, the validation is handled within the jsp usually automaticallyit is very rare that you have to do some additional stuffin Seam it is even easier:write a backend beanwrite an xml entry for the navigationwrite the jspThe xml entry for the backend bean is not needed, due to EJB3 session beans automatically becoming backend beans, also additionally to that scoping is added automatically which otherwise you have to achieve with for instance the t:saveState tag of myfaces (or shale Dialogs)in JSP:write the JSP logic in the simplest case and you run into a maintenance nightmare, but it is the quickest way for small things. (things become much more nasty as soon as you move away from a handful of pages)

    Right, but we're not talking about Struts Classic anymore. This is based on WebWork, which is (IMO) much better in terms of productivity than Struts Classic. From what I've seen of the config files for JSF, I've got to think it's more productive than that, too, but I've never used JSF.
  84. regarding the coding efforts[ Go to top ]

    in Seam it is even easier:
    write a backend bean
    write an xml entry for the navigation
    write the jsp

    If the number of artifacts you have to write is your sole criteria, you should take a look at Stripes ;) In that case you simply:
    write a backend bean
    write the jsp

    And your done! And it handles multiple events, all the configuration etc. Just saying...

    -Tim Fennell
    Stripes: Because web development should just be easier.
  85. regarding the coding efforts[ Go to top ]

    in Seam it is even easier:write a backend beanwrite an xml entry for the navigationwrite the jsp
    If the number of artifacts you have to write is your sole criteria, you should take a look at Stripes ;) In that case you simply:write a backend beanwrite the jspAnd your done! And it handles multiple events, all the configuration etc. Just saying...-Tim FennellStripes: Because web development should just be easier.

    Tim, I would recommend that you get in touch with Ted and the struts leads on working with struts Ti.

    If anything, as I stated in the web alignment group discussions, I hope that you guys are able to separate the view from the controller in such a way that JSF component integration becomes practical. I really adore WW's interceptor stack, but being able to use component/event UIs in the mix (as an option) would lock you guys in at the top with struts ti.
  86. Just wanted to[ Go to top ]

    Give an example to clear things up where jsf is positioned.
    The number of artefacts definitely is an important criterion.
    Due to the fact, that the more artefacts you have to handle the more problems you have while coding, because you constantly have to juggle between numerous artefacts and usually 2-3 different languages simultaneously.

    JSF is not perfect in this regard, but much better than Struts classic, and it probably will become better as soon as most of the stuff which is currently hosted in the xml configs and tlds is moved into annotations.
    But still it then is not perfect.

    And yes there are frameworks which are much tighter, with rails probably being the most perfect example up to date.

    But my point was, that someone wrote, that JSF probably has its place for highly interactive apps, while most webapps do not require that. I dont see that really, because the way I see it is, that it is a good solid standardized foundation which has cleaned up the many problems struts classic has had, and also delivered a rich client ui like programming model on top of that.

    It always will be 1-2 points behind, the current framework if choice which drives technologies, but standards usually are. But it is not a bad standard, like EJB1 and 2 were, it actually is quite good.

    With saying that, I wish the Struts TI people good luck in their efforts, what is really needed is an excellent successor to Struts classic which still has the name Struts on it (Shale also can do it one day). The main problem I had to deal with in the past with many struts devs was, that they were uneager to touch anything which did not have the name tag Struts, which is quite a pity, because those people lose around 5 years of advancement which Struts classic has not yet fully covered.

    JSF itself will find its position, the standard is good, the momentum is there, but there needs to be a Struts named alternative, which hopefully one day will drive technology forward, a nieche which jsf not fully can cover, due to the standardization cycle.
  87. Just wanted to[ Go to top ]

    Struts named alternative, which hopefully one day will drive technology forward, a nieche which jsf not fully can cover, due to the standardization cycle.

    I agree that there needs to be alternatives, but JSF innovation is not limited by the standards cycle. There is a lot of interesting work going on with projects based on JSF framework and the renderkit principle. For example, there are implementations that render to SVG, Flash, WML and even text-mode terminals. There are increasing numbers of components from various sources. The idea that because JSF (or any other JSR specification) can't be the basis for on-going innovation is mistaken.
  88. Just wanted to[ Go to top ]

    JSF itself will find its position, the standard is good, the momentum is there, but there needs to be a Struts named alternative, which hopefully one day will drive technology forward, a nieche which jsf not fully can cover, due to the standardization cycle.

    If JSF is that good (and Shale does *have* the Struts "name tag"!), Shale should have already dominated the Java Web landscape and left no room for the merge of Struts and WW. The purpose of Shale was really to lure those "uneager devs" into JSF. Correct me if I am wrong.
  89. Just wanted to[ Go to top ]

    If JSF is that good (and Shale does *have* the Struts "name tag"!), Shale should have already dominated the Java Web landscape and left no room for the merge of Struts and WW. The purpose of Shale was really to lure those "uneager devs" into JSF. Correct me if I am wrong.

    How can Shale have dominated the web landscape when there has not yet been a stable release?

    If you read the Shale website the idea is

    "a proposal for a modern web application framework, fundamentaly based on JavaServer Faces, and focused on improving ease of use for developers adopting JSF as a foundational technology in their own development environments."

    So, it seems targetted at developers who are already interested in using JSF. Personally, I find the idea that "uneager devs" could be lured into anything rather amusing! My impression is that Shale is designed to integrate with other frameworks rather than to always compete with them:

    "In addition, integration links for other frameworks and framework components are provided, to ease development when combinations of technologies are required"

    So, on that basis, I would suggest you are probably wrong.
  90. Just wanted to[ Go to top ]

    How can Shale have dominated the web landscape when there has not yet been a stable release?

    I have the impression the Shale project has been there for a long time. It is quite odd there has not yet been a stable release. Lack of resource or vendor support? Or its just not doable to mix and mess Struts and JSF?
  91. Just wanted to[ Go to top ]

    Or its just not doable to mix and mess Struts and JSF?

    One is request driven and the other is event driven.
  92. Just wanted to[ Go to top ]

    Or its just not doable to mix and mess Struts and JSF?
    One is request driven and the other is event driven.

    You can certainly mix struts and JSF:

    http://blogs.sun.com/roller/page/craigmcc/20040927#struts_or_jsf_struts_and

    "If your requirements include unique features supported only by Struts (such as Tiles or client side validation support), feel free to use the two frameworks together."
  93. Just wanted to[ Go to top ]

    "If your requirements include unique features supported only by Struts (such as Tiles or client side validation support), feel free to use the two frameworks together."

    Yes it is possible for a site (with apps written in differnt times) to use more than one frameworks/approaches or even more than one platforms (J2EE and Microsoft).

    But certianly no good to mess up two incompatible approaches in a single framework.
  94. Just wanted to[ Go to top ]

    How can Shale have dominated the web landscape when there has not yet been a stable release?
    I have the impression the Shale project has been there for a long time. It is quite odd there has not yet been a stable release. Lack of resource or vendor support? Or its just not doable to mix and mess Struts and JSF?

    Not really that long, I can remember that it has been there for a year now, given the timeframe and that shale sort of is an ongoing project and also that there is currently a severe lack of documentation it has not found its nieche yet.
    While Shale is good, it sort of is a mix of existing ideas blended into a jsf extensions. Many of those ideas exist in different forms in different frameworks.

    Shale Clay for instance, while Clay does a lot, it is probably covered better in facelets, which currently is taking off in the JSF realm.
    Shale Dialog, this one also is covered by Seam in a different manner and also by the MyFaces x:saveState components.

    But besides those two redundancy examples, Shale can add a lot to ease development and fills many small gaps in a good way. (one big problem for instance is that there is no decent standardized way to notify a data model to aquire and release its resources, shale adds that by providing an additional mechanism which is hooked into the view handler, the same also would be programmable easily, but Shale seems to add that out of the box)

    So I see a future for shale in the JSF realm, but will it be the dominant extension framework, my guess is no, but it probably will lure some old Struts devs into the JSF realm and also will be used often.
  95. Just wanted to[ Go to top ]

    And is Shale bounded by the standardization cycle??
  96. nice move[ Go to top ]

    But on the other hand, for classic web applications (most of them simply dont have that complex GUIs), JSF is a pain because its overkill. Alone the fact that modifying the output takes A LOT more time than doing the same with a taglib approach.JSF is there and it will stay. This is ok because Java is known of having different solutions for the same problem. But people should stop entering every thread and praise JSF as if it could cure cancer. Its just another framework with some more abstraction on top of the Servlet API, which is sometimes evil for people doing web app development for some years. Abstraction comes at a price as we all know.Marc Logemannhttp://www.logemann.org

    ASP.NET is appealing to the VB6 crowd.

    JSF is also appealing to the Swing crowd, but unfortunately not the majority of Java Web developers.
  97. JSF doesn't address the AJAX pattern of having all user flow downloaded as required

    The spec certainly does prevent JSF components from being AJAX-capable.
  98. > JSF doesn't address the AJAX pattern of having all user flow downloaded as requiredThe spec certainly does prevent JSF components from being AJAX-capable.

    Agreed, and that was far from what was intended. However, JSF AJAX capability seems to be limited to the JSF components, rather than block-level functionality. There are some useful AJAX patterns that JSF simply doesn't even begin to address yet.
  99. Shale propose some Ajax-related functionalities. It's not stable enough in the current alpha release (wich was announced this saturday on the mailing list, I am surprised to not see any mention on it on tss) but I guess it will be in the official 1.0 release.
  100. JSF and AJAX play well together[ Go to top ]

    Hi Joe,

    While the spec doesn't explicitly define how to do "page as an application" style apps, there is some interesting work going on around this regarding the Avatar concept that Jacob and I and others have been working on.

    It's still an idea right now, but it has promise. Maybe we can put it into shale.

    http://weblogs.java.net/blog/jhook/archive/2005/09/jsf_avatar_vs_m_1.html

    Ed (JSF co-spec lead)
  101. JSF and AJAX play well together[ Go to top ]

    Galen Dunkelberger has been doing some excellent work with prototyping JSF Avatar funtionality and including Rico and Prototype JS libraries. I'm pretty amazed by what he's been able to do so far with it. As for Facelets' roadmap, it's my goal to button up a couple more things for its 1.0 version, and then approach 1.1 with complete Avatar integration.

    -- Jacob
  102. All the Struts[ Go to top ]

    Here is all the news on Struts this weekend:

    http://wiki.apache.org/struts/SnapshotGuide11

    Like about new Struts 1.3, etc.

    .V
  103. Struts has a larger mind- and marketshare, but Spring has more momentum, especially in the open source community. WW has already adopted the Spring IoC container, and it would make more sense for the WW team to enhance the Controller-as-Model branch of Spring MVC (see ThrowawayController) and to bring their expertise and experience to the MVC part of Spring in general.
  104. Hallelujah
    Hallelujah
    Hallelujah
    Hallelujah
  105. What's the point ?[ Go to top ]

    Pardon my ignorance but what benefit will come of this merger ?

    I know Struts very well after working with it on numerous projects but never tried webwork and heard very little about it.
    I read that it is a Java web-application development framework, very much like Struts is.
    It doesn't to me look like it's going to complement Struts but both will overlap on functionalities ?
    For those who have worked on both, any thoughts on how one is better than the other or how this merger will improve Struts ?

    Thanks ;)
    David
  106. Ti? Would that be Titanium or some sort of European sports sedan reference?
  107. Ti == Titanium[ Go to top ]

    Struts Ti as in Struts Titanium. I went with Ti since I thought Titanium was too long and had too many syllables. Folks usually refer to a project by a shorted name, so why not start with one? :)

    Don (Struts committer)
  108. This is great for Struts and WebWork, and it's even better for the users. This means no more arguing to get WebWork on approved standards lists.
  109. This is great for Struts and WebWork, and it's even better for the users. This means no more arguing to get WebWork on approved standards lists.

    +1

    I wanted to use WebWork at a Struts shop (a few years back). It fit the problem domain better, but I got a big "no way"! (Actually they said mention it again and you have to leave.) Now WebWork and Struts have merged. I think it is great. It is good for Struts and good for corporate WebWork users (who folks who would like to be users).
  110. Re: This is great for Struts and WebWork[ Go to top ]

    This is great for Struts and WebWork, and it's even better for the users. This means no more arguing to get WebWork on approved standards lists.

    I agree with that. Of course there should always be a space for choice and innovation, but developing dozens of different implementations of (from a high level perspective) mostly the same patterns and ideas, is not very productive. And as you see from some of the comments before, WW has not been as well-documented and with every new feature added something like that becomes more critical.
    I have worked with WW only one or two times in projects so far. Liked some of its features and how parts fit together, but I also had to find a lot of things out myself due to lacking documentation (and support from the web agency who used it without any clue ;-)

    Especially some Java Developers and Architects might like it as over time, their profiles and CVs can be consolidated, too.

    I know quite a lot of agencies and clients, who really do full text searches for individual terms like MVC2, Value Object Pattern, or Struts ;-)
    Also those should profit from having to look for only one common term instead of 2.

    Unless they have to differentiate again between Struts "Classic", Struts 1.2, 1.3, Ti, Beehive, Shale, or whatever other mutation...?

    That is also why Apache has collected far more frameworks and technologies in that area themselves, than any WebWork, Codehaus, or other project might ever compete with.

    Take just Struts, Shale, MyFaces, Beehive, Tapestry and now Struts Ti. Some are based on Struts, some on JSF, and others on both, while e.g. Tapestry could be seen a bit like an ancestor to JSF. It also is a lot more component-driven, than Struts.

    So I guess more consolidation and merging is likely to happen in the future. Not resulting in a one-fits all monopoly, but getting some of all the different "smoke signs" (from Apache ;-) removed and the sky a bit clearer.
  111. Re: This is great for Struts and WebWork[ Go to top ]

    Take just Struts, Shale, MyFaces, Beehive, Tapestry and now Struts Ti. Some are based on Struts, some on JSF, and others on both

    I am probably being pedantic here, but just to clarify - MyFaces is not based on JSF - it is JSF, in the same way as the Sun JSF RI and Oracle's ADF Faces are. In principle you could use any of these as the JSF implementation to which you could add Shale functionality.

    I agree with your point about consolidation; just that packages such as MyFaces and Shale most likely won't merge as they serve different purposes.
  112. Some are based on Struts, some on JSF, and others on both, while e.g. Tapestry could be seen a bit like an ancestor to JSF. It also is a lot more component-driven, than Struts.So I guess more consolidation and merging is likely to happen in the future.

    Those based on Struts will consolidate, and those based on JSF will consolidate too, but those based on both will *die*.
  113. Some are based on Struts, some on JSF, and others on both, while e.g. Tapestry could be seen a bit like an ancestor to JSF. It also is a lot more component-driven, than Struts.So I guess more consolidation and merging is likely to happen in the future.
    Those based on Struts will consolidate, and those based on JSF will consolidate too, but those based on both will *die*.

    Just like your nonsensical bantering will kill this thread.
  114. Some are based on Struts, some on JSF, and others on both, while e.g. Tapestry could be seen a bit like an ancestor to JSF. It also is a lot more component-driven, than Struts.So I guess more consolidation and merging is likely to happen in the future.
    Those based on Struts will consolidate, and those based on JSF will consolidate too, but those based on both will *die*.
    Just like your nonsensical bantering will kill this thread.

    Soon.
  115. what all changes are we expecting if we have to upgrade to 1.3 or struts Ti. No one has said anything on the upgrade/migration issues ? Is everyone working in a small dotcom ?
  116. what all changes are we expecting if we have to upgrade to 1.3 or struts Ti. No one has said anything on the upgrade/migration issues ? Is everyone working in a small dotcom ?

    I assure you smooth migration is a very high priority. It will definitely be a lot easier (and smarter) than migrating to JSF.
  117. what all changes are we expecting if we have to upgrade to 1.3 or struts Ti. No one has said anything on the upgrade/migration issues ? Is everyone working in a small dotcom ?
    I assure you smooth migration is a very high priority. It will definitely be a lot easier (and smarter) than migrating to JSF.

    Thanks for a quick reply and understanding of problems in big companies.
      We had already started talking of moving to Spring after a bad experience with struts 1.1 to struts 1.2 migration - and also finding it too difficult to manage big , dynamic applications with struts.
  118. Wow, this is incredible but it sort of does make sense. Remember that Rickard Oberg initially created WebWork to fix some of the design-deficiencies with Struts. WebWork took of on a tangent but it's pretty much always been not much more than "Struts done right".

    Java has suffered for a long time from the likes of EJB and Struts, it's certainly time to set things straight.
  119. -1

    I think we should let Struts die from natural causes, I think its done enough already.

    regards Malcolm Edgar
  120. Is JSF Intelligent Design?

    ;)
  121. gosh..[ Go to top ]

    does this mean I won't have to pass around servlet contexts in my APIs in the future? thank god...
  122. Terrible News[ Go to top ]

    With struts being so near death, and webwork being so excellent, this seems like a real shame.
  123. Terrible News[ Go to top ]

    With struts being so near death, and webwork being so excellent, this seems like a real shame.

    I don't understand this comment? We're moving the WebWork codebase over to be the basis of Struts Ti (and possibly the Struts Action Framework 2.0). Will the same code be less excellent with a different name?
  124. Re: Terrible news[ Go to top ]

    Surely one of the reasonings behind WW in the first place was that Struts was so terribly difficult to write (what with all the various different classes that were needed), and test (what with all the Http* classes you needed to mock). WW struck me as the breath of fresh air to clear away all the fluff that was struts.

    WW integrates nicely with TDD and "simplest possible approach", struts certainly didn't (I haven't checked back recently)

    Basically: I dont understand how this will improve WW, which I saw as a great alternative to Struts, which I didn't like.
  125. Re: Terrible news[ Go to top ]

    Basically: I dont understand how this will improve WW, which I saw as a great alternative to Struts, which I didn't like.
    When I first created WW it was an attempt at taking what was good with Struts (et al) and making something different which could possibly be better. Possibly, because at the time I had no idea what the end result would be. In this case diversity was good, because it allowed "us" to try different approaches to the same problem.

    Now we know what different approaches are available, their different consequences, and their respective values and faults. With this common knowledge, which is new, it becomes possible and sensible to consolidate it into something which is less diverse and which takes the proven and working techniques from all different aspects, while at the same time being responsible and not ditching everything which is "old".

    As has already been pointed out Struts Ti is already based on WW code, so it's not like WW is being thrown away. People who are attached to names are barking up the wrong tree, IMO. Heck, I wrote the damn thing to begin with, so if anyone should be upset about "WW going away" it would be me. And I'm not.

    But to me this represents the best way further the web app space, in the same way that the AOP space has been consolidated with first AspectJ and AspectWerkz merging, and now Spring becoming more aligned with it due to natural influences from the general direction of Interface21.

    All of this is just basic natural principles, but in a technological setting. Breathe out, breathe in.
  126. Re: Terrible news[ Go to top ]

    <quote>
    But to me this represents the best way further the web app space, in the same way that the AOP space has been consolidated with first AspectJ and AspectWerkz merging, and now Spring becoming more aligned with it due to natural influences from the general direction of Interface21.

    All of this is just basic natural principles, but in a technological setting. Breathe out, breathe in.
    </quote>

    Well Said.
  127. Re: Terrible news[ Go to top ]

    As has already been pointed out Struts Ti is already based on WW code, so it's not like WW is being thrown away. .... But to me this represents the best way further the web app space.

    Will the Struts compatibility add complexity and bulk to the core WW codebase? Will it make WW harder to learn?
    All of this is just basic natural principles, but in a technological setting. Breathe out, breathe in.

    I just hope that projects won't start nosediving into 10,000 LOC struts-config.xml files again...
  128. Terrible News[ Go to top ]

    With struts being so near death, and webwork being so excellent, this seems like a real shame.

    Struts is nowhere near death - have you checked how much it is in demand in the job market? This merger should help to ensure that struts continues to be popular for a long time.
  129. This announcement shows the people managing the Struts and Webwork projects are not just technical leaders, but leaders in a bigger sense. Struts 2.0+ will be better and have a larger market share with this announcement than if the two projects stayed separate.
  130. WebWork is a great technology, and Struts is a great community.
    Very courages of the struts guys that they can look at it like that. I think there is almost no escape from struts for a webdeveloper trying to mak e a living, at least every now and then for maintenance. It is a good thing that things are improving and not abandoned. I am currently not working with struts so i am able not to rant about it;-)