Am I about to create an anti-pattern?

[Joe Hertz <jh...@speakeasy.net>]

This is the problem with being a solitary developer who doesn't have
other developers to bounce his ideas off of. I'm using you all. 

I'm finding myself gradually creating a generic two-way form bean. 

That is to say, a number of my actions boil down to showing lists of
objects that need to be modified and saved, so I have a form that
contains a List, and I put it into the session scope with the objects
that need to be dealt with. Since the List can contain any object, I've
used this form bean in several places where the concepts are similar. 

Eventually, I added a String named method to it to enable it's use in
DispatchActions. Didn't hurt it's reusability.

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?



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Am I about to create an anti-pattern?

[Adam Hardy <ah...@cyberspaceroad.com>]

Joe,
generally speaking you should seperate out the search functionality from 
the object lists. You could have two different forms quite easily and 
when you decide to enhance your search functionality it could quickly 
get really messy.


On 04/21/2004 06:44 AM Rick Reumann wrote:
> 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.
> 
> 


-- 
struts 1.2 + tomcat 5.0.19 + java 1.4.2
Linux 2.4.20 Debian


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Am I about to create an anti-pattern?

[Rick Reumann <st...@reumann.net>]

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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org