Hi

I use a subclass technique where I can achieve both a generic form as well
as specific forms for each action. Eg

public abstract class GenericListForm extends ActionForm

public class OrderListForm extends GenericListForm
public class MessageListForm extends GenericListForm

In my case, both OrderListForm and MessageListForm are emtpy (since I have
managed to include all functions in the GenericListForm). Now, all you need
is to call the super.reset():

    public void reset(ActionMapping mapping, HttpServletRequest request) {
        super.reset(mapping, request);
    }

GenericListForm contains all the functions and data for the JSP to navigate
across pages.

In the struts-config.xml, you work with OrderListForm and MessageListForm
(note that GenericListForm is abstract), eg:

                <action path="/orderList" type="OrderListAction" name="orderListForm"
scope="request" validate="false" >
                        <forward name="success" path="orderlist.jsp" redirect="false"/>
                </action>

It works really well, in your JSP, you can access the attributes from the
GenericListForm via the OrderListForm.

Keith


-----Original Message-----
From: Alex Colic [mailto:[EMAIL PROTECTED]]
Sent: Friday, 11 January 2002 10:14 a.m.
To: Struts Users Mailing List
Subject: RE: Struts design advice requested please.


Thanks a lot I really appreciate all the advice. It really helped me out.
One thing you said really surprised me. You said:

>For ActionForms, my preference is to use larger generic form beans. They
>are really a throw-away object, and linking them too closely to a
>hierarchy can be a waste of time.

I have been doing the opposite of generic forms. My forms usually consist of
objects within object. For example I might have an invoice object that has
and employee and a part object within it. It would have been faster for me
to make on big flat form but I thought that it would be better to break it
up amongst a number of objects. Looking back though, most of my forms all
they do is collect data that is used somewhere else.

Something for me to think about.

Thanks

Alex




-----Original Message-----
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: January 10, 2002 12:42 PM
To: Struts Users Mailing List
Subject: Re: Struts design advice requested please.


Alex Colic wrote:
> I have been using Struts now for about a year and I really like it. It has
> saved me a lot of time and made my apps quite stable. I have just been
> placed on another large struts project. It will be pushing struts to the
> limit. A quick question on design. What I am going to do is a bit
difficult
> to explain. This app is going to be used by users to input inventory data
> into two different databases, an AS400 and an Oracle/SQL database. The
user
> will enter essentially the same type of inventory data into each system,
> but, there are differences between the two. Part of the project plan is
that
> through a config switch, parameter etc, I will be telling struts if we are
> working with an AS400 system or an Oracle/SQL system and then the guy will
> slightly change, just the addition or deletion of a gui element.

I would consider extending the ActionServlet so that it stores which
schema is in use.

The Action could then look at the schema setting to route or otherwise
handle the request as needed.

Ideally, the Action should be able to just pass the schema setting back
to the business logic, without knowing anything about the schema itself,
except that it is some fact the business layer needs to know.


> I though about making a form bean that includes all the properties that
are
> required by the Inventory object for the AS400 and the ORACLE/SQL system.
> This would make one large generic form bean.
>
> Then I thought about making an abstract class that includes all the common
> elements amongst the object and from there I would extend and create an
> AS400 inventory form or an Oracle/SQL inventory form.

This is always a tricky question when dealing with persistence layer
issues. Scott Ambler's paper

http://www.ambysoft.com/mappingObjects.pdf

discusses this in depth.

For ActionForms, my preference is to use larger generic form beans. They
are really a throw-away object, and linking them too closely to a
hierarchy can be a waste of time.

The business logic beans that form the real peristence layer are another
matter (see Ambler). But ActionForms are really just an expediency.


> If I go this way then
> how do I set up the Struts.xml file to use the specific inventory form, if
> it could be one of two?

If you use subclassing, then you would have an ActionMapping for each
ActionForm subclass, which may or may not use the same Action class.

If you use one big bean, then they can all use the same Action, and it
can sort out which fields are being used for the active scheme.

In either case, you can use a separate page for each schema1 type, and
let the controller route to one or the other, or pass the schema type to
the page and let it use the logic tags to render the appropriate form.
The latter reduces the number of pages that need to be maintained, but
makes for larger pages. The former creates more individual pages, and
seems like better MVC to some folk. It's really a six-of-one
half-a-dozen of the other issue, and may be best left up to whomever has
to maintain the presentation pages.


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to