Discussions

News: Another Interesting Set of Struts Best Practices

Bookmark and Share Get thread feed

  1. Another Interesting Set of Struts Best Practices (12 messages)

    • Posted by: Matt Anton
    • Posted on: December 22 2004 03:38 EST
    I remember a post, a while back on TSS, that linked to "Struts Best Practices - Build the best performing large applications" (http://www.javaworld.com/javaworld/jw-09-2004/jw-0913-struts.html), generating avid reader response. This pointer to JAX Magazine's new article, "Struts Best Practices - How To Develop Low-Maintenance, Quality Code" (http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html) will hopefully bring about a more comprehensive discussion on the best practices employed in the Struts world.
    Reply to this

    Threaded Messages (12)

  2. RE:Another Interesting Set of Struts Best Practices[ Go to top ]

    Is it me or do the first two best practices conflict? It first recommends creating a base class for your actions adding common methods to that, then goes on to say use DispatchAction to group common actions. These two practices are not compatible unless you extend your base class from DispatchAction

    Chris
    Reply to this Reply to original

  3. RE:Another Interesting Set of Struts Best Practices[ Go to top ]

    Is it me or do the first two best practices conflict? It first recommends creating a base class for your actions adding common methods to that, then goes on to say use DispatchAction to group common actions. These two practices are not compatible unless you extend your base class from DispatchActionChris

    It's not you, they are incompatible.
    Q Best Albums of 2004
    Reply to this Reply to original

  4. RE:Another Interesting Set of Struts Best Practices[ Go to top ]

    Is it me or do the first two best practices conflict? It first recommends creating a base class for your actions adding common methods to that, then goes on to say use DispatchAction to group common actions. These two practices are not compatible unless you extend your base class from DispatchActionChris
    It's not you, they are incompatible.Q Best Albums of 2004

    I was most surprised they suggested grouping common options this way rather than build the Intercepting Filter pattern. That is how I did it in my first Struts project. We exended the struts action servlet and inserted the filter pattern.

    I suppose you could also subclass the DispatchAction with a second copy of the common operations - but that would be wrong on a few other levels :)

    David
    Reply to this Reply to original

  5. RE:Another Interesting Set of Struts Best Practices[ Go to top ]

    I think its correct. The base class recommendation is for "common" actions (common steps required for carrying out any two functions). And the DispatchAction recommendation is for "related" actions (functions which form part of the same process)
    Reply to this Reply to original

  6. RE:Another Interesting Set of Struts Best Practices[ Go to top ]

    Is it me or do the first two best practices conflict? It first recommends creating a base class for your actions adding common methods to that, then goes on to say use DispatchAction to group common actions. These two practices are not compatible unless you extend your base class from DispatchAction

    One alternative is to inject a request strategy/handler into execute method of Action or DispatchAction which provides it's own subset of hooks that can be used for both Action types.

    The easier solution is to use all DispatchActions and add the ability to define the method to be called in the ActionMapping-- leaving a default method to be executed (your straight Action case). Since all of your Actions inherit from the same DispatchAction, you can provide hook methods in the request processing for security, connection management, etc that can be overwritten in each subclass.
    Reply to this Reply to original

  7. RE:Another Interesting Set of Struts Best Practices[ Go to top ]

    Matt Raible has done a good job in Appfuse (http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse) at implementing a BaseAction where he extends from LookupDispatchAction to handle any situation.

    Other Struts best practices:

    JSTL taglibs over Struts taglibs whenever possible.


    Tools:

    Appfuse: good starter web.xml, springframework integration, BaseAction, ActionForm transform, etc...

    XDoclet: (sourceforge) to generate struts-config.xml (reduces the need for modules and contention on struts-config.xml file)

    myeclipse IDE has Struts GUI builder (@ $30 a pop - not bad)

    PageFlows: WebLogic Workshop (or Apache Beehive/Pollinate) to build Pageflows ( a Struts wrapper that encapsulates Actions/Forms/Struts-config in one class!

    Best Practice Sources:

    Jakarta Pitfalls (Wiley Press) see online sample chapter on ActionForm <-> VO transforms and validation.

    Struts In Action (Manning)
    Reply to this Reply to original

  8. RE:Another Interesting Set of Struts Best Practices[ Go to top ]

    How about another (best) practice:
    use form bean as a wrapper for the actual data (typically in the form of value object / DTO). That way you don't have to duplicate the declarations of fields in both the form bean and value object.
    Reply to this Reply to original

  9. RE:Another Interesting Set of Struts Best Practices[ Go to top ]

    Is it me or do the first two best practices conflict? It first recommends creating a base class for your actions adding common methods to that, then goes on to say use DispatchAction to group common actions. These two practices are not compatible unless you extend your base class from DispatchActionChris

    The scenario for using these two best practices are different. Use a base class to implement common functionalities to avoid duplicate code in different action classes.

    Use DispatchAction when there are "similar" actions (ex CRUD operations) to be implemented. Doing this will result in a single action class instead of a number of seperate action classes. This results in easy maintenance.
    Reply to this Reply to original

  10. best list[ Go to top ]

    Here are 11:
    http://infonoia.com/en/content.jsp?d=inf.05
    30 free videos, sample code
    http://wiki.apache.org/struts/StrutsTutorials
    A sample site:
    http://wiki.apache.org/struts/PoweredBy
    Tool:
    http://www.scioworks.com
    Struts (and Apache) based PetStore:
    http://ibatis.com/jpetstore/jpetstore.html

    .V
    ps:
    of course I now do RiA:
    -http://www.sandrasf.com/sites ;-)
    pps2: Just yesterday, Struts developers, god bless them, replaced the entire guts of Struts with CoR, a very simple and powerfull IoC like patern, in preperation for version 1.3. All BRAND NEW CODE! Check it out in nighly builds:
    - http://struts.apache.org/roadmap.html
    Reply to this Reply to original

  11. best list[ Go to top ]

    Just yesterday, Struts developers, god bless them, replaced the entire guts of Struts with CoR, a very simple and powerfull IoC like patern, in preperation for version 1.3. All BRAND NEW CODE!
    And what's the implication of this?
    Reply to this Reply to original

  12. Struts Chain Benefits[ Go to top ]

    Struts chain allows the developer to completely customize how Struts handles a request. This means if you don't like how Struts creates ActionForms, you can write your own "command" and replace the Struts one. If you don't want to extend Action every time, write your own commands to interact with your custom Action framework. If you want to use OGNL to map HTML form values into your form model, reimplement the PopulateActionForm command.

    For example, I wrote a POJO-based framework that allowed you to write Actions as regular Java classes that didn't implement or extend anything. Form values were automatically set on your action bean via reflection, ala WebWork. All it took was replacing a few Struts commands with my own implementations.

    The bottom line is Struts chain will allow developers to go in completely new directions with Struts, with the best ones eventually being accepted back into Core. We (disclaimer: Struts committer) still have a ways to go for complete configurability/extensibility, but Struts chain is a big step in that direction.

    Don
    Reply to this Reply to original

  13. Another Interesting Set of Struts Best Practices[ Go to top ]

    Having a BaseAction class for performing common operations is good. But the authorization should not be performed in the BaseAction class.
          For this purpose the Intercepting Filter could be used. Using servlet filters for this purpose gives more flexibility. Also in some cases we may use the Struts ForwardAction to forward directly to jsp pages but we may still need to authorize the request. In these scenarios using Intercepting Filters gives a clean solution.


    Chandrasekar
    Reply to this Reply to original