Re: Help with a design issue that I'm stumped by....

Rick Reumann wrote:

>On Thu, 08 May 2003 13:03:59 -0400
>Vic Cekvenich <[email protected]> wrote:
>
>  
>
>>You need 2 beeans.
>>One is a search bean, that will capture the submit of the search
>>screen. (deartment, name, etc.)
>>After submit, you pass values to employeeBean.populate(v_dept, 
>>v_firstName, etc.). This then display a list of employees.
>>Also, the select statment needs to be dynamic.
>>    
>>
>
>Well, now that I've gotten more into this, a few more questions:
>
>1) Would you also make this "SearchBean" and subclass of BaseBean? At
>first I thought this would be a bit overkill since all this bean is
>going to be used for is picking up some parameters (nothing to be
>persisted to the database etc so no need for a DAO and all the other
>stuff that comes with BaseBean). The problem is if I don't make it a
>BaseBean I really can't use it in any actions that are going to be
>subclasses of BaseAction and more problems abound with the use of
>ActEvent. If I create my SearchBean as a type of BaseBean these problems
>go away, but it does seem a bit heavy to make a simple bean like this a
>type of BaseBean.
>
>  
>

Agree. But since classloader loads BaseBean anyway.... its not that big 
a deal.
Also as far as thinking .... no need :-) You have a form, the bean must 
match form.
So you have a search form, and a search formBean (baseBean). It matches.
Each screen has it's bean, sort of.
To get to search form, you go to search action, that just creates the 
search bean in session, and passes to search screen.

search form, then submits to EmployeList action, and the process repeats.
I know that is what you said, just with Struts, very little to think 
about. I just handed things a bit same so it KISS:
namePg.jsp has a nameBean,java form bean that matches it. In order to 
get to  namePg.jsp you need to call nameAct.java.

>2) Assuming this SearchBean should be a BaseBean I used it like this...
>
>First I have an EmployeeAdminAction that is associated with the
>EmployeeSearchBean .... possibly like...
>
>
><action path  ="/employeeAdmin"  
>        type="foo.bar.EmployeeAdminAct"
>        name="employeeSearchBean"    
>        scope="request"   			 
>        validate="false">
>              <forward name="Continue"  path="/employeeList.jsp" />
></action>
>  
>

I make everything session scope..... just a habit.

>
>then my EmployeeAdminAction (extends BaseAction) and in there I have:
>
>
>public String onDisplayExec {
>
>	//try/catch removed for brevity
>	
>	EmployeeSearchBean employeeSearchBean = 
>		(EmployeeSearchBeanarchBean) ae.getBean();	
>
>  
>
Good!

>	
>	//create an EmployeeBean (List backed)
>
>	EmployeeBean employeeeBean = new EmployeeBean();
>

Perphaps you mapped this bean in action mapping, thus no need for new, 
Struts does it for you.

>
>	
>	//populate the bean using the employeeSearchBean
>
>        employeeeBean.populate( employeeSearchBean );
>

I do not do this.
I would do

employeeeBean.populate (employeSeachBean.getFirstName(), employeSeachBean.getDept(), ....);

this way it is... clenaer, more reusable.
Hey you asked for comments, so I have to think of things to say; but you can see not much diff. 


>        
>	
>	//now use the ActionEvent to put this bean in scope
>
>	ae.setBean( employeeeB );
>
Again.... if you mapped in action, Struts took care of this.

>
>}
>
>
>The above seems to work ok, but it also seems to have some problems.
>Initially the EmployeeSearchBean ends up going through the whole
>BaseAction process which includes having the ActionEvent put this bean
>unnecessarily in request scope in the portion of the BaseBean ...
>ae.setBean((BaseBean) formBean);
>
There is not much gc. But maybe I should not do that, and coment that 
line out so people put in scope themselfs.

>
>Maybe what I'm doing is ok?, 
>
If it works and meets requiremtns its good.

>but I'm guessing there is a better way.
>
What's better for one siutation/person is not ideal for another, good 
enough is good enough.

> I
>could of course just build a smaller lightweight Action to handle this
>search portion, but I want to be consistent with the framework.
>Obviously this situation must come up a lot, so I'd love an example to
>see how it should be done.
>

Yes, this does come up a lot, and I would do it just like that. Maybe I 
should have a serch scanario in basicPortal, like find users so one can 
set what role they are in.


.V