I am not an expert in action framework concepts, despite having used struts for several years :) but I have some practical experience with Struts, an action-based framework. So hopefully I can comment on the benefits of an action-based framework from the perspective a component-based mindset.
I started writing web apps in a pure component-based web framework (WebObjects/Objective C) back in the 90s, and around the year 2000, give or take a couple years, wrote a major web application in WebObjects/Java, which I continue to maintain to this day. At some point, maybe around 2005 or 2006, a political decision was pushed down from above to switch the project to Struts, an action-based framework. Eventually, the project was converted over to struts (which took longer than developing the project in the first place, despite knowing exactly what it was supposed to do), and it continues to run in struts until this day. Now there is a strong recommendation that the project be switched over to JSF, which you might think that I, as a component-based development mindset person, would agree, especially since all of my other projects are in JSF these days. However, as I considered the conversiion, I realized that the action-based style provides some benefits for a public-facing needs-to-be-secure-and-error-free application. On a JSF page, anything that's a bean can have its methods called and its values set. There's no contract enforced between the view and controller layer, so the designer has to insure that view beans aren't providing non-view-bean access. There's also no correspondence between calling an action method and determining what field values (component value bindings) are related to that method. In Struts, you explicitly define which methods are actions (not every "public String" or "public void" is neccessarily supposed to be an action) and more importantly which fields (by defining the form) are tied to which actions. These value containers are completely isolated from the real values, like UIInput.getSubmittedValue(). All of this is enforced by the framework rather than designed-in by the developer. This adds a lot more work, but will eliminate certain classes of development errors due to the fact that you cannot break the contract. This is something that you probably could make happen in JSF right now with enough extra work. Action based framework action methods also operate on the idea of a pipeline. You don't call a single method, you call a chain of methods, each of which, like the unix shell do one small job, then forward to task on to the next thing. Not being an action-framework-mindset person, I probably don't fully take advantage of what this is supposed to allow you to do. it seems to me that it is rare that a web form action can be broken up into many sharable sequential input->output-based subtasks, other than processing a page submit, then initializing the next page. I used it a little bit to add page-based state management to my application (webobjects, like most component-based frameworks, was stateful, but struts was not stateful). I also "cheated" and used velocity as my view framework instead of JSPs (just like I "cheated" and used facelets as my view framework in JSF 1.1, which gave me a little bit more of a component-based presentation layer. (velocity macros). Explicitly initializing a page still seems good to me, even after 10 or 11 years of using JSF. Integration and unit testing for a struts project currently is far easier than testing a JSF project because of the explicit contract and statelessness. In an ideal world, I guess I'd like to upgrade this struts project so that I am using facelets as the view templating system (rather than velocity). I'd like the project to remain stateless (my page state system is more than adequate for the few things that need to retain state). I'd like to keep the explicit forced declaration of what form values belong to which actions, and how those values are validated for that action. I don't want to lose my ability to test, and maybe it is my own fault for not looking harder, but I haven't found a good way to test JSF pages after all this time. I'm not sure if I care about action chaining, but I like explicit page initialization. So I'm glad to see that action support is being considered for JSF 2.3. I think the explicit action/form declarations can be helpful. I'm glad that MyFaces is working on statelessness. At some point, it may indeed be practical to upgrade this project to JSF without losing all of the benefits that I now, years later, see that struts has provided. I definitely didn't see any benefits when I initially switched. Hope this helps. On Tue, Jan 14, 2014 at 6:24 AM, Christian Beikov <[email protected]> wrote: > Could you explain what the actual benefits of the action based programming > style are? I am missing the purpose/use cases for the actual need of such a > feature. > > Thanks in advance! > > Mit freundlichen Grüßen, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 14.01.2014 12:02, schrieb Thomas Andraschko: > >> If they add support for such actions with @RequestMapping, then it should >> also be possible to declare request params as method params. >> e.g. >> >> @RequestMapping(...) >> public void doSomething(@RequestParameter(name="..") private String test) >> >> >> And of course conversion/validation of the request parameters. >> >> >> 2014/1/14 Karl Kildén <[email protected]> >> >>> Hello, >>> >>> Any opinions on this >>> >>> >>> https://weblogs.java.net/blog/mriem/archive/2014/01/13/jsf-tip-56-using-action-based-prototype-mojarra >>> >>> Basically it's regarding the common opinon that JavaEE should have a >>> action >>> based framework or support a action based style in JSF. >>> >>> cheers >>> >
