Discussions

News: Struts 2 (AKA Webwork 2) goes final

  1. Struts 2 (AKA Webwork 2) goes final (75 messages)

    Struts 2.0.6 has become Generally Available (GA), meaning that it's been labeled "ready for prime time." Struts 2 is the result of the migration of WebWork 2 to Apache under the Struts umbrella, and is an action-based framework. According to the Struts 2.x home page, "This new version of Struts is simpler to use and closer to how Struts was always meant to be." That's debatable, but it's certainly good news to see the framework released in a production-ready form. So what do you think of the new release? Have you been waiting for it to consider migrating? Are you considering migrating to the new release?

    Threaded Messages (75)

  2. fantastical...[ Go to top ]

    This is some fantastic work by a great group of people... it's destined for a bright future. Now that I'm actually using it on a project, I may need to get my committer kudos back :P Cheers, Arron.
  3. why struts 2 ?[ Go to top ]

    Just my opinion hoping to avoid flames ... I have to say that i do not really see any point in using struts 2 (may be that simply I do not see it even it exists ...). I have been using struts 1 for years, getting used to all its defects but nothing better was available so, simply struts ruled. Spring then overcome many of the problems of the struts mvc architecture (and of course covering in a wonderful way the complete application architecture). Spring controllers are much better the struts actions, aop interceptors are in spring since a lot of time, ... Why use struts any more ? Even if spring web is the only bad part of the spring framework, (i think that the taglibs were simply both poor and complicated), it was still much better than struts. Now, spring 2 has a quite simple to use taglib, even if not yet perfect and complete, but i still do not see any advantage in using struts 2 against spring 2. Personally i still use struts 1 tiles with spring but i do not miss anything else from struts.
  4. Re: why struts 2 ?[ Go to top ]

    If you are happy with Spring MVC, great, you have no reason to switch. I would like to point out that Spring support, particularly Spring IoC/DI support, is very important to the project. Most every Struts 2 user I've talked to is using the Spring Plugin, and we ship it with Struts 2 so it is readily available. Even most of our example applications use it. Speaking of plugins, there are also third-party Spring WebFlow and Spring MVC plugins.
  5. Re: why struts 2 ?[ Go to top ]

    I am not writing my opinion to make anyone disappointed. Let me say, as premise, that struts is a great framework and i have been using it for years. So, first of all, thanks to everybody has been working hard on struts. After that, i also have to say that i tried to use struts 2, just before starting my last project, also using the spring plugin. After the test, however I simply feel that for anyone is a very experienced spring user, the effort of using struts 2 dropping spring mvc is not worth, even if the struts 2 taglib support is much better. I simply hope that my opinion could be helpful to the current spring developers without offending the beautiful work of the struts team. Probably my post title should have been "Re: why struts 2 for spring users ?"
  6. Re: why struts 2 ?[ Go to top ]

    Personally i still use struts 1 tiles with spring but i do not miss anything else from struts.
    Tiles? Baby, you need to dump that zero and get yourself a hero!
  7. zero vs hero[ Go to top ]

    Personally i still use struts 1 tiles with spring but i do not miss anything else from struts.


    Tiles? Baby, you need to dump that zero and get yourself a hero!
    may be ik am "old" but i do not feel comfortable with sitemesh. The idea of "parsing" and "decorating" an http response is not exactly what i like. I prefer to have "full control". I understand your "zero" adjective about tiles, with respect to sitemesh but prefer to avoid "losing the control" :-) MY template + MY xhtml + css is enough for me.
  8. Click Framework[ Go to top ]

    I've given up on heavyweight MVC framework like Struts. It gets complex every releases. Try the Click Framework. Even my 5yr old daughter could set up a webapp in 3mins using click. http://click.sourceforge.net/
  9. Re: Click Framework[ Go to top ]

    I've given up on heavyweight MVC framework like Struts. It gets complex every releases.

    Try the Click Framework. Even my 5yr old daughter could set up a webapp in 3mins using click.
    Sorry, could not check it out, my AdBlock is configured to remove everything that contains "click" from a page. ;-)
  10. Re: Click Framework[ Go to top ]

    Even my 5yr old daughter could set up a webapp in 3mins using click.

    http://click.sourceforge.net/
    Hopefully that is a bit of exaggeration but i can add one more vote for Click. It is very intuitive,you get a lot of components out of the box,Spring integration and it's got a good javascript integration. To see click in action - http://click.sourceforge.net/. Hopefully when Click 1.2 is released we'll get the news on TSS. But anyway this is a struts 2 thread and therefore we should be discussing its value proposition and how migration going is for those who have carried it out or are in the process.
  11. Struts 2 Tutorials[ Go to top ]

    Hi, We have developed many tutorials on Struts 2. You can read at http://www.roseindia.net/struts/struts2/index.shtml Thanks
  12. According to the Struts 2.x home page, "This new version of Struts is simpler to use and closer to how Struts was always meant to be." That's debatable.
    I'm curious why you feel its debatable. Webwork significantly simplifies the work required by a Struts 1 application. I am currenly migrating (from Webwork). So far, I've run into a couple of undocumented, non-backward compatible changes going from XWork to Xwork2.
  13. According to the Struts 2.x home page, "This new version of Struts is simpler to use and closer to how Struts was always meant to be." That's debatable.

    I'm curious why you feel its debatable. Webwork significantly simplifies the work required by a Struts 1 application.

    I am currenly migrating (from Webwork). So far, I've run into a couple of undocumented, non-backward compatible changes going from XWork to Xwork2.
    It's not a question of Struts 2 being simpler than Struts 1 - in my opinion, it is. However, it's arguable whether Struts 2 is actually "closer to how Struts was always meant to be."
  14. However, it's arguable whether Struts 2 is actually "closer to how Struts was always meant to be."
    OK, but it seems pretty clear to me. Rickard did a much cleaner implementation of Struts, while keeping the basic concepts intact, and Ted has acknowledged as much. So it seems pretty straightforward, unless you believe that Struts was "always meant to be" needlessly difficult to customize and extend. :)
  15. Please Calrify[ Go to top ]

    Can someone help clarify the answer to this question? I have been using WebWork - version 2.2.4 for sometime now. (available here: http://www.opensymphony.com/webwork/) - I love it!!! It's one of the best MVC frameworks I've used... Now is that WebWork-2? And the new stuff - Struts-2 is a combination of WebWork-2 and Struts? Should I now be using Struts-2 (Struts+WebWork) for new projects or should I continue to use WebWork 2.2.4? -- Confused...
  16. sorry - meant to say "Clarify" up above...[ Go to top ]

    sorry - meant to say "Clarify" up above...
  17. Re: Please Calrify[ Go to top ]

    The Struts website has a good FAQ that should answer most of your questions. My OnJava "My History of Struts 2" post should cover the rest. As for the XWork -> XWork changes, we try to document them in the Migration Guide, but if we are missing any, please let us know on dev at struts dot apache dot org or file a JIRA ticket. One feature I'm particularly happy about in Struts 2 is its plugin system and the Plugin Registry. Extensions were such a big part of Struts 1 that we formalized them in a plugin system for Struts 2. One of the nice features of WebWork 2 was the builtin support for many third-party libraries, and most of these have been kept, but moved into plugins. This makes the framework easier to extend for developers, but simpler to use for end users. In the registry, we have plugins for technologies like GWT, Spring WebFlow, JSF, JSON, Tiles, and many more, and most of the time, all that is required to use a plugin is to drop it in your project.
  18. Re: Please Clarify[ Go to top ]

    Struts 2 is basically the next version of Webwork. How could you be confused? :) All further development by the Webwork developers will be on the Struts2 project.
  19. Aw who cares?[ Go to top ]

    Thars better stuff out thar! (Seam)
  20. Struts2 vs Seam[ Go to top ]

    Without getting into a flame war .. ;-) Is the answer "depends on your project" or are there some clear advantages that one has over the other? thanks fv
  21. "AKA Webwork 2" isn't accurate[ Go to top ]

    I don't think it is accurate to refer to Struts 2 as "AKA Webwork 2". After the WebWork 2 code was imported a year ago, it has seen a lot of development that, if still the merger didn't take place, would have probably been WebWork 3. Java 5 has had a profound impact on the code, resulting in features like zero configuration and native generics-aware type conversions. We also rewrote the internals of XWork 2 and Struts 2 to support the new plugin system, which allowed us to split out a lot of integration support into new plugins as well as better support third-party plugins. Finally, our tags, particularly Ajax tags, have seen a lot of development with the bump to Dojo 0.4 and the introduction of new tags like the autocomplete. A common complaint in the Open Source world is how each project seems to "reinvent the wheel", but in this case, both the WebWork and Struts teams decided to put aside differences and consolidate efforts. I have nothing but the highest praise for the WebWork 2 team and am thrilled to be working with not only the high quality WebWork 2 code, but also the excellent developers themselves now part of the Struts team.
  22. Nice work guys. I'm sure the whole struts community should be made very happy by this logical progression forward.
  23. Cool stuff! I'm currently using WebWork2 mainly for portlets, and it seems like Struts 2 has some pretty decent portlet support. If all goes well we'll probably port all of our 70(or so) portlets over to Struts2. What I've seen so far is very promising. Kudos to both the WW2 and Struts communities for getting this together! It warms my heart to see that at least one of my babies is doing fine :-)))
  24. Cool stuff! I'm currently using WebWork2 mainly for portlets, and it seems like Struts 2 has some pretty decent portlet support. If all goes well we'll probably port all of our 70(or so) portlets over to Struts2. What I've seen so far is very promising.

    Kudos to both the WW2 and Struts communities for getting this together! It warms my heart to see that at least one of my babies is doing fine :-)))
    Spring 2 also got a new portlet MVC. Don't know how this compares to WW2.
  25. Then let me tell you that here on planet earth web developers are going component based. J
  26. JSF?[ Go to top ]

    Are you talking about JSF? As a complete aside to this thread, but hopefully someone can tell me: are there are any JSF implementations that does not require JavaScript to work, and which does not use tables for layouting? Those two things are requirements for doing accessible websites around here (=ALL gov. websites), and I was wondering if it's possible to do it at all with JSF. The few projects I've heard about have given up on it, and use WW instead, but maybe I just don't know enough about JSF.
  27. Re: JSF?[ Go to top ]

    Are you talking about JSF?

    As a complete aside to this thread, but hopefully someone can tell me: are there are any JSF implementations that does not require JavaScript to work, and which does not use tables for layouting?

    Those two things are requirements for doing accessible websites around here (=ALL gov. websites), and I was wondering if it's possible to do it at all with JSF. The few projects I've heard about have given up on it, and use WW instead, but maybe I just don't know enough about JSF.
    My last job was in a government organization and trust me as you say they are really serious about respecting w3c standard and usability norms but we were using JSF without any problem. First of all, if you don't use jsp but facelets to construct your page, and therefore no stupid panels components, there won't be any table used to create your layout. My css zealot coworker would have killed me otherwise and he would have been right :) Also, the regular jsf components emit straight xhtml and of course a bit of Javascript which can't be avoided even if you don't use JSF. For instance, submitting parameters in a GET manner by clicking on a hyperlink is impossible without javascript from what I know. In my case, our applications were allowed to use standard javascript since otherwise you are too limited in your development. Most of the problem you are mentionning come from 3rd parties libraries which usually aren't so strict about their use of HTML and of Javascript. But in these cases, you can always write a new renderer for the component (contrary to a common myth, renderers aren't use primarily to enable another ui technology like WAP or so). The only problem to me here is that at the moment it's quite cumbersome to write a new renderer (a lot more than it should be) and by default you have to write it using Java. Anyway, it isn't hard to embedd Velicoty to develop your renderers using a template language. This is definitely something they'll have to adress in future JSF versions. In the end, my friend who was in charge of the UI, ran a couple of W3C to assert our pages were respecting the XHTML 1.0 (strict) standard and the usability norm. We got a good mark :)
  28. Re: JSF?[ Go to top ]

    My last job was in a government organization and trust me as you say they are really serious about respecting w3c standard and usability norms but we were using JSF without any problem.
    That's good to hear. I know of one recent gov. project around here which had "must use JSF" and "must be accessible" as requirements, and in the end they ditched JSF because of the table/JavaScript problems.
    Also, the regular jsf components emit straight xhtml and of course a bit of Javascript which can't be avoided even if you don't use JSF.
    Well... that's just it. JavaScript is, at least for us, simply not allowed. We get along just fine, since we're using WW2 without any fancy AJAX things, but my prejudice was that this was much harder to do with JSF, and from your reply it seems like it might be correct.
    In the end, my friend who was in charge of the UI, ran a couple of W3C to assert our pages were respecting the XHTML 1.0 (strict) standard and the usability norm. We got a good mark :)
    Well, XHTML Strict is a good start, but in order to get around the accessibility fascists (and I use that word lovingly) that's not enough. We get quite a lot of customers simply for being, more or less, the best accessible CMS around. And that's sort of sad.
  29. Re: JSF?[ Go to top ]

    For instance, submitting parameters in a GET manner by clicking on a hyperlink is impossible without javascript from what I know
    not really you can combine the outputlink tag with with an embedded param tag set and you are done it renders into a restful http link http get forms however are not there in core jsf you can make them but you do not get them out of the box. form handling can be achieved javascript less via commandbuttons instead of commandlinks
  30. Re: JSF?[ Go to top ]

    Oh, haven't you heared of the real kids on the block? Just to name a few: Tapestry and Wicket? J
  31. Re: JSF?[ Go to top ]

    Oh, haven't you heared of the real kids on the block? Just to name a few: Tapestry and Wicket?
    J
    yes .. here on the planet earth everyone is going with tapestry, everyone is going with wicket, everyone is going with components, ... very good that you are giving us all this very valuable and detailed info ...
  32. Re: JSF?[ Go to top ]

    Are you talking about JSF?

    As a complete aside to this thread, but hopefully someone can tell me: are there are any JSF implementations that does not require JavaScript to work, and which does not use tables for layouting?

    Those two things are requirements for doing accessible websites around here (=ALL gov. websites), and I was wondering if it's possible to do it at all with JSF. The few projects I've heard about have given up on it, and use WW instead, but maybe I just don't know enough about JSF.
    use facelets for composition and layoting dont use commandlinks but commandbuttons... pure jsf should keep you going, if you need restful stuff also use outputlinks! Most javascript and nonconformisation is introduced by third party renderers trying to get rich client ui functionality in, you always can makr your onw renderer as well and push it into a component not being compliable enough, but pure jsf only has commandlink and panelGrid as problematic constructs in this area.
  33. Then let me tell you that here on planet earth web developers are going component based.

    J
    wow, what a wonderful answer ... let's therefore say that "here on the planet earth, people use ms windows". so, everybody using mac os, linux, xbsd, xnix, ... please drop it and use ms windows ... bah.
  34. Man, it's not about OS war, ok? Its about which framework lets you do the job productively with less hassles, less plumbing, less pain. On other planets people are still using procedural languages. On planet earth people are using OO languages, including you, Paolo. Right or not? :-) J
  35. Man, it's not about OS war, ok? Its about which framework lets you do the job productively with less hassles, less plumbing, less pain.
    On other planets people are still using procedural languages. On planet earth people are using OO languages, including you, Paolo. Right or not? :-)
    J
    LOL, that was seriously funny :-) "It's not a war, but let's start one anyway!".. cute.. FWIW, I took exactly one look at Wicket and saw immediately that it would be useless for us. Why? Because too many assumptions about what is being rendered is locked up in code, which makes arbitrary customizations of the View without changing code impossible. So MVC may not be as "hip" as Components, but at least it gets the job done ;-)
  36. Man, it's not about OS war, ok?
    are you serious ??? it was clearly a metaphor, to say "if almost everyone uses SOMETHING, it does not necessarly mean that it that SOMETHING the best for every situation !". why don't you simply write your thoughts instead of looking and following the most of earth inhabitants ?
    FWIW, I took exactly one look at Wicket and saw immediately that it would be useless for us. Why? Because too many assumptions about what is being rendered is locked up in code, which makes arbitrary customizations of the View without changing code impossible
    simply perfect. in general, in my opinion this is a common problem in the component approch, too tied with UI.
  37. in general, in my opinion this is a common problem in the component approch, too tied with UI.
    Oh, you mean that a component oriented UI framework should also be able to be used as, say messaging middleware?
  38. in general, in my opinion this is a common problem in the component approch, too tied with UI.


    Oh, you mean that a component oriented UI framework should also be able to be used as, say messaging middleware?
    I think the point is, and which is what I objected to as well, is that when you look at web code you have to realize what parts are more static: the code or the template. In general I would say that the code is more static than the template, and that you will want to either have support for "themes" (which is a way to hide dynamicity of templates), or support truly end-user customizable templates. In our product, being a CMS, our customers tweak the templates all the time, and if all they could do with the template was to use whatever was available in the base code our most common support phone call would go like this: "oooh... you want to do THAT.. well, that will require a change to our UI code, so you'll have to wait for the next release". Now, this may be your cup of tea, but it aint mine. I'm a product developer, not a consultant, so I suppose it depends on your business model whether the above is a desired situation or not. This is also, coincidentally, one of the oldest arguments in the web framework "theory": push vs pull. Should the code "push" data into the template, or should the template "pull" data from the code. Because of the problems outlined above the early web frameworks that used the push mechanism were reasonably quickly abandoned in favor of "pull" frameworks, like Struts and WebWork. And for a while all was well. It was therefore with some amusement that I noticed that Wicket was a return to the "push" strategy, but now marketed under the name "Component based framework". It may be more "hip" that way, but when you cut through the fluff it's just the old "push" thing showing it's face again. Our industry is truly like a whole gang of guppies, reinventing ourselves every ten years or so, believing that whatever stuff we come up with is "new". I haven't decided yet whether this is funny or sad. But again, if that's your cup of tea, then good for you! Personally I have better things to do than constantly change controller code to satisfy whatever bizarre needs the template maestros need.
  39. In our product, being a CMS, our customers tweak the templates all the time, and if all they could do with the template was to use whatever was available in the base code our most common support phone call would go like this: "oooh... you want to do THAT.. well, that will require a change to our UI code, so you'll have to wait for the next release".

    So you are writing a CMS app. Do you think serving as the basis for a CMS framework is a typical thing for web app frameworks to support? And don't you think it is pretty weak to blame *any* framework for *your* product not being flexible enough? Especially when it comes as an afterthought like it sounds in your case.
    This is also, coincidentally, one of the oldest arguments in the web framework "theory": push vs pull. Should the code "push" data into the template, or should the template "pull" data from the code. Because of the problems outlined above the early web frameworks that used the push mechanism were reasonably quickly abandoned in favor of "pull" frameworks, like Struts and WebWork.

    I am very curious which those 'abandoned' frameworks are. 'Pull' vs 'Push' is also very generalized, and if you *had* to label Wicket something it would rather be pull. If you don't agree with that, I'd be very interested to hear your arguments.
    So, as Wicket is 'pull', I assume that you are talking about whether markup and logic should be separated and that you refer to a framework's preferred ways. If that is the case, yes, this is somewhat a matter of taste. Clean templates (no logic in them) ensures that the templates will be readable by non-programmers and fights the tendency of larger systems to evolve into spaghetti code. It is always clear where to find logic and where the layout etc is defined. Having /all/ the logic in Java also ensures it is easy to manage as you'll have all the type safety, refactoring, code browsing, etc you may wish for.
    And for a while all was well.

    Oh was it? Good for you. Meanwhile, tons of people were/are having problems with model 2 frameworks. When I started looking for alternative frameworks for the company I worked for (some 3 years ago), it was because we had serious problems with keeping our development scalable with the framework we were using (Struts and Maverick). The first two or three months developing were ok, but then when the first end-user tests started and change requests came pouring in, and when the deadlines became more urgent and when we wanted to add more developers to the project, things inevitably started breaking down. Refactoring was a pain. We needed lot of hacking (like ad-hoc session use, url generation interception and filters to clean it all up again) to get tabs, wizards and things like pageable lists working - which only added to the pain when refactoring. It was hard to find back stuff because the logic was so scattered. We couldn't get designers to work on the project as the templates were so polluted (projects done with JSP being the worst). There was hardly any reuse possible in the UI layer, so we ended up with lots of code duplication which resulted in all the problems typically related to that. And also the lack of reuse actually was a big problem when for one project we *had* to have several product variations; as we had to maintain different branches of all the config and templates and stuff, whereas with Wicket it would suffice to just have a shared project. And last but not least, most Java developers totally hated the daily hacking on the web tier and preferred to work on the back-end layers or to work with .NET.
    It was therefore with some amusement that I noticed that Wicket was a return to the "push" strategy, but now marketed under the name "Component based framework". It may be more "hip" that way, but when you cut through the fluff it's just the old "push" thing showing it's face again. Our industry is truly like a whole gang of guppies, reinventing ourselves every ten years or so, believing that whatever stuff we come up with is "new".

    Wicket's mission statement is 'enabling component-oriented, programmatic manipulation of markup'. If you can point me to one single Java web framework that fits that besides Wicket, I declare you king.
    Yes, Wicket is component based, as frameworks like Swing, Delphi and .NET are. There's nothing 'hip' about it, and I have seen no claims of any of these framework that they are doing something new. In fact they are providing a development model that was and is well established for desktop applications and that now finally gets a lot of traction in web app development as well (thanks for that Ajax, GWT, Tapestry etc).
    I haven't decided yet whether this is funny or sad.

    What is sad to me is that Java developers have had to deal with EJBs, JSPs, model 2 frameworks etc for years, and that many of them hardly recognize the advantage of having a elegant progamming model. That's hardly ever the topic of discussion here it seems. And whether you agree with the choices made in Wicket, that *is* the big driver behind the project, just like it must have been behind e.g. Hibernate.
    But again, if that's your cup of tea, then good for you! Personally I have better things to do than constantly change controller code to satisfy whatever bizarre needs the template maestros need.

    Sure. Whatever fits your needs. It *is* totally doable to use Wicket for such things, and in fact has been done a couple of times already. Also the fact that for instance http://servoy.com/ (a Java based filemaker alternative) uses Wicket as the web engine for it's product) and frameworks like PaxWicket can RSP can support Wicket says enough about it's flexibility I hope. And personally, if I would have to implement CMS like functionality, I would use e.g. the velocity or freemarker extensions or just roll something out myself.
  40. Btw, nothing in this last rant is directed at the new Struts as far as I am concerned. I have no opinion on it's usability atm, but I'm sure it is good news for a lot of people. I also appreciate the big effort - mostly in spare time - that goes into such an undertaking. Kuddos.
  41. Design decisions[ Go to top ]

    I realize that this subthread doesn't have much to do with Struts2, but at the same time it highlights many important design decisions I think. With that disclaimer in mind, here are some further throughts on this.
    So you are writing a CMS app. Do you think serving as the basis for a CMS framework is a typical thing for web app frameworks to support?
    Perhaps not, but I didn't state so either. I said that for *us* Wicket would be useless, for the reasons mentioned. All software development is about tradeoffs, but there is an important distinction between "design decisions" and "design beliefs", and you have to know which is what.
    And don't you think it is pretty weak to blame *any* framework for *your* product not being flexible enough? Especially when it comes as an afterthought like it sounds in your case.
    If I choose a framework it is of course my responsibility to make sure that it meets my needs. In this case we knew upfront that the views would be customized in absurdum by us and our customers, so choosing a framework where the view is tightly coupled to the code would have been a bad idea. And therefore Wicket would have been a poor choice, because of its characteristics and design decisions.
    I am very curious which those 'abandoned' frameworks are.
    Jon Stevens wrote a very good piece on this some time ago which is available here: http://jakarta.apache.org/turbine/turbine/turbine-2.3.2/pullmodel.html
    'Pull' vs 'Push' is also very generalized, and if you *had* to label Wicket something it would rather be pull. If you don't agree with that, I'd be very interested to hear your arguments.
    If you understand the points Jon makes in the above article that should answer your question, and I think it also explains quite well why Wicket should be considered a "push" framework rather than a "pull" framework. This is not something inherently bad, but it is a very very critical design decision, and it is important to understand the implications of it.
    So, as Wicket is 'pull', I assume that you are talking about whether markup and logic should be separated and that you refer to a framework's preferred ways. If that is the case, yes, this is somewhat a matter of taste.
    See above, Wicket is not a "pull" framework, and it is a bit more intricate than just how markup and logic should be separated. It is not so much a matter of taste as it is in understanding the implications, and whether those implications are desirable or not. Comparing Struts2 and Wicket, for example, is therefore like comparing apples and bananas, so it's not just a matter of taste but rather whether you are an Adam or a Chimp (figuratively speaking).
    Clean templates (no logic in them) ensures that the templates will be readable by non-programmers and fights the tendency of larger systems to evolve into spaghetti code. It is always clear where to find logic and where the layout etc is defined. Having /all/ the logic in Java also ensures it is easy to manage as you'll have all the type safety, refactoring, code browsing, etc you may wish for.
    Sure, and if those were the only factors to consider then all would be well. But that is far from reality, and I think Jon explained one view of this fairly well. Design decisions are simple only if you consider a small subset of the actual factors involved. That's when a "design decision" becomes a "design belief", and I would argue that your descriptions thus far fall into this category. You have chosen a small subset of factors to consider, and then base your decision on that. Which could be fine in your particular case - that I don't know - but it probably doesn't apply in a more general context where it would be better to consider all sorts of factors in order to make a good design decision.
    [snip] There was hardly any reuse possible in the UI layer, so we ended up with lots of code duplication which resulted in all the problems typically related to that. And also the lack of reuse actually was a big problem when for one project we *had* to have several product variations; as we had to maintain different branches of all the config and templates and stuff, whereas with Wicket it would suffice to just have a shared project.
    Many good points, and as I said, Wicket might be the best choice for you. But it would also be interesting to know whether this is because Wicket is inherently better in your situation, or whether the way you used the other frameworks was not optimal. I.e. would you be able to do it better with Model2 frameworks if you were to do it from scratch today. Possibly, even probably. But I agree, some of the things you mention are indeed painful to do in Model2 frameworks. Those are some of the factors you need to be aware of when you make a design decision.
    And last but not least, most Java developers totally hated the daily hacking on the web tier and preferred to work on the back-end layers or to work with .NET.
    I think this particular part is a very important reason why some developers like Wicket. It puts the power in their hands as opposed to someone elses hands. It's always easier to be in control rather than, as is outlined in Jon's article, make good API's that is like a buffet that the template developers can use.
    Wicket's mission statement is 'enabling component-oriented, programmatic manipulation of markup'. If you can point me to one single Java web framework that fits that besides Wicket, I declare you king.
    Sure, it's called portlets. And they can be written in WebWork, Struts, JSF, Tapestry, and even Wicket. It's not a framework, sure, but it's a "component-oriented programmatic manipulation of markup". And it works quite well in my experience.
    Yes, Wicket is component based, as frameworks like Swing, Delphi and .NET are. There's nothing 'hip' about it, and I have seen no claims of any of these framework that they are doing something new.
    First of all web components are quite different from traditional UI components specifically because they tend to have many different "themes" or customizable templates, depending on their granularity. Second, if there is nothing new in Wicket, why did you imply that I would not be able to come up with another framework that is component-oriented?
    In fact they are providing a development model that was and is well established for desktop applications and that now finally gets a lot of traction in web app development as well (thanks for that Ajax, GWT, Tapestry etc).
    But the question is whether that model is applicable to the web. It's a different beast, with a different interaction model, so I'm not convinced thus far.
    What is sad to me is that Java developers have had to deal with EJBs, JSPs, model 2 frameworks etc for years, and that many of them hardly recognize the advantage of having a elegant progamming model. That's hardly ever the topic of discussion here it seems. And whether you agree with the choices made in Wicket, that *is* the big driver behind the project, just like it must have been behind e.g. Hibernate.
    There is a huge difference between saying that a big driver behind a project is the desire for an elegant programming model and the project actually having one. For me, requiring code changes whenever the UI should be tweaked is not an "elegant programming model". It is a "programming intensive model".
    Sure. Whatever fits your needs. It *is* totally doable to use Wicket for such things, and in fact has been done a couple of times already.
    Excellent, then prove me wrong please. Show me an example where the template programmer can say "you know, I need to display three more fields from the model object object, give them to me" without having to change Java code. If it is totally doable, and I'm open to see that this is actually true, then show me how that works. I might just be ignorant of how Wicket works, which would be great.
  42. Re: Design decisions[ Go to top ]

    Rickard, Reading all these I see you lack deep understanding of the whole concept behind web component based frameworks and what you could achieve with them. I believe if you devote some time and go look deeper into Wicket or Tapestry, you'll quickly port your CMS product to either of them :-).
  43. Re: Design decisions[ Go to top ]

    Rickard,

    Reading all these I see you lack deep understanding of the whole concept behind web component based frameworks and what you could achieve with them. I believe if you devote some time and go look deeper into Wicket or Tapestry, you'll quickly port your CMS product to either of them :-).
    Your time would be better spent answering my questions rather than assuming what I will do or not do if I look deeper into Wicket. As it is I have no reason to look deeper, and as I said, if you can show me that there's something I've totally misunderstood about how Wicket works, then by all means, show me the light!
  44. Re: Design decisions[ Go to top ]

    Rickard,

    Reading all these I see you lack deep understanding of the whole concept behind web component based frameworks and what you could achieve with them. I believe if you devote some time and go look deeper into Wicket or Tapestry, you'll quickly port your CMS product to either of them :-).

    Your time would be better spent answering my questions rather than assuming what I will do or not do if I look deeper into Wicket. As it is I have no reason to look deeper, and as I said, if you can show me that there's something I've totally misunderstood about how Wicket works, then by all means, show me the light!
    Does your comment hold as well for Tapestry, since I mentioned that as well? You keep pinning me on Wicket as if I'm the founder.
  45. Re: Design decisions[ Go to top ]

    Does your comment hold as well for Tapestry, since I mentioned that as well? You keep pinning me on Wicket as if I'm the founder.
    I haven't looked at Tapestry, so I don't know if it has the same design choices as Wicket. Again, your time would be better spent trying to answer my questions and concerns about how Wicket works. So far there is more glorification and less fact, which is always a worrying sign.
  46. Re: Design decisions[ Go to top ]

    Jon Stevens wrote a very good piece on this some time ago which is available here:
    http://jakarta.apache.org/turbine/turbine/turbine-2.3.2/pullmodel.html
    Ok, I am reading this piece.
    The current encouragement that Turbine gives to developers is to do a mapping between one Screen (Java) and one Template (WM or V). The way it works is that you build up a Context object that is essentially a Hashtable that contains all of the data that is required to render a particular template.
    Rendering is simple, input is a bitch, especially if you have lists or maps or list of maps. It is important to automatically build the keypaths and to resolve the indices to stick input data into proper place. This is a bigger challenge and this piece does not even mention input at all. Reading data from a context object is no big deal.
    For example, say you have a set of "wizard" type screens and you want to change the order of execution of those screens or even the order of the fields on those screens. In order to do so, you can't simply change the Next/Back links you need to also change the Java code.
    Bad example and terminology mixup. A wizard is a stateful object, its views depend from its state, not vice versa. It is simply wrong to require changing page order in the wizard without modifying its code or, if code is abstract enough, its state machine. Views are driven by state, period. What he talks about is merely a sequence of loosely related pages where properties do not depend on each other. In any Model 2 framework this is easily solved by using a single form bean for all views.
    Another example of this is if you have a form on a page and you want to be able to split that form across several steps across several pages. In the current model, you would have to potentially write/modify several Java classes.
    Again, use one form bean, possibly session-scoped. I don't see a problem.
    There are several considerations that one must take into consideration regarding the design of a system to provide this level of abstraction. For example, when someone submits the form and there is an error. Proper UI would suggest that you should re-display the page with the previous form data filled in as well as an error message that details the problems. You also need to consider the ability to display the same form that may be pre-populated with information from the database instead of as an error from the user.
    Umm, so? Add page ID as a hidden form field. No problem. Prepopulating? Also simple. If there is any input event, then process it and redisplay a page if there is an error. If there are no input events in the request then prepopulate and display the page. What exactly is the problem?
    So, beginning with Scarab, we are going to try another model which I will describe as the "Pull MVC Model". What this entails is the ability to create an object that is able to "pull" the required information out at execution time within the template. Thus, it becomes the job of the template designer to understand the API of objects available to him/her to take advantage of.
    Not so simple. This is a webapp, which preserves/modifies its state while interacting with a user over stateless HTTP protocol. Using request/session/app scopes is inevitable, and it has to be a Java programmer who makes decisions on which scope to use, when to instantiate the data objects, when to remove them from memory, what to do if the object is not there but is accessed from a page, etc. Therefore push or pull, crucial decisions has to be made by Java developer as well and these decisions may have to be changed while app development goes on. I don't see a big difference between push and pull unless it is user code that sticks data from business/DTO objects into a template. Whenever you have an external templating engine it always seems pull to me, because it simply cannot make up data from thin air, it has to pull it from another source, that is, from the business/DTO layer of an application.
  47. Re: Design decisions[ Go to top ]

    I am very curious which those 'abandoned' frameworks are.

    Jon Stevens wrote a very good piece on this some time ago which is available here:
    http://jakarta.apache.org/turbine/turbine/turbine-2.3.2/pullmodel.html

    While I see what you are getting at, I don't think that piece qualifies as a general accepted theory and certainly not as a theory that 'won'. Neither can I find a string of frameworks that got deserted due to this insight. Also, the explanation mostly makes sense in the context of model 2 frameworks. My interpretation of it concerned the model parts of the UI, in which case it could be mapped to any UI framework/ paradigm.
    'Push' vs 'Pull' isn't something absolute either, as even with Velocity for instance, pull can implemented easily by exposing one or more generic tools. The intent does not always match the real usage here.
    If you understand the points Jon makes in the above article that should answer your question, and I think it also explains quite well why Wicket should be considered a "push" framework rather than a "pull" framework.

    Why should I agree with a label I don't think is even useful to start with? I think the notion of whether logic and presentation are separated are more useful than 'push' and 'pull'.
    I agree with the statement that neither are inherently good or bad, though I feel pretty strong about where it is applicable. You don't need a rigid separation of presentation and logic for smaller projects, and not having this separation may speed up initial development as it easier to develop increment. For larger projects though, separation of presentation and logic really pays off. It's really just another variation of why you should layer software in the first place. If you don't layer, some things get done much quicker initially, but often result in code that is hard to maintain. Though you don't have to agree with it, I recommend you read Building Scalable Websites, especially the first few chapters.
    It is not so much a matter of taste as it is in understanding the implications, and whether those implications are desirable or not. Comparing Struts2 and Wicket, for example, is therefore like comparing apples and bananas, so it's not just a matter of taste but rather whether you are an Adam or a Chimp (figuratively speaking).
    In the end everything is relative. However, both are web frameworks, and while there is the old 'best tool for the job' argument which is very true, there certainly are choices that are better in general than others.
    Sure, and if those were the only factors to consider then all would be well. But that is far from reality, and I think Jon explained one view of this fairly well. Design decisions are simple only if you consider a small subset of the actual factors involved. That's when a "design decision" becomes a "design belief", and I would argue that your descriptions thus far fall into this category. You have chosen a small subset of factors to consider, and then base your decision on that.

    No, I gave you *a couple* of the design decisions. Or rather, I gave you a couple of the reasons why I started out looking for alternative frameworks a couple of years ago.
    Which could be fine in your particular case - that I don't know - but it probably doesn't apply in a more general context where it would be better to consider all sorts of factors in order to make a good design decision.

    Wicket is not build for a particular case. Like most web app frameworks are not.
    But it would also be interesting to know whether this is because Wicket is inherently better in your situation, or whether the way you used the other frameworks was not optimal. I.e. would you be able to do it better with Model2 frameworks if you were to do it from scratch today. Possibly, even probably.

    Today, I even have a better understanding of the problems with model 2 than I had years ago. Using a framework like Stripes (and maybe Struts 2; like I said I don't have an informed opinion on that yet) would make things marginally better but the most important concerns I have to today wouldn't be solved by it. Honestly, I would rather change jobs than having to deal with a model 2 framework again. I'm glad that I love working with Java once again and I intend to keep it that way.
    Wicket's mission statement is 'enabling component-oriented, programmatic manipulation of markup'. If you can point me to one single Java web framework that fits that besides Wicket, I declare you king.

    Sure, it's called portlets. And they can be written in WebWork, Struts, JSF, Tapestry, and even Wicket. It's not a framework, sure, but it's a "component-oriented programmatic manipulation of markup".

    Portlets are a nice *additional* technology, which work well for some situations but certainly not for all. And indeed it is not a framework so your crowning has to wait I'm afraid.
    First of all web components are quite different from traditional UI components specifically because they tend to have many different "themes" or customizable templates, depending on their granularity.

    You are confusing the concept of user interfaces with some particular ideas you have about how to implement them. There are some differences, yes, but conceptually you can have most if not all the widgets and programming constructs you would have in a desktop environment.
    Second, if there is nothing new in Wicket, why did you imply that I would not be able to come up with another framework that is component-oriented?

    Oh there's enough novelty in Wicket for sure. Component orientation isn't one of them though. Maybe that one-liner isn't strong enough by itself.
    In fact they are providing a development model that was and is well established for desktop applications and that now finally gets a lot of traction in web app development as well (thanks for that Ajax, GWT, Tapestry etc).
    But the question is whether that model is applicable to the web. It's a different beast, with a different interaction model, so I'm not convinced thus far.
    That's fine, though I would be surprised if that includes being not convinced about Ajax. With Wicket we took the unusual approach it seems to start from what we believe is the optimal programming model and then optimize later (the phase we are in now).
    Excellent, then prove me wrong please. Show me an example where the template programmer can say "you know, I need to display three more fields from the model object object, give them to me" without having to change Java code.
    If it was just about adding a few fields every now and then that we would be talking about, and not conditionals, loops etc, we wouldn't have this discussion.
    Like you probably understand by now, *I* don't think it is a good thing to have designers (template 'programmers'?) do this in the first place. So with Wicket you would typically add the place holders in the template and then add the components in Java. And that works really well in my experience, whether the roles are separated or not. That said, it is pretty easy to bend Wicket to your own needs. The two exceptions we currently have are , which automatically resolves all embedded anchors, and which replaces it's body with text from message bundles. It is easy (couple of lines of code, and in fact easier to write than say custom JSP tags) to add your own tag handlers, so if you want you could implement that. We actually used to even have which could instantiate components on the fly (your idea of 'pull'). However, we removed it (or are about to) as we feel it encourages bad practice. If people want to develop like that, that's fine, but we just don't want to encourage it.
  48. Re: Design decisions[ Go to top ]

    While I see what you are getting at, I don't think that piece qualifies as a general accepted theory and certainly not as a theory that 'won'. Neither can I find a string of frameworks that got deserted due to this insight.
    The old Turbine framework would be one. ECS is another (although that was horrible for oh so many other reasons). Enhydra XMLC is another. The ideas behind "pull" may not have "won", and I don't know what would qualify as "winning" either, but the majority of the popular frameworks these days use the "pull" approach.
    'Push' vs 'Pull' isn't something absolute either, as even with Velocity for instance, pull can implemented easily by exposing one or more generic tools. The intent does not always match the real usage here.
    Certainly, and I should note that we use Velocity exclusively as the templating mechanism with WebWork. Figuring out what to register in the context ("push") is a constant struggle, because we always find ourselves wanting more when we come to template customization situations.
    For larger projects though, separation of presentation and logic really pays off. It's really just another variation of why you should layer software in the first place. If you don't layer, some things get done much quicker initially, but often result in code that is hard to maintain.
    But here you are mixing apples and oranges, and in a strange way too. When you layer software it's usually the case that the layers that are above (=closer to the client) call those below (=closer to the database). And that is good 'n all. But what you are saying is that a layer that is below (=Java code) should control the layer that is above (=template). And that may be ok if you have a 1-1 mapping between the layers, and if you very rarely want to change the template layer, but if you have a 1-N situation, with many templates using the same Java model or code, then it becomes tricky. Or how do you support that in Wicket? Please explain!
    Though you don't have to agree with it, I recommend you read Building Scalable Websites, especially the first few chapters.
    Not sure what that has to do with anything discussed here. Can you explain?
    Portlets are a nice *additional* technology, which work well for some situations but certainly not for all. And indeed it is not a framework so your crowning has to wait I'm afraid.
    Damn, and here I was thinking I had answered your question, and without the restriction of having to limit myself to frameworks... so close... oh well.
    That's fine, though I would be surprised if that includes being not convinced about Ajax.
    Well, I wouldn't use AJAX myself for a number of reasons. First of all, gov. regulations here in Sweden mandates that all websites must work equally well without JavaScript, and about 80% of our customers are in the gov. sector. Using AJAX and JavaScript would therefore force us to develop a solution twice, which is not a good idea. Second, I've done my share of JavaScript debugging and prefer to stay away from it. Our customers have a wiiiide range of browsers, and just creating CSS that works decently is a nightmare in itself. And third, when it comes to integrating apps in a portal, which is increasingly becoming the norm around here, AJAX tends to mess things up as it makes a lot of assumptions about its runtime environment that are not true in a portlet setting. So I usually discourage people from using it. Developers and marketing people tend to whine about this, and those responsible for actually purchasing solutions and running them are usually more happy about it.
    If it was just about adding a few fields every now and then that we would be talking about, and not conditionals, loops etc, we wouldn't have this discussion.
    So you can't do what I asked in Wicket?
    Like you probably understand by now, *I* don't think it is a good thing to have designers (template 'programmers'?) do this in the first place.
    Yes, that much I have understood...
    So with Wicket you would typically add the place holders in the template and then add the components in Java.
    But is that the ONLY way to do it? So if I have shipped a system to a customer, and they want to tweak the UI to include more things, what would you say to them?
    We actually used to even have which could instantiate components on the fly (your idea of 'pull').
    Wheeee!!
    However, we removed it (or are about to) as we feel it encourages bad practice.
    oooh....
    If people want to develop like that, that's fine, but we just don't want to encourage it.
    Thanks for the clarifications.
  49. Re: Design decisions[ Go to top ]

    The old Turbine framework would be one. ECS is another (although that was horrible for oh so many other reasons). Enhydra XMLC is another.
    The ideas behind "pull" may not have "won", and I don't know what would qualify as "winning" either

    Maybe 'losing' then, as you stated they were 'quickly abandoned'.
    And what makes you say Enhydra XMLC is abandoned? It still seems in active development (a new release today even), and I'm sure it has a healthy share of users for which is just works fine.
    , but the majority of the popular frameworks these days use the "pull" approach.
    And the majority must be right, right? :)
    But what you are saying is that a layer that is below (=Java code) should control the layer that is above (=template).
    I made a statement about layering software in general. Separation of concerns would have been a better wording. And that can be on any level. In this case, presentation and logic can be such separate concerns. So in the presentation part you say, I want a grid here and a link there. In the logic part, you would decide how to render the grid and link (which for a large part would be the decision of how to get and use the data that feeds the components) and how to process input. You can debate on whether M+V are logically one or not and where exactly the M ends and V starts. But that's hair splitting, and I hope you get my drift by now.
    And that may be ok if you have a 1-1 mapping between the layers, and if you very rarely want to change the template layer, but if you have a 1-N situation, with many templates using the same Java model or code, then it becomes tricky. Or how do you support that in Wicket? Please explain!
    Templates are used on any level, and the 'page' you are viewing at any time is a dynamically built tree (1-N?) of components, and for components like Panels, Fragments and Borders the actual markup to be used is deferred until the page is rendered. There is absolutely no inflexibility in that.
    Though you don't have to agree with it, I recommend you read Building Scalable Websites, especially the first few chapters.
    Not sure what that has to do with anything discussed here. Can you explain?
    Yes. The author is the lead developer of Flickr, and they develop with PHP (UI) and Java (services). The interesting thing is that - even though they use PHP - they have a very strict separation of presentation and logic. Ah, just read it, it's a good book.
    Well, I wouldn't use AJAX myself for a number of reasons. First of all, gov. regulations here in Sweden mandates that all websites must work equally well without JavaScript, and about 80% of our customers are in the gov. sector. Using AJAX and JavaScript would therefore force us to develop a solution twice, which is not a good idea.
    Second, I've done my share of JavaScript debugging and prefer to stay away from it. Our customers have a wiiiide range of browsers, and just creating CSS that works decently is a nightmare in itself.
    And third, when it comes to integrating apps in a portal, which is increasingly becoming the norm around here, AJAX tends to mess things up as it makes a lot of assumptions about its runtime environment that are not true in a portlet setting. So I usually discourage people from using it. Developers and marketing people tend to whine about this, and those responsible for actually purchasing solutions and running them are usually more happy about it.
    Fair enough. I love what ajax can do for the development model when the proper abstractions are used. But I agree it isn't always applicable.
    So with Wicket you would typically add the place holders in the template and then add the components in Java.
    But is that the ONLY way to do it? So if I have shipped a system to a customer, and they want to tweak the UI to include more things, what would you say to them?
    No, it is not the only way to do it, which is why I said *typically*. It is the preferred way to do it, but if you have the (very specific?) requirement that you ship a product that may be altered by customers (like a CMS I guess), you could plan for that, define the kind of alterations than are permitted. I would in that case probably choose to provide velocity or freemarker for the customer's templating needs (e.g. using Wicket's Velocity- or Freemarker integration projects) and provide the context and tools according to what I would permit. The sky is the limit though, so it depends on what you want you think will work best for you.
    We actually used to even have which could instantiate components on the fly (your idea of 'pull').

    Wheeee!!
    However, we removed it (or are about to) as we feel it encourages bad practice.
    oooh....
    But if such use would be your thing, you could go ahead and create such a tag handler with just a class or two.
  50. Re: Design decisions[ Go to top ]

    I wouldn't use AJAX myself for a number of reasons. First of all, gov. regulations here in Sweden mandates that all websites must work equally well without JavaScript, and about 80% of our customers are in the gov. sector. Using AJAX and JavaScript would therefore force us to develop a solution twice, which is not a good idea.
    Not quite. You can have sync and async functionality using single codebase.
  51. jspcontrols?[ Go to top ]

    Michael, this is off-topic of course, but since you mentioned it: is jspcontrols an abandoned project? I'm asking because I see no progress in CVS.
  52. Re: jspcontrols?[ Go to top ]

    Michael, this is off-topic of course, but since you mentioned it: is jspcontrols an abandoned project? I'm asking because I see no progress in CVS.
    No, it is not. Last year I had to concentrate on my personal life, but it is all sorted out now so the development has restarted. You will see better documentation, cleaner Javascript code, less session usage and better integration with Struts framework. In fact, after I have become Struts committer I was contemplating donating the code to Struts project. Any interest in that?
  53. Re: jspcontrols?[ Go to top ]

    No, it is not. Last year I had to concentrate on my personal life, but it is all sorted out now so the development has restarted. You will see better documentation, cleaner Javascript code, less session usage and better integration with Struts framework. In fact, after I have become Struts committer I was contemplating donating the code to Struts project. Any interest in that?
    That would be great. But keep the option to use it without Struts, too.
  54. Struts 2: pushmi-pullyu[ Go to top ]

    Struts 2 actually supports both push and pull. Aside from invoking actions through a hyperlink or form submit, you can also call an action from a Struts tag as the page renders. You can use an "inline" action to make values available to the page or include a page snippet with additional markup (a la Tiles). * http://struts.apache.org/2.0.6/docs/action.html If an application has a number of rich or reusable controls, each control can be put on its own snippet, with its own action, and then plunked down on whatever page needs to use it. Struts 2 also supports Stripes-style annotations, leading to a XML-free configuration. Through plugins, Struts 2 supports a number of optional features, like JSF components and ASPX-style codebehinds, where you can associate a page with an action just by naming them alike (sans XML or annotation). There are also third-party plugins available to support offerings like Spring WebFlow and the Google Web Toolkit. Another new plugin adds a set of table-management tags to S2, in the DisplayTag tradition. With the Struts/WebWork merger, I believe the group has demonstrated that web framework developers can put aside design fetishes and work together on common solutions that let us each write our own applications in our own way. Moving forward, I expect that Struts will continue to adopt and adapt the very best design ideas from all the frameworks on all the platforms, so that we can better share the wealth. -Ted.
  55. Re: Struts 2: pushmi-pullyu[ Go to top ]

    Struts 2 actually supports both push and pull.
    Yeah, it was part of the point I was trying to make that even though some frameworks may make it easier or harder to do that push or pull thing, you can usually choose (or mix) those approaches, meaning that at the end of the day it is how you choose to use (or extend) the framework.
    Moving forward, I expect that Struts will continue to adopt and adapt the very best design ideas from all the frameworks on all the platforms, so that we can better share the wealth.
    Framework developers spoil their users too much ;)
  56. FWIW, I took exactly one look at Wicket and saw immediately that it would be useless for us. Why? Because too many assumptions about what is being rendered is locked up in code, which makes arbitrary customizations of the View without changing code impossible.

    Too many assumptions? Design choices you mean? 1) A no-compromise separation of markup and the logic that works on that. 2) Providing stateful components and a rich interaction model between those components and their models without sucking users into configuration hell. That may or may not work for you. It is certainly a switch to what most people are used to.
    So MVC may not be as "hip" as Components
    I'm such a fashion kid for choosing components. Oh my, I work on a Mac too! Btw, congrats Struts team!
  57. Spring is bigger and better ?[ Go to top ]

    Why choose struts when it goves you only UI framework components. We used struts extensively and now moved to SPRING because it has IOC, JDBC, transactiosn, aspects and ofcourse MVC. so why to use something just for UI whe you have a pretty good framework which doesn everything from UI to integration. ?
  58. Request for Groovy action[ Go to top ]

    If script action is available, it will be wonderful. Script action can make development fast. Groovy support shoud be first, then others. Thanks.
  59. Hmmmmm...Struts 2 wasn't on my radar, but I'm intrigued by the feature set. Jasperreports, Spring integration, JSF and GWT integration, and some AJAX... I would argue that this is Struts in spirit only, but worth a look.
  60. In a lot of conservative corporate environments I've worked in, particularly financial institutions, government departments etc. they already have Struts 1.x with the J2EE stack, firmly embedded as the standard architecture. This looks like a great way of getting some of the newer technology you mention into these places under the guise of a Struts version upgrade. I'm sure a lot of developers will welcome this, regardless of whether there may be better web frameworks around nowadays. Its simply the path of least management resistance.
  61. Fantastic work. Struts 2 is having a bright future and the team behind it are really devoted and bright people. I know as I in the past helped the WebWork team. I'm really impressed that the documentation is so complete and good at this time already. Keep it up.
  62. Better framework for web developer[ Go to top ]

    Having a chance to look at the architecture, it is a really better choice for traditional struts developer looking for new framework to learn and use.Over the last 2 or 3 years,it seems the old Struts has been sleeping for so long time without significant improvement while other framework are getting more and more popular among web developers keeping up with the maturity of java world. Now struts 2 can incooperate nice features from others,specifically ACTION FORM being replaced with Domain model while keeping its own ease of use and simplicity. Hopefully, Struts 2 can still be the dominant player in web framework market like before by keeping up with the fast-growing java technology.
  63. Much better than Struts 1 - Definitely true. But IMHO it stills lack from some conceptual niceties that it might have. And I think that the responsible for that is JSP and not Struts... And don't get me wrong, I been using Struts for years! 1- That Action-UI separation. The Action has to gather all the info, put it in the request and forward to the JSP. If there is something wrong in the JSP, too late. The transaction was closed, etc. That separation is the one that force us to have the OpenSessionInView filter (aweful) and things like that. How can we solve that? I don't see much hope using JSP... It would be great if the Action can inject the objects in the UI and the last starts rendering it in parallel instead of gathering all the objects first and render them later. So, if there is any problem in the UI rendering, the action can react. 2- A better Component approach. Struts deals great with tags but they lack of a persistent state serverside. So, a tag is never self contained, it needs from an execution context, let's say, the action injecting state in the request and retrieving it in the post. Our 'friends' of .NET do that much better. So far, the only UI framework I know that deals with these 2 things is Wicket. It is too young and needs a lot of work. But I still think we have some lessons to learn from those guys.
  64. ... That Action-UI separation....
    exactly what i dislike about the component approaches. why should we tie so strictly action and ui ? actions (or controllers or whatever) in my opinion should stay as separated as possible. you say "If there is something wrong in the JSP, too late". too late for what ? jsp must only display values, not execute any action ! Of course if you write jsp having side effects, the problem is in you, not in the jsp.
  65. In the UI you can have several *rending* problems. Or you are thinking out loud or have no experience at all. As an example among hundreds, formating dates is something you must do in the UI, not in the action and that can cause errors. What can you then? Only display a nice error page, BUT the transaction was commited. The rendering and the control should execute concurrently in a professional environment.
  66. In the UI you can have several *rending* problems. Or you are thinking out loud or have no experience at all. As an example among hundreds, formating dates is something you must do in the UI, not in the action and that can cause errors. What can you then? Only display a nice error page, BUT the transaction was commited. The rendering and the control should execute concurrently in a professional environment.
    You can't render in parallel in a Web environment because a server can't initiate a request, only the client. The server can issue only one complete response and that's all. Partial rendering is only supported through Ajax. That's the reason why there is an MVC2 pattern : the model can't notify parts of the view to refresh themselves. A lot of problems that we deal with come from this very simple fact. Because of this situation, in a web environment, the input controller is in charge of notifying the view to redisplay itself which in the regular MVC is the job of the model (using the observer pattern most of the time). So I think what you were saying is there should be a way to ensure all the data is effectively loaded before ending the transaction and processing the view. As I know, there are plenty of good solutions and not so good solutions to that problem : openSessionInViewFilter, extended persistence context, ensuring manually that all you objects are loaded, turn off lazy loading, ...
  67. In the UI you can have several *rending* problems. Or you are thinking out loud or have no experience at all. As an example among hundreds, formating dates is something you must do in the UI, not in the action and that can cause errors. What can you then? Only display a nice error page, BUT the transaction was commited. The rendering and the control should execute concurrently in a professional environment.


    You can't render in parallel in a Web environment because a server can't initiate a request, only the client. The server can issue only one complete response and that's all. Partial rendering is only supported through Ajax.

    That's the reason why there is an MVC2 pattern : the model can't notify parts of the view to refresh themselves. A lot of problems that we deal with come from this very simple fact. Because of this situation, in a web environment, the input controller is in charge of notifying the view to redisplay itself which in the regular MVC is the job of the model (using the observer pattern most of the time).

    So I think what you were saying is there should be a way to ensure all the data is effectively loaded before ending the transaction and processing the view. As I know, there are plenty of good solutions and not so good solutions to that problem : openSessionInViewFilter, extended persistence context, ensuring manually that all you objects are loaded, turn off lazy loading, ...
    Just to complete, I think you were saying that you wanted the actual control logic and view processing logic to execute in the same transaction. Well I think it's a lot worse than openSessionInViewFilter, you have an error in your ui and the whole transaction is rolled back. I would never do that and I think it's already possible to do if you want so but not recommended. I could be wrong.
  68. In the UI you can have several *rending* problems. Or you are thinking out loud or have no experience at all. As an example among hundreds, formating dates is something you must do in the UI, not in the action and that can cause errors. What can you then? Only display a nice error page, BUT the transaction was commited. The rendering and the control should execute concurrently in a professional environment.
    This is how you can do it in Struts1 running on Tomcat:
    public ActionForward renderView(...) {   HttpSession session = request.getSession();   HttpJspBase page = new mypage_jsp();   page.init(getServlet().getServletConfig());   try {     page._jspService(request, response);   } catch (...) {     // Handle render errors here   }   page.destroy();   return null; }
    You can make a utility method that will do something like this and call it instead of returning mapping.findForward
  69. Much better than Struts 1 - Definitely true.

    But IMHO it stills lack from some conceptual niceties that it might have. And I think that the responsible for that is JSP and not Struts...
    And don't get me wrong, I been using Struts for years!

    1- That Action-UI separation. The Action has to gather all the info, put it in the request and forward to the JSP. If there is something wrong in the JSP, too late. The transaction was closed, etc. That separation is the one that force us to have the OpenSessionInView filter (aweful) and things like that. How can we solve that? I don't see much hope using JSP... It would be great if the Action can inject the objects in the UI and the last starts rendering it in parallel instead of gathering all the objects first and render them later. So, if there is any problem in the UI rendering, the action can react.

    2- A better Component approach. Struts deals great with tags but they lack of a persistent state serverside. So, a tag is never self contained, it needs from an execution context, let's say, the action injecting state in the request and retrieving it in the post. Our 'friends' of .NET do that much better.


    So far, the only UI framework I know that deals with these 2 things is Wicket. It is too young and needs a lot of work. But I still think we have some lessons to learn from those guys.
    Actually no wicket is not the only one, jsf has state handling and can save states client and server side. I assume tapestry does it as well, pretty much every component framework has to, to deal with the event logic. As for conversations handling of db connections etc.. so that you do not run into something fails in the renderer the db already has a commit issue, there are lots of frameworks covering this. The opensessioninview filter is there, but this is only half the way, as you said, I think persistence context aware conversation systems like seam are the way to go in the long run, the view layer should not really be concerned with those issues. Sateful saving is needed for more complex ui interactions like in mask events, but the html methodology basically is broken by design in this area, all soolutions on top of html are hacks, they work, but they do not look good and add a certain burden. Stateless mvc frameworks are the closest thing to pure mvc on top of html you can get, everything added is burden. And there are a lot of usecases where you do not want to have this burden on top of everything.
  70. See http://www.sucks-rocks.com/rate/struts2/tapestry/jsf/wicket/stripes ;-)
  71. Haha. That's awesome. :)
    See http://www.sucks-rocks.com/rate/struts2/tapestry/jsf/wicket/stripes

    ;-)
  72. Haha. That's awesome. :)

    See http://www.sucks-rocks.com/rate/struts2/tapestry/jsf/wicket/stripes

    ;-)
    Meaningless. For example: http://www.sucks-rocks.com/rate/Ford/Yugo
  73. Haha. That's awesome. :)

    See http://www.sucks-rocks.com/rate/struts2/tapestry/jsf/wicket/stripes

    ;-)

    Meaningless. For example: http://www.sucks-rocks.com/rate/Ford/Yugo
    You/Me
  74. Ford vs Yugo[ Go to top ]

    What's wrong with Yugo? A friend of mine has bin driving 25+ years old Yugo 45 without problems. I doubt you could do more with Ford, any model ;)
  75. make no sense! struts 3.4 struts1 ? struts 1 10.0 struts 1.x 0.0 1 6.8 struts2 10.0 struts 2 ? struts 2.x ? 2 8.1
  76. AKA WebWork 3, IMHO.