RE: Struts Design patterns - if you use TogetherCC...

[rh...@rdg.boehringer-ingelheim.com]

I have implemented the Value Object pattern in Together Control Center. My
implementation creates a vo based on an entity EJB (it would also work for
any other class with public attributes) and also adds a setter/getter for
the newly created vo to the bean class. The pattern can also be reapplied to
update things if changes are made to the bean class. I was going to post to
the community site, but there are still a few minor problems with the
module.

If anyone else is using Together+EJBs+Struts though, you might find this
helpful. It sure has saved me a lot of time! If you are interested then let
me know and I will email it to you or post it to the group.

While on the topic of Struts and Together, I was thinking about implementing
some Struts specific patterns in Together. However, I started thinking about
this in more detail, and I am not sure how useful this would be since the
majority of the Struts logic is contained in the config.xml file. It would
be no problem to generate some skeleton templates for a ActionForm or
ActionServlet, etc... but a useful pattern implementation would probably
need to contain navigational logic and update the XML file accordingly. Has
anyone else thought about this or tried to implement any Struts patterns in
Together?

-Bob





-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Sunday, July 22, 2001 3:22 PM
To: struts-user@jakarta.apache.org
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 ?