Grokbase Groups Struts user July 2005
FAQ

[Struts-user] Putting execute() in ActionForm

Schaub, Stephen
Jul 11, 2005 at 6:07 pm
I'm interested in some feedback on the following:

I prefer to develop web applications using a page-centric model. I like the simplicity of one JSP <-> one Java class for the view layer (not the model). Struts, with its separate Action and ActionForm classes, tends toward at least two Java classes for a JSP: an Action, and an ActionForm. This tends toward a multiplicity of Java classes. (I know it's possible to share a single ActionForm and Action for multiple JSP's, but I'm looking for a simpler approach.)

I would like to create a generic Action class that delegates request processing to a SimpleActionForm, like this:

public abstract class SimpleActionForm extends ActionForm {
public abstract ActionForward execute(
ActionMapping mapping,
HttpServletRequest request,
HttpServletResponse response) throws Exception;
}

public class SimpleAction extends Action {
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {

SimpleActionForm bean = (SimpleActionForm)form;
return bean.execute(mapping, request, response);
}
}

With this approach, most JSP pages could have a single Java class -- a SimpleActionForm subclass that handles both validation and processing for the page:

public class LoginForm extends SimpleActionForm {

private String username;
private String password;

... getter and setter methods ...

public abstract ActionForward execute(
ActionMapping mapping,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
... Login processing ...
}


public ActionErrors validate(ActionMapping mapping, HttpServletRequest req) {
... validation code ...
}

}

Then, in my struts-config.xml file, most form beans would extend the SimpleActionForm, and most actions would use the SimpleAction type:

<form-beans>
<form-bean name="loginform" type="LoginForm" /> <!-- extends SimpleActionForm -->
</form-beans>

<action path="/login" type="SimpleAction" name="loginform" scope="request"
validate="true" input="/login.jsp">
...
</action>


I don't have a lot of experience with Struts, so I'm interested on feedback about this approach. Is it a good/bad idea? If bad, why?

Thanks in advance,

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
reply

Search Discussions

26 responses

  • Rick Reumann at Jul 11, 2005 at 7:20 pm

    Schaub, Stephen wrote the following on 7/11/2005 2:07 PM:

    With this approach, most JSP pages could have a single Java class --
    a SimpleActionForm subclass that handles both validation and
    processing for the page:
    Michael, is this guy a plant from your StrutsDialog camp?:)

    --
    Rick

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Michael Jouravlev at Jul 11, 2005 at 8:15 pm

    On 7/11/05, Rick Reumann wrote:
    Schaub, Stephen wrote the following on 7/11/2005 2:07 PM:
    With this approach, most JSP pages could have a single Java class --
    a SimpleActionForm subclass that handles both validation and
    processing for the page:
    Michael, is this guy a plant from your StrutsDialog camp?:)
    I wanted to post something like "Rick, Ted and other orthodox guys,
    check out this guy's suggestion", but then I decided not to ;-)

    Michael.

    Oh, almost forgot the plug: Struts Dialogs,
    http://struts.sourceforge.net/strutsdialogs/index.html

    ;-)

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Ted Husted at Jul 13, 2005 at 7:22 pm

    In 7/11/05, Michael Jouravlev wrote:
    I wanted to post something like "Rick, Ted and other orthodox guys,
    check out this guy's suggestion", but then I decided not to ;-)
    Wow! That may have been the first time anyone has ever accused me of
    being "orthodox" :)

    I've never used this strategy myself, but I don't see anything wrong
    with it. In fact, if I were to start coding in Java again, this is
    the strategy I would probably use. At this point, I'm accustom to
    having a code-behind, and the ActionForm is the closest thing Struts
    has to a code-behind.

    If I were to use this strategy, I'd select the parameters to the
    Execute signature with care. There may not be any reason to pass the
    HTTP parameters out of the call, and there may be a reason to pass
    the Action. I would just be careful of using the parameters from the
    Struts Execute signature, unless my code actually needed those
    parameters..

    I also wouldn't hestitate to put some "traffic cop" code into the base
    Action as needed, so that the ActionForm execute can focus on what it
    needs to do, rather than what the application needs to do.

    I'd also consider using a base ActionForm with all the properties my
    application needs, which I could then extend with execute and validate
    methods, as needed.

    Though, I'd probably use a DynaActionForm instead of a conventional
    ActionForm as the base class, just for the agility.

    Most importantly, I'd make very sure that all my "code-behind
    ActionForms" were request scope, probably by changing the factory
    default.

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Michael Jouravlev at Jul 13, 2005 at 7:30 pm

    On 7/13/05, Ted Husted wrote:
    Most importantly, I'd make very sure that all my "code-behind
    ActionForms" were request scope, probably by changing the factory
    default.
    In this case this form would not be stateful. At least for me, it is
    the whole point of sticking data and behavior and state in one place.
    Redirection does not work well with request scope. And redirection is
    the must to cleanly separate input phase from output phase. See, I was
    right calling you 'orthodox' :))

    Michael.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Rick Reumann at Jul 11, 2005 at 7:34 pm

    Schaub, Stephen wrote the following on 7/11/2005 2:07 PM:

    public class SimpleAction extends Action { public ActionForward
    execute( ActionMapping mapping, ActionForm form, HttpServletRequest
    request, HttpServletResponse response) throws Exception {
    SimpleActionForm bean = (SimpleActionForm)form; return
    bean.execute(mapping, request, response); } }
    You can do that, although I still like my business logic done higher up
    in the Action (Servlet) that I submit to rather than having it be done
    in the Object that is backing the view (your ActionForm subclass).
    Michael Jouravlev on this list does this and his stuff looks very nice
    if you want to take this approach.
    With this approach, most JSP pages could have a single Java class --
    a SimpleActionForm subclass that handles both validation and
    processing for the page:
    Well they certainly wouldn't have a 'single' java class, you would have
    a LOT of them. I can have one ActionForm (if I wanted) for my entire
    application but you will definitely have many of them to process the
    business logic. You mean you'll have 'one' java class that is extended.
    I don't see the big deal of that since Struts has the same concept..
    your ActionForms extend a flavor of the ActionForm base class.
    public class LoginForm extends SimpleActionForm { private String
    username; private String password; ... getter and setter methods ...


    public abstract ActionForward execute( ActionMapping mapping,
    HttpServletRequest request, HttpServletResponse response) throws
    Exception { ... Login processing ... } public ActionErrors
    validate(ActionMapping mapping, HttpServletRequest req) { ...
    validation code ... }

    }
    I don't think you meant for that to be abstract. But notice you know
    have an execute in all your ActionForms? How is that different than
    simply the processing done in different Actions as Struts is now? All
    you've done is pushed down the processing to a different place..
    ActionForm vs Action.
    Then, in my struts-config.xml file, most form beans would extend the
    SimpleActionForm, and most actions would use the SimpleAction type:

    <form-beans> <form-bean name="loginform" type="LoginForm" /> <!--
    extends SimpleActionForm --> </form-beans>
    Ok, yes they'd have to extend that in order to utilize your processing
    in the ActionForm functionality. Bottom line is I think all you've done
    is move where you do the processing... you moved it from the Actions to
    the ActionForms. If you like this approach definitely check out
    StrutsDialog. (Sorry Michael, not trying to oversimplify all that your
    stuff does, I realize it's much more than processing in the ActionForm,
    but if he's going to do this he might as well stand on the shoulders of
    someone who has done all the work already:)

    --
    Rick

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Schaub, Stephen at Jul 11, 2005 at 7:56 pm

    Rick Reumann wrote:

    With this approach, most JSP pages could have a single Java class --
    a SimpleActionForm subclass that handles both validation and
    processing for the page:
    Well they certainly wouldn't have a 'single' java class, you
    would have
    a LOT of them.
    Sorry -- I meant a single Java class per JSP page, instead of _two_ Java classes (an Action and an ActionForm) per JSP page.
    I don't think you meant for that to be abstract. But notice you know
    have an execute in all your ActionForms? How is that different than
    simply the processing done in different Actions as Struts is now? All
    you've done is pushed down the processing to a different place..
    ActionForm vs Action.
    Yes -- it is supposed to be abstract -- each ActionForm subclass must define an execute() method to perform the processing for that form. You're right in saying that All I've done is push the processing to a different place -- but it's for the purpose of combining the Action and the ActionForm to reduce the number of separate Java classes needed for a typical Struts app, hopefully reducing complexity.
    If you like this approach definitely check out StrutsDialog.
    Thanks for the tip. I took a brief look, but I don't see how StrutsDialogs corresponds to what I'm suggesting. It appears to maintain a separation of Action and ActionForm, which I am proposing to combine.

    Stephen

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Zarar Siddiqi at Jul 11, 2005 at 8:09 pm
    I think the ideal that you're searching for is "one class per view". Take a
    look at JSF.


    ----- Original Message -----
    From: "Schaub, Stephen" <stephen.schaub@agilysys.com>
    To: "Struts Users Mailing List" <user@struts.apache.org>
    Sent: Monday, July 11, 2005 3:56 PM
    Subject: RE: Putting execute() in ActionForm

    Rick Reumann wrote:
    With this approach, most JSP pages could have a single Java class --
    a SimpleActionForm subclass that handles both validation and
    processing for the page:
    Well they certainly wouldn't have a 'single' java class, you
    would have
    a LOT of them.
    Sorry -- I meant a single Java class per JSP page, instead of _two_ Java
    classes (an Action and an ActionForm) per JSP page.
    I don't think you meant for that to be abstract. But notice you know
    have an execute in all your ActionForms? How is that different than
    simply the processing done in different Actions as Struts is now? All
    you've done is pushed down the processing to a different place..
    ActionForm vs Action.
    Yes -- it is supposed to be abstract -- each ActionForm subclass must
    define an execute() method to perform the processing for that form. You're
    right in saying that All I've done is push the processing to a different
    place -- but it's for the purpose of combining the Action and the
    ActionForm to reduce the number of separate Java classes needed for a
    typical Struts app, hopefully reducing complexity.
    If you like this approach definitely check out StrutsDialog.
    Thanks for the tip. I took a brief look, but I don't see how StrutsDialogs
    corresponds to what I'm suggesting. It appears to maintain a separation of
    Action and ActionForm, which I am proposing to combine.

    Stephen

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Rick Reumann at Jul 11, 2005 at 8:18 pm

    Schaub, Stephen wrote the following on 7/11/2005 3:56 PM:

    Yes -- it is supposed to be abstract -- each ActionForm subclass must
    define an execute() method to perform the processing for that form.
    (Right but in your example you were showing LoginAction as the
    implementing class and you still kept it abstract in the example-
    probaby just cut and paste errror no big deal)
    If you like this approach definitely check out StrutsDialog.

    Thanks for the tip. I took a brief look, but I don't see how
    StrutsDialogs corresponds to what I'm suggesting. It appears to
    maintain a separation of Action and ActionForm, which I am proposing
    to combine.
    Actually you might want to get with Michael, he has been talking about
    combining the ActionForm and Action together, and I too think that's the
    best approach to take if you plan to push the business logic into the
    ActionForm.

    --
    Rick

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Michael Jouravlev at Jul 11, 2005 at 8:29 pm

    On 7/11/05, Rick Reumann wrote:
    Ok, yes they'd have to extend that in order to utilize your processing
    in the ActionForm functionality. Bottom line is I think all you've done
    is move where you do the processing... you moved it from the Actions to
    the ActionForms. If you like this approach definitely check out
    StrutsDialog. (Sorry Michael, not trying to oversimplify all that your
    stuff does, I realize it's much more than processing in the ActionForm,
    but if he's going to do this he might as well stand on the shoulders of
    someone who has done all the work already:)
    On 7/11/05, Schaub, Stephen wrote:
    I took a brief look, but I don't see how StrutsDialogs corresponds to what I'm suggesting. It appears to maintain a separation of Action and ActionForm, which I am proposing to combine.
    First of all, to get it over with, Struts Dialogs has plans to combine
    Action and ActionForm but it is not there yet :)

    Second, the concept of Struts Dialogs is different. Stephen wants to
    have one class -> one page relation. JSF or ASP.NET is the way to go
    in this case. My library DOES NOT maintain one-to-one relations of
    Java class to a page. Quite contrary, the whole idea is to serve
    *different* pages from *one* location. And, if no other hi-tech stuff
    like mod-rewrite is used, it means to serve different pages from one
    action. This is NOT what Stephen wants.

    On the other hand, Stephen, why do you want to have one class per
    page? Page is not what you load by browser. You load a resource, which
    can potentially generate many different pages. This is much more
    flexible. Even MS is adding Front Controller to ASP.NET 2.0, realising
    limitations of Page Controller architecture, which it uses in current
    ASP.NET 1.1

    Think again, why exactly you want to address to a *page* istead of
    addressing to a *resource*.

    P.S. As Craig M. explained, one of the reasons of having one-to-one
    class->page relationship in JSF is the simplicity of this concept to
    [current and former] desktop app developers. But it does not
    necessarily mean that this concept is better, than Front Controller
    used in Struts.

    Michael.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Schaub, Stephen at Jul 11, 2005 at 8:11 pm

    Zarar Siddiqi wrote:

    I think the ideal that you're searching for is "one class per
    view". Take a look at JSF.
    That's correct. And I'm familiar with JSF -- but it's way too complicated for my needs. Plus Struts is dictated for this project...

    Stephen


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Schaub, Stephen at Jul 11, 2005 at 8:58 pm

    Michael Jouravlev wrote:

    First of all, to get it over with, Struts Dialogs has plans to combine
    Action and ActionForm but it is not there yet :)

    Second, the concept of Struts Dialogs is different. Stephen wants to
    have one class -> one page relation. JSF or ASP.NET is the way to go
    in this case. My library DOES NOT maintain one-to-one relations of
    Java class to a page. Quite contrary, the whole idea is to serve
    *different* pages from *one* location. And, if no other hi-tech stuff
    like mod-rewrite is used, it means to serve different pages from one
    action. This is NOT what Stephen wants.

    On the other hand, Stephen, why do you want to have one class per
    page?
    Because I don't want to have to have two classes per page. :)

    Let me clarify that I'm not arguing for one class per page: in fact, I don't mind having one class backing multiple pages. Just as Struts allows for one ActionForm that backs multiple JSP's, my approach allows for one SimpleActionForm that backs multiple JSP's. I've been working this afternoon on just such a use case.

    What I'm wanting is an explanation of why I should keep the ActionForm class _separate_ from the Action class. It seems to me that this unnecessarily complicates the application design.
    Page is not what you load by browser. You load a resource, which
    can potentially generate many different pages.
    I'm not sure I follow. Can you explain further with an example? I do want to understand.

    Thanks for your understanding and thoughtful response, Michael.

    Stephen

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Michael Jouravlev at Jul 11, 2005 at 9:33 pm

    On 7/11/05, Schaub, Stephen wrote:
    Michael Jouravlev wrote:
    On the other hand, Stephen, why do you want to have one class per
    page?
    Because I don't want to have to have two classes per page. :)
    you got me :) I wanted to ask, why would you want to have one *set of
    classes* for one page, but seems that is not what you want. You just
    want to combine Action and ActionForm which was my idea too.
    Let me clarify that I'm not arguing for one class per page:
    in fact, I don't mind having one class backing multiple pages.
    Just as Struts allows for one ActionForm that backs multiple JSP's,
    my approach allows for one SimpleActionForm that backs multiple
    JSP's. I've been working this afternoon on just such a use case.

    What I'm wanting is an explanation of why I should keep the
    ActionForm class _separate_ from the Action class. It seems to me
    that this unnecessarily complicates the application design.
    I wanted to combine these two classes as well, but I am not so sure
    now. Action class is stateless and can serve several requests, whereas
    action form either is instantiated for every request, or is stateful
    within a session, and has only one instance per session. Also, Struts
    is based on idea of subclassing, thus if you already subclassing
    something like ValidateForm, you cannot subclass another form, which
    you would want to because it has needed event handlers.

    So, these differences allow to mix and match and to combine. For
    example, I have a component which provides CRUD functionality (is it
    OK that I use my library as an example?).

    In this case the interface with browser is pretty much stable, it has
    create(), edit(), view(), delete() and of course render() methods. So,
    each particular project can reuse not only the protocol, but the
    implementation too. It is quite standard, it processes button events,
    it handles error messages, and it returns different mappings for
    different state of the ActionForm. This Action is totally reusable.

    On the other hand, every application has its own data which I don't
    know how to handle. So I have an interface for an action form, which I
    use from my standard action class. This interface defines what should
    be done with data for each input event, but it does not define how it
    should be done. You implement this interface in your ActionForm and go
    crazy with your data. I don't care what you do, just return back an
    error message and set status accordingly.

    What if it were a solid dispatching ActionForm as you suggest? In this
    case you would not be able to subclass other class like ValidateForm,
    because multiple inheritance does not exist in Java. At the same time
    your base ActionForm most likely would not have any functionality,
    because it depends on actual data. For UI interface, if you decide to
    add one event, it probably does not really matter, to use a separate
    action class for that, or to override all form classes... No firm
    opinion on that.

    Anyway, I agree that combining Action and ActionForm can be
    beneficial, but I would not want to *replace* current Struts
    Action/ActionForm combination with a solid ActionForm.
    Page is not what you load by browser. You load a resource, which
    can potentially generate many different pages.
    I'm not sure I follow. Can you explain further with an example?
    I do want to understand.
    Never mind, I wrote this because I thought that you wanted to "go to
    login.htm", "then go to homepage.htm" instead of "go to login
    location, which will display whatever page is proper for current
    application state". Because if you have stateful objects on the
    server, and you load a resource, you do not know what exact content
    you receive. It all depends on server state. But seems that this
    concept is clear to you, sorry for hitting into the open door ;)

    Michael.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Frank W. Zammetti at Jul 11, 2005 at 9:56 pm

    Schaub, Stephen wrote:
    What I'm wanting is an explanation of why I should keep the ActionForm class _separate_ from the Action class. It seems to me that this unnecessarily complicates the application design.
    When a Struts-based app is "properly" architected, the Actions are
    nothing more than traffic cops... they move data sent from the client
    along to some "business delegate" where the real work of the application
    happens. That is their only purpose in life, theoretically.

    The design that many people follow is that an ActionForm receives input
    from the client. The Action receives the form and uses BeanUtils (or
    similar) to copy the properties of the ActionForm into some other type
    of bean (DTO) that the business delegate knows how to handle. This is
    generally done with a single line of code (the copy I mean). Then the
    appropriate delgate is called, passed that bean, does its thing, and
    returns the bean (or a different one in some cases). The Action then
    copies that bean into the ActionForm, again with a single line of code,
    and forwards as appropriate. There might be some branching based on
    exceptions the delegate may throw, but in general this is how it flows.

    So we're talking about three lines of code per Action, in an ideal
    situation. But that's not the pertinent fact... the pertinent fact is
    that the Action doesn't know anything about what actually is in the
    ActionForm, and therefore what is in the view, nor does it know what the
    delegate does or anything about the bean it uses, or in other words, the
    model.

    So, let's imagine a situation where you want to add some fields that a
    user can enter on a given screen. No problem... you alter only your
    ActionForm (or just struts-config if your using DynaActionForm), and
    presumably the bean that gets passed to the delagate class as well. But
    the important point is that the Action is unchanged because it's only
    playing its role as a traffic cop and nothing else.

    By combining Actions and ActionForms, you are breaking the separation.
    There *IS* clearly benefit to doing so... cutting down class count is
    something I'm always in favor of, so long as line count doesn't increase
    as a result. But is it worth it?

    Clearly some now believe it is... as I understand it, that's one of the
    important concepts in JSF and ASP.Net, among others.

    I wonder, would you think there is benefit to combining the two over a
    declarative approach like DynaActionForm? Using them you cut the class
    count down similarly, and in fact *REDUCE* overall line count as well,
    and you gain a declarative approach to things, which is definitely nice
    (I seem to remember that's how JSF approaches things, but it has been a
    while since I looked, my memory may be fooling me).

    --
    Frank W. Zammetti
    Founder and Chief Software Architect
    Omnytex Technologies
    http://www.omnytex.com


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Craig McClanahan at Jul 12, 2005 at 1:49 am
    On 7/11/05, Frank W. Zammetti wrote:

    [snip]
    By combining Actions and ActionForms, you are breaking the separation.
    There *IS* clearly benefit to doing so... cutting down class count is
    something I'm always in favor of, so long as line count doesn't increase
    as a result. But is it worth it?
    I think of the state information represented by an ActionForm (in
    Struts 1.x) or potentially as properties of an "action" class (per the
    current discussion) to be part of the *view* tier. Further, I see the
    role of the execute method on an action as being an Adapter Pattern
    link between the web tier (HTTP-centric) and the model tier
    (HTTP-agnostic). Therefore, I don't feel any pain at the idea of
    combining the two together.

    The primary mistake to avoid is using an ActionForm as a VO passed to
    your persistence tier. This seems a little less likely when the same
    object has behavior as well as data, but you still need to watch out
    for this.
    Clearly some now believe it is... as I understand it, that's one of the
    important concepts in JSF and ASP.Net, among others.
    I wonder, would you think there is benefit to combining the two over a
    declarative approach like DynaActionForm? Using them you cut the class
    count down similarly, and in fact *REDUCE* overall line count as well,
    and you gain a declarative approach to things, which is definitely nice
    (I seem to remember that's how JSF approaches things, but it has been a
    while since I looked, my memory may be fooling me).
    That (combined "action form" and "action" concept) is indeed the
    recommended design pattern when using JSF, as well as with WebWork,
    which uses the same idea. Although it does reduce the total line
    count slightly, this is outweighed, IMHO, by other advantages:

    * The input values are available as instance variables in your
    "action" class, which makes coding accesses to those values
    a little simpler (foo instead of formBean.getFoo()).

    * Because of that, there's a little less per-request object creation
    going on (although you trade that off for the "action" class being
    instantiated per request, so it is almost a push).

    * At least in the JSF case, the component handles conversions
    for you, so "foo" can be an int if the value is supposed to be
    an integer. No more BeanUtils.copyProperties() calls.

    * The code becomes easier to unit test because your test case
    simply has to instantiate your "action" class, set the appropriate
    properties, and call the execute() method. Lots less to do
    setting up mock objects that simulate a servlet container.

    As I've said publicly on more than one occasion, if I'd thought of
    this approach (action class with properties for the request variables,
    instantiated per request) early enough, this is what Struts 1.0 would
    have done. Alas, by the time the value of this pattern became clear,
    backwards compatibility was an important issue, and we couldn't
    change.

    Craig

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Frank W. Zammetti at Jul 12, 2005 at 3:31 am

    Craig McClanahan wrote:
    I think of the state information represented by an ActionForm (in
    Struts 1.x) or potentially as properties of an "action" class (per the
    current discussion) to be part of the *view* tier. Further, I see the
    role of the execute method on an action as being an Adapter Pattern
    link between the web tier (HTTP-centric) and the model tier
    (HTTP-agnostic). Therefore, I don't feel any pain at the idea of
    combining the two together.
    It sounds like what your saying is that there really is no need for a
    control layer, we're coming down to view-adapter-model now. Am I
    understanding that correctly?

    I absolutely agree that the ActionForm, or properties of Action, is
    indeed part of the view. And, as per your next paragraph, I absolutely
    agree we shouldn't be passing that state information, in either form,
    directly to the model.

    So, in my mind, if we are talking about a single class that has
    properties of the view layer, as well as an adapter to the model in
    execute() (which we may or may not still call the control layer I
    suppose), that feels like co-mingling two tiers, something we have
    always convinced ourselves is a bad idea.

    Further, what would stop something from stretching a bit further and
    saying that DTOs from the control to the model should be in the form of
    maybe an inner class in the Action, further co-mingling in the model
    tier, arguably?

    I'd be very interested to understand why, assuming my interpretation is
    correct to begin with, we should start to think differently now about
    the mixing of parts of various layers in a single entity. I don't ask
    to be confrontational at all by the way, but its an interesting
    discussion to me.
    The primary mistake to avoid is using an ActionForm as a VO passed to
    your persistence tier. This seems a little less likely when the same
    object has behavior as well as data, but you still need to watch out
    for this.
    Agreed, that is indeed the real problem to avoid in the end. How best
    to accomplish it might be debatable, but I think we all agree this is
    the gotcha to avoid :)
    That (combined "action form" and "action" concept) is indeed the
    recommended design pattern when using JSF, as well as with WebWork,
    which uses the same idea. Although it does reduce the total line
    count slightly, this is outweighed, IMHO, by other advantages:

    * The input values are available as instance variables in your
    "action" class, which makes coding accesses to those values
    a little simpler (foo instead of formBean.getFoo()).
    That is one benefit I definitely like as well. Although it has never
    caused me personally any major heartache that you can't do this with
    Struts, I have seen instances where it would have made life a little
    simpler.
    * Because of that, there's a little less per-request object creation
    going on (although you trade that off for the "action" class being
    instantiated per request, so it is almost a push).
    I've always wondered about how big a help it is to not be instantiating
    Actions per-request (although I suppose I haven't wondered it enough to
    do any benchmarks myself :) ). It always seemed perfectly reasonable
    that it was a benefit, I've never doubted it was, but I've always
    wondered if it was truly worth the trade-offs.
    * The code becomes easier to unit test because your test case
    simply has to instantiate your "action" class, set the appropriate
    properties, and call the execute() method. Lots less to do
    setting up mock objects that simulate a servlet container.
    Indeed, that is a nice benefit.
    As I've said publicly on more than one occasion, if I'd thought of
    this approach (action class with properties for the request variables,
    instantiated per request) early enough, this is what Struts 1.0 would
    have done. Alas, by the time the value of this pattern became clear,
    backwards compatibility was an important issue, and we couldn't
    change.
    Eh, live and learn. No one gets it right every time out :) And it
    isn't like you got anything *wrong* per se anyway, you figured out
    something better later on. The developer that has never had a
    revelation after the fact is a better developer than any of us for sure!

    Frank


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Craig McClanahan at Jul 12, 2005 at 3:58 am

    On 7/11/05, Frank W. Zammetti wrote:
    Craig McClanahan wrote:
    I think of the state information represented by an ActionForm (in
    Struts 1.x) or potentially as properties of an "action" class (per the
    current discussion) to be part of the *view* tier. Further, I see the
    role of the execute method on an action as being an Adapter Pattern
    link between the web tier (HTTP-centric) and the model tier
    (HTTP-agnostic). Therefore, I don't feel any pain at the idea of
    combining the two together.
    It sounds like what your saying is that there really is no need for a
    control layer, we're coming down to view-adapter-model now. Am I
    understanding that correctly?
    Not completely, but amost.

    There are reasons to have an "application scoped" front controller.
    There are reasons to have a "view-scoped" front controller. There is
    *no* reason I am aware of that requires these controllers to be the
    same :-).

    In Shale, the application-scoped functions are performed by a Commons
    Chain pipeline that is configured and processed by Shale's filter.
    This is the right place to put things like "if the user isn't logged
    on, redirect to the login page" and "log every request" type
    functions. But it is not the right place for "execute this expensive
    SQL query, but *only* if I am the view that needs it.".

    In Struts 1.x, you get around the latter case, typically, by having a
    setup action before the view, and a process action after the view.
    Shale simply combines those two bits of code into a single class (and,
    along the way, combining the form bean too), resulting in a little
    less code, but a lot fewer classes.
    I absolutely agree that the ActionForm, or properties of Action, is
    indeed part of the view. And, as per your next paragraph, I absolutely
    agree we shouldn't be passing that state information, in either form,
    directly to the model.

    So, in my mind, if we are talking about a single class that has
    properties of the view layer, as well as an adapter to the model in
    execute() (which we may or may not still call the control layer I
    suppose), that feels like co-mingling two tiers, something we have
    always convinced ourselves is a bad idea.
    See above.
    Further, what would stop something from stretching a bit further and
    saying that DTOs from the control to the model should be in the form of
    maybe an inner class in the Action, further co-mingling in the model
    tier, arguably?
    People do that with form beans already, so we clearly haven't
    succeeded in communicating the correct pattern :-). But, if you do
    the right thing in Struts 1.x, you already have zero model tier code,
    or business logic, in your actions -- they are already performing the
    adapter role.
    I'd be very interested to understand why, assuming my interpretation is
    correct to begin with, we should start to think differently now about
    the mixing of parts of various layers in a single entity. I don't ask
    to be confrontational at all by the way, but its an interesting
    discussion to me.
    It's not about mixing layers. It is about mixing all the parts of the
    *same* tier (view) related to a particular page into a single class,
    instead of three classes (setup action, form bean, and process
    action). The adapter has to be somewhere no matter what; co-hosting
    it in a single class turns out to have benefits in terms of simplicity
    and unit testability.

    WebWork and JSF got this one right.
    The primary mistake to avoid is using an ActionForm as a VO passed to
    your persistence tier. This seems a little less likely when the same
    object has behavior as well as data, but you still need to watch out
    for this.
    Agreed, that is indeed the real problem to avoid in the end. How best
    to accomplish it might be debatable, but I think we all agree this is
    the gotcha to avoid :)
    That (combined "action form" and "action" concept) is indeed the
    recommended design pattern when using JSF, as well as with WebWork,
    which uses the same idea. Although it does reduce the total line
    count slightly, this is outweighed, IMHO, by other advantages:

    * The input values are available as instance variables in your
    "action" class, which makes coding accesses to those values
    a little simpler (foo instead of formBean.getFoo()).
    That is one benefit I definitely like as well. Although it has never
    caused me personally any major heartache that you can't do this with
    Struts, I have seen instances where it would have made life a little
    simpler.
    * Because of that, there's a little less per-request object creation
    going on (although you trade that off for the "action" class being
    instantiated per request, so it is almost a push).
    I've always wondered about how big a help it is to not be instantiating
    Actions per-request (although I suppose I haven't wondered it enough to
    do any benchmarks myself :) ). It always seemed perfectly reasonable
    that it was a benefit, I've never doubted it was, but I've always
    wondered if it was truly worth the trade-offs.
    In 1.1 and 1.2 JDKs (i.e. when Struts was invented), this mattered a
    *lot*. In 1.4 JDKs, it basically doesn't matter unless you have
    *huge* request volumes. Thus, the reasons for most people to not put
    their adapters in request scope is basically gone.
    * The code becomes easier to unit test because your test case
    simply has to instantiate your "action" class, set the appropriate
    properties, and call the execute() method. Lots less to do
    setting up mock objects that simulate a servlet container.
    Indeed, that is a nice benefit.
    As I've said publicly on more than one occasion, if I'd thought of
    this approach (action class with properties for the request variables,
    instantiated per request) early enough, this is what Struts 1.0 would
    have done. Alas, by the time the value of this pattern became clear,
    backwards compatibility was an important issue, and we couldn't
    change.
    Eh, live and learn. No one gets it right every time out :) And it
    isn't like you got anything *wrong* per se anyway, you figured out
    something better later on. The developer that has never had a
    revelation after the fact is a better developer than any of us for sure!
    Just remember ... the lifetime of Struts 1.x (five years since initial
    conception, four years since 1.0) is basically a geologic era in terms
    of Internet time :-).
    Frank
    Craig

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Frank W. Zammetti at Jul 12, 2005 at 4:26 am

    Craig McClanahan wrote:
    There are reasons to have an "application scoped" front controller.
    There are reasons to have a "view-scoped" front controller. There is
    *no* reason I am aware of that requires these controllers to be the
    same :-).
    Good point. In fact, I don't think it would take much to convince me
    that it's better if they ARE NOT the same :)
    In Shale, the application-scoped functions are performed by a Commons
    Chain pipeline that is configured and processed by Shale's filter.
    This is the right place to put things like "if the user isn't logged
    on, redirect to the login page" and "log every request" type
    functions. But it is not the right place for "execute this expensive
    SQL query, but *only* if I am the view that needs it.".
    This sounds very much like the types of things I would typically do in a
    filter. I'm a fan of filters because it's one less piece of the
    puzzle that doesn't tie me to a particular framework (I've done some
    converting of apps from one framework to another, so I always keep the
    possibility in mind as much as possible).

    Is there a benefit to the Chain approach over filters?
    In Struts 1.x, you get around the latter case, typically, by having a
    setup action before the view, and a process action after the view.
    Shale simply combines those two bits of code into a single class (and,
    along the way, combining the form bean too), resulting in a little
    less code, but a lot fewer classes.
    I think I just realized why I'm not completely excited by this... I've
    never been a fan of DispatchAction, and while I understand it isn't
    exactly analogous, it is along the same lines.

    You couldn't know just how ironic me saying that is, but trust me, it is
    :) Probably 6 or 7 years back I had some rather heated debates with
    some coworkers where I was trying to convince them it was better to have
    a single class with a switch block than a couple of individual classes
    (this was before frameworks were en vogue, so we were talking servlet
    design). I've done a complete 180 on that, to the point where I,
    generally, won't use DispatchAction.

    It was, until now when I realized it, giving me a subconscious dislike
    of anything along those lines :)
    People do that with form beans already, so we clearly haven't
    succeeded in communicating the correct pattern :-).
    Agreed. And I for one cannot claim to have always gotten it right either :)
    It's not about mixing layers. It is about mixing all the parts of the
    *same* tier (view) related to a particular page into a single class,
    instead of three classes (setup action, form bean, and process
    action). The adapter has to be somewhere no matter what; co-hosting
    it in a single class turns out to have benefits in terms of simplicity
    and unit testability.
    While I agree on the unit testability point, I'm not completely sold on
    the simplicity argument... there's always a fine line between how much
    actual code there is and how big the object hierarchy is. Go too far
    either way and its complex, just in different ways. Again, I've changed
    my opinion on this, but I now feel that a larger number of classes,
    assuming each has a clearly defined role to play, is easier to digest
    than a single class with all the code, or perhaps even a little more
    code, in it. Again, there is a bit of a fine line there because if
    there are too many classes, no matter how simple, it becomes difficult
    to see how they all fit together.
    In 1.1 and 1.2 JDKs (i.e. when Struts was invented), this mattered a
    *lot*. In 1.4 JDKs, it basically doesn't matter unless you have
    *huge* request volumes. Thus, the reasons for most people to not put
    their adapters in request scope is basically gone.
    That's good info, thanks! :)

    I wonder, and I'm not the first one I'm sure, what would it take to make
    Struts work that way now? More importantly, what would the consequences
    be? It seems like it could be done in a completely backwards-compatible
    way, at least at first pass through my brain.
    Just remember ... the lifetime of Struts 1.x (five years since initial
    conception, four years since 1.0) is basically a geologic era in terms
    of Internet time :-).
    Absolutely! You must have gotten *something* right for Struts to have
    this kind of staying power :) I can think of many things that seemed
    like the greatest thing since sliced bread at the time that wound up
    fading into obscurity in half that time.

    Frank


    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Craig McClanahan at Jul 12, 2005 at 5:46 am

    On 7/11/05, Frank W. Zammetti wrote:
    Craig McClanahan wrote:
    There are reasons to have an "application scoped" front controller.
    There are reasons to have a "view-scoped" front controller. There is
    *no* reason I am aware of that requires these controllers to be the
    same :-).
    Good point. In fact, I don't think it would take much to convince me
    that it's better if they ARE NOT the same :)
    In Shale, the application-scoped functions are performed by a Commons
    Chain pipeline that is configured and processed by Shale's filter.
    This is the right place to put things like "if the user isn't logged
    on, redirect to the login page" and "log every request" type
    functions. But it is not the right place for "execute this expensive
    SQL query, but *only* if I am the view that needs it.".
    This sounds very much like the types of things I would typically do in a
    filter. I'm a fan of filters because it's one less piece of the
    puzzle that doesn't tie me to a particular framework (I've done some
    converting of apps from one framework to another, so I always keep the
    possibility in mind as much as possible).

    Is there a benefit to the Chain approach over filters?
    In this case, the only purpose of the Shale application filter is to
    execute a Chain that is applied to all requests. So have it your way
    :-).

    Seriously, the reason for that choice was to reduce the amount of
    effort needed to add a particular piece of application scope logic.
    It's a lot easier for a newbie to implement a Command, and then add it
    to a configured chain, without having to understand the whole
    processing flow of a Filter. The only tricky bit is whether to return
    true or false from the execute() method :-).

    On the other hand, use of the Shale application filter does *not*
    preclude you from using other technologies (like securityfilter) that
    are also based on filters. One of the key lessons I've learned is
    that frameworks should be fine grained, not monolithic ... make it
    *easy* for your users to incorporate additional capabilities. Filters
    are a huge enabling technology that are free for the taking if you
    assume a Servlet 2.3 or later baseline (as Shale does, but as Struts
    1.x has not as yet). So, if you like filters, go for it ... they'll
    work fine in a Shale environment.
    In Struts 1.x, you get around the latter case, typically, by having a
    setup action before the view, and a process action after the view.
    Shale simply combines those two bits of code into a single class (and,
    along the way, combining the form bean too), resulting in a little
    less code, but a lot fewer classes.
    I think I just realized why I'm not completely excited by this... I've
    never been a fan of DispatchAction, and while I understand it isn't
    exactly analogous, it is along the same lines.

    You couldn't know just how ironic me saying that is, but trust me, it is
    :) Probably 6 or 7 years back I had some rather heated debates with
    some coworkers where I was trying to convince them it was better to have
    a single class with a switch block than a couple of individual classes
    (this was before frameworks were en vogue, so we were talking servlet
    design). I've done a complete 180 on that, to the point where I,
    generally, won't use DispatchAction.

    It was, until now when I realized it, giving me a subconscious dislike
    of anything along those lines :)
    The JSF recommended pattern actually lets you do "dispatch action"
    sorts of things, but a bit more easily :-). The key is that you can
    bind different submit buttons to different execution methods ("action"
    methods in JSF terminology) -- and those methods can either be in the
    same class or in different classes. Both have nice advantages:

    * If you have a search widget on every page of your app, you can
    bind all of them to a single common action that performs the search.
    Coupled with outcome-based navigation, the developer implementing
    the search functionality doesn't have to care anything about navigation --
    his or her only job is to report back on what happened (for a search
    widget, typical results would be "no matches", "one match", or "multiple
    matches" ... which the application architect can map to a single view,
    two views, or three views at his or her whim -- *without* changing any code.

    * If you have, say, an "Update" button at both the top and the bottom
    of a long table, you can bind them to the same action, since you want
    exactly the same behavior -- you are only providing two ways to invoke
    it as a convenience to the user (GMail users will instantly recognize this
    as the paradigm that is used for the "Newer" and "Older" buttons in the
    index view).
    People do that with form beans already, so we clearly haven't
    succeeded in communicating the correct pattern :-).
    Agreed. And I for one cannot claim to have always gotten it right either :)
    It's not about mixing layers. It is about mixing all the parts of the
    *same* tier (view) related to a particular page into a single class,
    instead of three classes (setup action, form bean, and process
    action). The adapter has to be somewhere no matter what; co-hosting
    it in a single class turns out to have benefits in terms of simplicity
    and unit testability.
    While I agree on the unit testability point, I'm not completely sold on
    the simplicity argument... there's always a fine line between how much
    actual code there is and how big the object hierarchy is. Go too far
    either way and its complex, just in different ways. Again, I've changed
    my opinion on this, but I now feel that a larger number of classes,
    assuming each has a clearly defined role to play, is easier to digest
    than a single class with all the code, or perhaps even a little more
    code, in it. Again, there is a bit of a fine line there because if
    there are too many classes, no matter how simple, it becomes difficult
    to see how they all fit together.
    Don't assume that the entire user population knows, or even *wants* to
    know, what an "object" is. It would be a disservice for the Java
    platform as a whole to sneer at such people -- instead, we should
    embrace them. The more Java people there are, the more folks will buy
    our Java related products (and the more places we can go get jobs if
    we get tired of our current situation :-).
    In 1.1 and 1.2 JDKs (i.e. when Struts was invented), this mattered a
    *lot*. In 1.4 JDKs, it basically doesn't matter unless you have
    *huge* request volumes. Thus, the reasons for most people to not put
    their adapters in request scope is basically gone.
    That's good info, thanks! :)

    I wonder, and I'm not the first one I'm sure, what would it take to make
    Struts work that way now? More importantly, what would the consequences
    be? It seems like it could be done in a completely backwards-compatible
    way, at least at first pass through my brain.
    In today's world, if you are doing *new* development, the choices are
    actually pretty harsh:

    * If you want the Action+ActionForm paradigm by itself, adopt WebWork.
    They got a bunch of the other stuff right already; it's not worth reinventing
    in 2005.

    * If you like component oriented architectures, pick JSF (if you like
    mainstream)
    or Tapestry (if you like the edge). In either case, it's not worth
    reinventing
    in 2005 ... or competing with a JCP standard technology that has achieved
    (in its 16 months since 1.0 release, pretty much the same communty
    infrastructure
    support -- books, tutorials, consultants, etc. -- that Struts 1.x
    currently enjoys).

    Can you tell I'm not personally sold on trying to retrofit Struts 1.x
    to match today's patterns? That doesn't mean it should not be done,
    or that it's a bad idea ... it just means that I have no energy to
    invest in that direction. It's time for a clean break (not unlike the
    changes from Apache HTTPD 1.3->2.0, or Tomcat 3.x->4.x, where
    completely different architectures were inserted to leverage the most
    recent best practices).

    (By the way, I'm now quite happy that I didn't waste time trying to
    learn how to build Maven 1.x build environments, since Maven 2.x
    basically throws that stuff away :-).
    Just remember ... the lifetime of Struts 1.x (five years since initial
    conception, four years since 1.0) is basically a geologic era in terms
    of Internet time :-).
    Absolutely! You must have gotten *something* right for Struts to have
    this kind of staying power :) I can think of many things that seemed
    like the greatest thing since sliced bread at the time that wound up
    fading into obscurity in half that time.
    Of course, the above advice is primarily for folks doing new
    development -- people with existing investments in Struts 1.x should,
    of course, be aware that their investment is being protected by
    ongoing development on 1.2 (then) and 1.3 (now). That will continue
    as long as there is a need for improved capabilities.

    But that's not where the future of web tier development in Java lies,
    IMHO. After five years of creating the de facto standard, it's
    definitely time for me to leverage five years of lessons and do it all
    over again. But this time, founded on a JCP standard technology so I
    don't have to argue with anyone about adopting some wildcat open
    source project for their mission critical application architecture
    :-).
    Frank
    Craig

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Yaroslav Novytskyy at Jul 13, 2005 at 10:49 am
    Hello!

    Craig McClanahan wrote:
    On 7/11/05, Frank W. Zammetti wrote:

    Craig McClanahan wrote:
    I think of the state information represented by an ActionForm (in
    Struts 1.x) or potentially as properties of an "action" class (per the
    current discussion) to be part of the *view* tier. Further, I see the
    role of the execute method on an action as being an Adapter Pattern
    link between the web tier (HTTP-centric) and the model tier
    (HTTP-agnostic). Therefore, I don't feel any pain at the idea of
    combining the two together.
    It sounds like what your saying is that there really is no need for a
    control layer, we're coming down to view-adapter-model now. Am I
    understanding that correctly?

    Not completely, but amost.

    There are reasons to have an "application scoped" front controller.
    There are reasons to have a "view-scoped" front controller. There is
    *no* reason I am aware of that requires these controllers to be the
    same :-).
    (The question is below but here I only wonder: what is a "view-scoped"
    front controller? :) what are the differences between a "view-scoped"
    and an "application-scoped" (a "normal" one as I can guess) front
    controller?)
    In Shale, the application-scoped functions are performed by a Commons
    Chain pipeline that is configured and processed by Shale's filter.
    This is the right place to put things like "if the user isn't logged
    on, redirect to the login page" and "log every request" type
    functions. But it is not the right place for "execute this expensive
    SQL query, but *only* if I am the view that needs it.".

    In Struts 1.x, you get around the latter case, typically, by having a
    setup action before the view, and a process action after the view.
    Shale simply combines those two bits of code into a single class (and,
    along the way, combining the form bean too), resulting in a little
    less code, but a lot fewer classes.
    In Struts 1.x I do use setupAction->jsp->processAction technique and was
    thinking all the time how can I put together the setupAction and
    processAction into one class. The best way I could think of was to make
    a "downgraded" DispatchAction, that dispatches based on mapping's
    parameter (in the latest version of Struts just the same thing appeared
    named MappingDispatchAction) and to put both setup and precess
    actions-methods into one class.

    (p.s. this technique made it also possible to automate token-based
    protection - every prepare calls saveToken and before every process
    token is checked)

    So please tell, in what way does Shale do this?
    Should I pay more attention to shale? Is it ready to try it out on some
    small test projects?


    Yaroslav Novytskyy

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Craig McClanahan at Jul 13, 2005 at 4:53 pm

    On 7/13/05, Yaroslav Novytskyy wrote:
    Hello!

    Craig McClanahan wrote:
    On 7/11/05, Frank W. Zammetti wrote:

    Craig McClanahan wrote:
    I think of the state information represented by an ActionForm (in
    Struts 1.x) or potentially as properties of an "action" class (per the
    current discussion) to be part of the *view* tier. Further, I see the
    role of the execute method on an action as being an Adapter Pattern
    link between the web tier (HTTP-centric) and the model tier
    (HTTP-agnostic). Therefore, I don't feel any pain at the idea of
    combining the two together.
    It sounds like what your saying is that there really is no need for a
    control layer, we're coming down to view-adapter-model now. Am I
    understanding that correctly?

    Not completely, but amost.

    There are reasons to have an "application scoped" front controller.
    There are reasons to have a "view-scoped" front controller. There is
    *no* reason I am aware of that requires these controllers to be the
    same :-).
    (The question is below but here I only wonder: what is a "view-scoped"
    front controller? :) what are the differences between a "view-scoped"
    and an "application-scoped" (a "normal" one as I can guess) front
    controller?)
    In design pattern terms, it's actually the View Helper pattern more
    than it really is a view scoped front controller. But the key
    differences are:

    FRONT CONTROLLER
    - Typically an application-level singleton
    - Processes every request
    - Enforces global architectural issues (has the user logged in?
    perform validations before application actions. ...)
    - Manages navigation between views

    VIEW HELPER:
    - Typically one instance per view
    - Processes only requests for that view
    - Assists the view in performing its rendering (go execute
    the JDBC select or Hibernate query needed for rendering
    a table, and clean up afterwards).
    - Does not manage navigation, but provides logical
    outcomes that influence the navigation performed
    by the front controller
    In Shale, the application-scoped functions are performed by a Commons
    Chain pipeline that is configured and processed by Shale's filter.
    This is the right place to put things like "if the user isn't logged
    on, redirect to the login page" and "log every request" type
    functions. But it is not the right place for "execute this expensive
    SQL query, but *only* if I am the view that needs it.".

    In Struts 1.x, you get around the latter case, typically, by having a
    setup action before the view, and a process action after the view.
    Shale simply combines those two bits of code into a single class (and,
    along the way, combining the form bean too), resulting in a little
    less code, but a lot fewer classes.
    In Struts 1.x I do use setupAction->jsp->processAction technique and was
    thinking all the time how can I put together the setupAction and
    processAction into one class. The best way I could think of was to make
    a "downgraded" DispatchAction, that dispatches based on mapping's
    parameter (in the latest version of Struts just the same thing appeared
    named MappingDispatchAction) and to put both setup and precess
    actions-methods into one class.

    (p.s. this technique made it also possible to automate token-based
    protection - every prepare calls saveToken and before every process
    token is checked)

    So please tell, in what way does Shale do this?
    Shale provides four application level events in your backing bean
    (optionally -- you don't *have* to leverage this, but you'll get the
    service if you implement the ViewController interface):

    * init() -- The view you are associated with is going to be involved
    in the current request (either you are about to process a postback
    or about to process a render), so gather any resources you need
    to get ready for either.

    * preprocess() -- Your view is about to process a form submit,
    so get set up. For example, you might need to go lock a database
    row, or acquire references to some business logic options.

    * prerender() -- Your view is about to be rendered, so go collect the
    data that will be needed (this is used for the sort of stuff a setup
    action typically does in a struts app).

    * destroy() -- The framework guarantees to call this *after* rendering
    so you can clean up any allocated resources. For example, you
    might have executed a JDBC query in prerender() to provide the data
    for a table; here is where you would close it and release the
    database resources. (This is something Struts doesn't support
    directly; you have to mess around with a filter or something like that).

    Should I pay more attention to shale? Is it ready to try it out on some
    small test projects?
    I would definitely suggest paying attention :-). If you're
    investigating the JSF route, JSF+Shale is a good combination.

    Yaroslav Novytskyy
    Craig

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Ted Husted at Jul 14, 2005 at 11:07 am

    On 7/11/05, Craig McClanahan wrote:
    Just remember ... the lifetime of Struts 1.x (five years since initial
    conception, four years since 1.0) is basically a geologic era in terms
    of Internet time :-).
    Ahh, but time is an illusion, and Internet time doubly so :)

    It seems to me that a lot of us are still solving the same problems we
    had five years ago with the same applications we wrote five years ago.
    Struts promised us applications that would be easier to maintain than
    rewrite, and, boy, has it delivered.

    Of course, over the last five years, we've managed to make Struts
    applications even easier to write and maintain, with features like
    declarative validation and exception handling, Tiles, JAAS support,
    modules, multiple configurations, Wildcard mappings, BSF Scripting,
    Workflow, DynaActionForms, LazyDynaActionForms, and even instant
    DynaActionForms (FormDef) -- to name a few :)

    We still don't have "UI components", but Struts works fine with
    coolness gizmos like DisplayTags and Layout. Of course, Struts plays
    nice with other great tools, like SecurityFilter and SiteMesh. And
    while Struts is harder to test than we would like, libraries like
    Struts TestCase and Web Canoo lighten the load.

    Most recently, just as Microsoft starting to think about Ajax support,

    * http://weblogs.asp.net/scottgu/archive/2005/06/28/416185.aspx

    members of the Struts community are delivering Ajax support.

    * http://javawebparts.sourceforge.net/

    It is disappointing that Struts 1.3.x has stalled again -- since there
    is some real innovation under that hood. But at least we are within
    spitting distance. Eventually, I'm sure someone will be able to spare
    a few days to push it out the door.

    -Ted.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Michael Jouravlev at Jul 12, 2005 at 6:16 am

    On 7/11/05, Craig McClanahan wrote:
    I think of the state information represented by an ActionForm (in
    Struts 1.x) or potentially as properties of an "action" class (per the
    current discussion) to be part of the *view* tier. Further, I see the
    role of the execute method on an action as being an Adapter Pattern
    link between the web tier (HTTP-centric) and the model tier
    (HTTP-agnostic). Therefore, I don't feel any pain at the idea of
    combining the two together.

    The primary mistake to avoid is using an ActionForm as a VO passed to
    your persistence tier. This seems a little less likely when the same
    object has behavior as well as data, but you still need to watch out
    for this.
    Very few had the idea of passing ActionForm as VO to persistence
    layer. This is some kind of backwards MVC. Contrary, the idea was to
    use BOs in ActionForm with session scope, thus making it a stateful
    interactive business object.

    I am not sold on the idea that presentation should have state. Why?
    Presentation presents. Business objects have data and state. If I
    aggregate BO into view, I do not break classic MVC design. Instead, I
    gain in terms that I have my data in one place instead of two places.
    This is classic database rule: if you can have data in one place, have
    it there. This saves from discrepancies and is easier to maintain, to
    understand and to follow the relationships.

    Treeviews may contain business data, or may not, so I see value of
    having things like treeviews in view layer. Comboboxes are usually not
    a business data, busines data is only one value from this combobox.
    Regular data that comes from database and edited by user, is busines
    data, and it is much easier to pull it from a real BO and to display
    it.
    The JSF recommended pattern actually lets you do "dispatch action"
    sorts of things, but a bit more easily :-).
    JSF isolates business data from widgetse even further. Also, JSF is
    not advertised as framework where a resource returns different views.
    Instead, it is advertised as Page Controller, which works well for
    former desktop programmers, but does not fit HTTP ideology. Not that
    it is not possible to emulate Front Controller in JSF, but it takes
    some tricks for that.

    Same goes for ASP.NET - easy to develop, clumsy to use. Of course,
    Microsoft provided option to not use _viewstate, but everybody uses
    it, because it is used in sample code and is considered standard. I am
    glad that JSF stores viewstate on server by default, this is much
    better.

    Michael.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Craig McClanahan at Jul 12, 2005 at 6:34 am

    On 7/11/05, Michael Jouravlev wrote:

    Very few had the idea of passing ActionForm as VO to persistence
    layer. This is some kind of backwards MVC. Contrary, the idea was to
    use BOs in ActionForm with session scope, thus making it a stateful
    interactive business object.
    Haven't been around the Struts mailing list for five years, have you? :-)
    I am not sold on the idea that presentation should have state. Why?
    Presentation presents. Business objects have data and state. If I
    aggregate BO into view, I do not break classic MVC design. Instead, I
    gain in terms that I have my data in one place instead of two places.
    This is classic database rule: if you can have data in one place, have
    it there. This saves from discrepancies and is easier to maintain, to
    understand and to follow the relationships.
    I'll give you one trivial example where view state matters ... lots of
    applications have a way to select the language in which the user
    wishes to interact, which should also affect things like date and
    currency formats. It is ridiculous for the application developer to
    have to manually set such a property on every request ... that's what
    frameworks do (and, to their credit, frameworks like Struts and JSF
    deal with this quite nicely). But it is a *view* tier piece of state,
    and has nothing to do with the model tier.

    There are other examples (which columns in a table are you sorting on?
    Have you applied any filters? Is this tree node expanded or
    collapsed?) but the point is clear ... there is indeed such a thing as
    view tier state that is totally independent of model tier state.
    Treeviews may contain business data, or may not, so I see value of
    having things like treeviews in view layer. Comboboxes are usually not
    a business data, busines data is only one value from this combobox.
    Regular data that comes from database and edited by user, is busines
    data, and it is much easier to pull it from a real BO and to display
    it.
    So, are you saying that a tree view should *not* remember which nodes
    are opened and closed?
    The JSF recommended pattern actually lets you do "dispatch action"
    sorts of things, but a bit more easily :-).
    JSF isolates business data from widgetse even further. Also, JSF is
    not advertised as framework where a resource returns different views.
    Instead, it is advertised as Page Controller, which works well for
    former desktop programmers, but does not fit HTTP ideology. Not that
    it is not possible to emulate Front Controller in JSF, but it takes
    some tricks for that.

    Same goes for ASP.NET - easy to develop, clumsy to use. Of course,
    Microsoft provided option to not use _viewstate, but everybody uses
    it, because it is used in sample code and is considered standard. I am
    glad that JSF stores viewstate on server by default, this is much
    better.
    Why should *JSF* be required to play the front controller role you
    describe, when the servlet API provides clearly adequate features if
    that is what you want to do? That suggestion reminds me of one of my
    first exposures to "frameworks" a couple decades ago ... Microsoft's
    MFC framework for writing Windows apps. If you could craft your
    requirements in terms of the APIs that MFC provided, you were going to
    be OK ... but woe be you if you wanted to go outside the framework!

    Modern frameworks should be fine grained and composable ... combine
    the pieces you need in order to accomplish your application
    requirements. You, as an application developer, should *not* be
    forced into "my way or the highway" decisions simply because the
    developers of your framework did not anticipate your particular use
    case.

    After all, why would anyone care about formalized "dispatch actions"
    in a Struts environment? You know the answer ... the basic framework
    doesn't know how to deal with the complexities of this use case.
    You've found a nice answer, but it's constrained by trying to be
    compatible with Struts 1.x. That's a *perfectly* reasonable goal, if
    that is what you are after -- that's just not where I am now.

    Where I am, it's a much simpler problem if you remove that constraint.
    The exact same design principles can be expressed much more elegantly
    if you don't need to worry about implementing Action or ActionForm.
    Michael.
    Craig

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Schaub, Stephen at Jul 12, 2005 at 1:29 pm

    Michael Jouravlev wrote:

    Also, Struts
    is based on idea of subclassing, thus if you already subclassing
    something like ValidateForm, you cannot subclass another form, which
    you would want to because it has needed event handlers.
    Good point.
    What if it were a solid dispatching ActionForm as you suggest? In this
    case you would not be able to subclass other class like ValidateForm,
    because multiple inheritance does not exist in Java. At the same time
    your base ActionForm most likely would not have any functionality,
    because it depends on actual data. For UI interface, if you decide to
    add one event, it probably does not really matter, to use a separate
    action class for that, or to override all form classes... No firm
    opinion on that.

    Anyway, I agree that combining Action and ActionForm can be
    beneficial, but I would not want to *replace* current Struts
    Action/ActionForm combination with a solid ActionForm.
    True. I'm not proposing changing the Struts API. I'm just forced to use it on a project, and am looking for a way to simplify the development.

    Thanks for the feedback -- this has been a most interesting thread.

    Stephen

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Schaub, Stephen at Jul 15, 2005 at 12:46 pm

    -----Original Message-----
    From: Ted Husted
    Sent: Wednesday, July 13, 2005 3:22 PM
    To: Struts Users Mailing List
    Subject: Re: Putting execute() in ActionForm

    [snip]

    If I were to use this strategy, I'd select the parameters to the
    Execute signature with care. There may not be any reason to pass the
    HTTP parameters out of the call, and there may be a reason to pass
    the Action. I would just be careful of using the parameters from the
    Struts Execute signature, unless my code actually needed those
    parameters..
    I have found that I do need the Action available to the ActionForm's execute method, because the Action class contains several important utility methods (like saveErrors(), etc.) that need to be available to the ActionForm's execute method.

    Further, since there is a separate ActionForm instance for each thread, I've considered adding the ActionMapping and HttpServletRequest as instance variables on the ActionForm, which are populated by the Action method before invoking ActionForm.execute():

    public class SimpleAction extends Action {
    public ActionForward execute(ActionMapping mapping, ActionForm form,
    HttpServletRequest request, HttpServletResponse response)
    throws Exception {
    SimpleActionForm bean = (SimpleActionForm) form;
    bean.init(this, mapping, request);
    return bean.execute();
    }
    }

    I realize this would not be a safe approach if there are situations where a SimpleActionForm could have multiple threads running through it. I've seen references to situations where session-scoped ActionForms can be accessed concurrently by multiple requests. However, I can't think of any common situations where that could occur -- at least, not in the sort of applications I'm writing. And, of course it would never occur with request-scoped ActionForms.
    I also wouldn't hestitate to put some "traffic cop" code into the base
    Action as needed, so that the ActionForm execute can focus on what it
    needs to do, rather than what the application needs to do.

    I'd also consider using a base ActionForm with all the properties my
    application needs, which I could then extend with execute and validate
    methods, as needed.

    Though, I'd probably use a DynaActionForm instead of a conventional
    ActionForm as the base class, just for the agility.
    These suggestions make sense to me.
    Most importantly, I'd make very sure that all my "code-behind
    ActionForms" were request scope, probably by changing the factory
    default.
    Can you elaborate on this? Why the strong recommendation for request scope? Is it because of threading concerns related to session-scoped ActionForms that I mentioned above?

    By the way, I'm very interested in all of the feedback on my request for input on this pattern. If this is considered a desirable pattern, would it be worth adding it on the Struts wiki?

    Stephen

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org
  • Michael Jouravlev at Jul 15, 2005 at 3:53 pm

    On 7/15/05, Schaub, Stephen wrote:
    -----Original Message-----
    From: Ted Husted
    Sent: Wednesday, July 13, 2005 3:22 PM
    To: Struts Users Mailing List
    Subject: Re: Putting execute() in ActionForm

    [snip]

    If I were to use this strategy, I'd select the parameters to the
    Execute signature with care. There may not be any reason to pass the
    HTTP parameters out of the call, and there may be a reason to pass
    the Action. I would just be careful of using the parameters from the
    Struts Execute signature, unless my code actually needed those
    parameters..
    I have found that I do need the Action available to the ActionForm's execute method, because the Action class contains several important utility methods (like saveErrors(), etc.) that need to be available to the ActionForm's execute method.

    Further, since there is a separate ActionForm instance for each thread, I've considered adding the ActionMapping and HttpServletRequest as instance variables on the ActionForm, which are populated by the Action method before invoking ActionForm.execute():

    public class SimpleAction extends Action {
    public ActionForward execute(ActionMapping mapping, ActionForm form,
    HttpServletRequest request, HttpServletResponse response)
    throws Exception {
    SimpleActionForm bean = (SimpleActionForm) form;
    bean.init(this, mapping, request);
    return bean.execute();
    }
    }
    You can do the same in ActionForm.reset(). It receives mapping and
    request. I often pull out session object out of request and save it in
    a field of an ActionForm, so I could access it outside reset().
    By the way, I'm very interested in all of the feedback on my request for input on this
    pattern. If this is considered a desirable pattern, would it be worth adding it on the
    Struts wiki?
    Darn, I realised that I need another event for my CRUDAction, thus I
    need another handler in the action, then I need to pass it to the
    form, so I need to update ICRUDForm interface... If I called some kind
    of execute() method in ActionForm directly, I would not have to change
    the interface now.

    So, I guess I will change the way Struts Dialogs works, and will
    channel events directly to ActionForm. Instead of creating a new
    generic traffic cop action I have to fiddle with some core class like
    RequestProcessor. If action class is not defined for a form, and form
    implements something like ICallable, then I would call form directly.

    Major change... Good, that it had not been accepted to core Struts yet ;-)

    Michael.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
    For additional commands, e-mail: user-help@struts.apache.org

Related Discussions