struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lisa Woodring (EUS)" <EUSL...@am1.ericsson.se>
Subject RE: Struts limitation?
Date Wed, 14 Jun 2000 13:21:46 GMT
see comments below


> > I've been reading about Struts and playing with the example application.
> > It seems like there's a major limitation with the architecture, but
> please
> > correct me if I'm wrong...!!??
> >
> > It appears that multiple Action classes can use the same ActionForm.
> > However, an Action can only use 1 ActionForm (which would translate
> > to only 1 bean per JSP page).  Is this correct?
> >
> 
> You are correct ... however, there is no limitation on the number of beans
> on
> the JSP page -- it's just that only one of them will be treated as a "form
> bean"
> for a particular mapping.
> 
	---- That's what I thought.  Of course you can use more beans, but
you
	lose the ability to use parts of the struts taglib.


> >
> > My application sets configuration parameters for a piece of equipment.
> > The grouping of configuration parameters is not necessarily obvious
> > -- different people have different views on the logical grouping.
> > Therefore,
> > we want the ability to have certain parameters show up on multiple
> > pages -- and have the flexibility to easily move parameters between
> > pages (without having to change the ActionForms).  So, in this case, it
> > would make more sense to have the "ActionForm" beans contain an internal
> > grouping.  Then, have the JSPs use parameters from different beans.
> But,
> > it appears that you can only have 1 ActionMapping per path in the
> > "action.xml"
> > file.  Am I wrong, or is there a way to do this?
> >
> 
> I am not positive I completely understand what you are after, but can't
> you do
> this by sharing a single ActionForm instance with all of the
> properties/fields
> required by all of the various pages?  That way, you can move a particular
> field
> from one page to another (within this set of pages) without changing any
> code.
> 
	----- Yes, we could use 1 ActionForm for all the parameters.
However, we
	have several hundred parameters -- that would make a rather
gross-looking
	bean.  Not an acceptable approach in my opinion.


> >
> > We actually have an architecture that uses a generic bean class for the
> > parameters.
> > Then, we have a "setName" method that needs to get called to specify the
> > specific
> > parameter.  Ideally, it would be nice if the ActionServlet could do this
> for
> > us --
> > creating the generic bean class & calling the "setName" method.  Any
> > ideas/thoughts?
> >
> 
> If you passed the name as a hidden input field called "name", won't this
> work
> for you?  The servlet has no clue whether a particular field was actually
> visible or not -- only that it came in as part of the request.
> 
	----- I don't think this will work in our case.


> The Struts design pattern is aimed at the use case where a particular form
> bean
> contains individual properties for various fields with matching names
> (modulo
> the usual JavaBeans conventions about capitalization).  A single form bean
> can
> be shared across multiple pages, and a particular field can be moved among
> those
> pages -- or even shown on more than one of them.  The main rationale is
> that, if
> you have to redisplay an existing page, you want the values last entered
> by the
> user to be redisplayed (just as a GUI application will) so that only the
> offending fields need to be corrected.
> 
> If your JSP pages are gathering data from more than one bean, you've got a
> couple of choices if you want to use Struts as it currently stands:
> 
> * Create a new bean that combines all the required fields, and populate
>   it appropriately when it is first created.  This can be very handy when
>   your form bean actually represents an underlying data object (like an
>   entity EJB) and you do not want to make actual changes to the data
>   bean's properties until everything has been validated and completed.
> 
	----- Yes, this is one approach we could take.  But I have a feeling
that
	the content of our pages will change frequently (at least for
awhile).
	If we make an ActionForm bean to represent each page, we would
	have to change that bean every time the page content changes.
	Doable (and easy work), but definitely not ideal.  This is one
	possibility -- with this, we could still use the struts taglib.

> * Skip the "form bean" part of Struts and just use the MVC pattern stuff.
> 
	----- Possible, but it seems like that's one of the major advantages
	of Struts...  :-(

	One idea we had was to create an XML representation of the pages
	(it would define the page names and which parameters are on each
	page, call it something like "pagelayout.xml").  Use "struts"
action.xml
	to map the "path"s to pages by adding an application-specific
parameter:
	name of the page.  Then, we would have 1 (and only 1) Action class 
	that handles the parameters in a generic manner.  The Action class 
	would lookup the appropriate page in the "pagelayout.xml" file and 
	use this information to build up a list of parameters that are
needed for 
	this page.  
	(Then, it interfaces to the business logic portion of the code,
etc...)
	However, we would lose the ability to use the "struts" tags which
can
	only be used inside forms.  Bummer...


> I'd be interested in discussing what sort of general design patterns we
> could
> implement in Struts that come closer to your requirements, if it is
> insufficient.
> 
> >
> > Lisa
> >
> 
> Craig McClanahan
> 
> 

Mime
View raw message