Discussions

Web tier: servlets, JSP, Web frameworks: Struts' approach of forwarding does not make sense

  1. Struts' approach of forwarding does not make sense (3 messages)

    All example usages, and also most implementations I've seen so far are having the struts-config.xml forwards setup in such a way that the action mapping forwards are in relation to a specific JSP page, and defines possible forwards (often in terms of "success" and "exit" -type keywords).

    The issue with such a scheme of forwarding is that it would be impossible to apply good reuse when one want a sequence of such pages to be applied elsewhere in the application. To be able to reuse this, one should not define where the next page is, but rather what the next "page flow" (use-case?) is. The calling action would then be able to receive the output from the called page flow. I believe that Expresso and Bea Workshop addresses this, but I do not have experience with either tool, so I'm not sure.

    Please let me know if this sounds unclear, and I will explain further.

    Andre Ranvik
  2. What?[ Go to top ]

    What?
  3. Not quite getting it either. I am very familer with Expresso and it is simply a Struts extension having forwards operate in nearly the same fashion. Could you provide an example of what you would like in pseudo code please
  4. The problem I am addressing is experienced in typical order-entry applications, as opposed to portal informational-only applications.

    In such order-entry type applications, you very often need to gather bits-and-pieces of information, for example you need to provide user-registration entry forms, product-search forms, product-order forms, etc. These forms normally consist of multiple web-pages, where each page completes a part of the information-gathering process. These individual parts normally need to be put into the session or persisted somehow, but the location (e.g. the session attribute variables to be used) of the information and also what to do with the information should really be up to the "user" (calling party) of the forms.
    I would like each page to function as a method: "Here is your input, and give me your output - I'll worry about how to handle the output, and I don't care how you gather the input."
    One way of achieving this, is to build up a graph-structure forwarding scheme, where I can call a form-entry page-set (from now on called "use case"), where the calling party has full control of the output from such use-cases. The use-cases themselves are merely "information gatherers", and should not have to deal with how this information is used. The calling party should handthe controller should deal with a use-case level of granularity as opposed to a page-level granularity (like Struts does). After a use-case has completed its job (of gathering information), it should return this information to the calling party. Keep in mind that a calling party might itself be called from another calling party etc. In other words - a stricter separation of the controller and the form.
    This is what Struts should have provided (thes things would belong in struts-config.xml):
    * A way of grouping and ordering individual pages into use-cases. A use case may itself consist of a set of use cases.
    * A way to forward to these use-cases (as opposed to individual pages).

    I am well aware of that all this is possible using Struts (I have done it myself), but it requires quite an effort to make it easy to use, and it seems to be something Struts should have provided out-of-the-box.

    I hope this was more understandable. I would like to know if there are tools that are addressing any if these issues - preferably based on / or add-ons to Struts.


    Here is another issue with Struts:
    You have virtually no control of how to prepare data for easy JSP rendering of data. It is common to use custom-tags to process complex data structures, or even worse use scriptlets and heavy JSTL processing. I know that you want to provide control of most (all?) visual aspects to the JSP developer, but he/she should normally not have to deal with sorting, appending, adding up, text-manipulation, etc. of the information.

    It would be nice if there was a pre-rendering step where we could take data from the session (and wherever else it may be) and prepare it for the rendering JSP, with the purpose of making the JSP code clean and easy to maintain. This could be things like appending information, sorting it, cropping long text-blocks etc. It is a shame that we would have to deal with custom tags for each such scenario - or have to create our own proprietary framework for dealing with it.
    My way of dealing with this was to provide abstract methods for the Action forms, where one could write JSP-preparation code, and insert it into the request. This also requires that the ActionForm is called prior to the JSP being renderes, something that is easily done by forwarding to ".do" instead of ".jsp". You would then need a mechanism in your Base Action class of knowing whether the Action Form is executed before or after the JSP. This was handled by having a flag being set/unset in the session.

    Puh! Lots of text here... Anybody still with me?