Not *quite* what I was saying, but close.
I have a list for displaying things. A parameter for the dispatching,
and now I'm considering putting in a map for criteria to be entered from
the user (the more typical pattern).
The reason this has become so tempting is that I am using Hubert
Rabago's FormDef plugin, which, with a single method call and some xml
definitions, lets you make a single method call to generate a populated
DynaBean based on the business object you pass into it.
So what I'm able to do in my Action is the following:
Do my Hibernate query.
For each of the biz objects I get back from the query
{
Generate a corresponding dynabean for the business object with a call
to FormDef.
Stick it into the "Generic Form Bean's" display List.
}
It's terribly easy. Almost too easy. Yeah, it requires a form to be put
into session scope, but it's always the "same" form, the session isn't
going to get too crowded. It's not like everything is being put there.
Well it is, but it's all going to get replaced on each request :-)
The only drawback I see is that I will *have* to use
DynaValidatorActionForm as a base class, since every request is really
using the same form, otherwise the validator won't help me, and the
validator will not be generating javascript popups because every
property is going to be indexed.
I'm onto something. The question is, is it good or bad :-). The moment I
found myself considering adding a Map to my generic DynaForm, I started
to have doubts...
-Joe
> -----Original Message-----
> From: Rick Reumann [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 21, 2004 12:45 AM
> To: Struts Users Mailing List
> Subject: Re: Am I about to create an anti-pattern?
>
>
> Joe Hertz wrote:
>
> > Now I've also got some screens that need input criteria for
> the search
> > that results in the data upon the screen. I'm contemplating
> adding a
> > Map to this form for this purpose.
> >
> > My intentions are good. Any thoughts about where this road
> I am paving
> > is going to?
>
> I try to keep my form beans only responsible for collecting user
> inputted data (the exception is I often keep the parameter
> used for my
> dispatch actions in the form bean as well). I tend to not
> like to bloat
> an ActionForm with things like Lists or Maps that are used solely for
> the purpose of display data used for collecting input. I 'think' what
> you are saying in the above is that you'd have a Map in your
> form bean
> that would be used to provide a drop down list (or something
> similar). I
> usually opt for putting stuff like this in the session or,
> depending on
> whether form validation is needed or not, you could simply
> make the call
> to the business layer to return this Map each time and populate in
> request scope. If you need the Map around for the life time of the
> user's session set in there or put it in request scope each time.
>
> The 'road you are paving' isn't really all that bad in my
> opinion, but
> to me Action Forms shouldn't hold this kind of info. After
> all at some
> point you are having to call a business class in your action
> in order to
> populate the Action Form Map or List (a definite no-no is having the
> form bean actually make model layer calls to populate the Map
> or List).
> Since after getting the List or Map from the model it's just
> as easy to
> put in Session or Request scope as it is to put it in the form bean.
> Plus, for you plan to work it would appear the form bean would always
> have to have session scope, otherwise you'd still be making a model
> layer call to get the List or Map and then populate the form
> bean each
> time. Sometimes my form beans make sense to be in Session
> scope but most
> of the time request scope will work fine.
>
>
> --
> Rick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
