Ted,
> * Use directory matching for ActionServlet (/do/* instead of *.do)
I'd like to hear more about why you prefer this technique. I have to admit
that I've rather blindly followed the *.do camp without giving too much
consideration to the alternatives.
Thanks!
--
Martin Cooper
----- Original Message -----
From: "Ted Husted" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, July 22, 2001 12:22 PM
Subject: Re: Struts Design patterns
> Any of the patterns described in the recent "Core J2EE Patterns" should
> work well with Struts. In fact, many of these have already been
> implemented for you by the framework ;-)
>
> The three patterns that Struts developers may use most would be Data
> Access Objects, Value Objects, and Helper Objects. The classical trinity
> is to have a Data Access Object return a Value Object, which is wrapped
> in a Helper Object and sent to the presentation layer.
>
> In my projects, I use standard method calls to my Data Access Objects,
> like
>
> public static final int scriptInsert(
> int script, byte image, String title, String article
> ) throws AccessException {
> return
> scriptCommand(script,image,title,article,Commands.SCRIPT_INSERT);
> }
>
> Where scriptCommand is a library function shared by Insert and Update.
> The implementation here uses standard JDBC things like
> PreparedStatements.
> Though, I could change all that without affecting anything else. (Hence,
> the custom AccessException instead of SQL Exception.)
>
> The retrieval commands return RowSets
>
> public static final RowSet scriptSelect(int key) throws SQLException
> {
> return RowSets.getRow(key,Commands.SCRIPT_SELECT);
> }
>
> which I use as Value objects. RowSets are handy even if you are using
> something else in the implementation. Since RowSets can be created from
> scratch or from a ResultSet, they make an excellent value object.
>
> You could also pass the RowSet directly to the presentation layer, and
> use the Struts logic:iterate and bean:write to access the column by
> number.
>
> <bean:write name="ROW" property="object[3]"/>
>
> You can also use the Jakarta Tablib dbTags with disconnected rowsets. I
> just submitted the patch, and it may not be available in the nightly
> build yet, but you can get the updated JAR from More About Struts.
>
> < http://husted.com/about/struts/resources.htm#new >
>
> Here you just place the RowSet into Request context and tell the
> resultSet tag its name.
>
> <db:resultSet id="ROW" name="ROWS">
>
> and then you can use the dbTag getColumn tag to refer to columns by name
>
> <db:getColumn colName="title"/>
>
> See the Jarkata dbTag docs for more about getColumn and friends.
>
> Some other Struts design stategies I would recommend are
>
> * Document all entry points with global forwards (no "page=" parameters)
> * Use more mappings to minimize the use of hidden fields and query
> strings
> * Use the parameter property to document each operation of an Action
> * Use one Action for related operations
> * Use one ActionForm for related forms
> * Subclass Action and ActionServlet as needed for better code reuse
> * Use directory matching for ActionServlet (/do/* instead of *.do)
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
>
> > Jerzy Kawa wrote:
> >
> > Hello all,
> > Any comments about struts design pattern ?
>
