On 9/6/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
>
> At first I thought prerender would be really cool, and I'm sure in some
> cases it is, but I still find myself writing "prepareForSearch" or
> "prepareForEdit" methods. To make it makes sense to have those kind of
> methods in backing beans for your commandLinks or buttons on menus to
> call. The reason I feel this way is....
>
> 1) If using setUp/prepare method calls, it make sense when reading the
> code what is going to happen. If I see the link call that method I can
> tell exactly at a glance what is going to happen. (Granted it's not that
> difficult to look inside the backing bean see that a prerender is in
> there.)
Any event driven paradigm is going to require that you have at least some
casual understanding of what events get called in what order.
2) More importantly, setup/prepare methods allow for multiple setUps for
> a backing bean. What if when going to an "EmployeeAction" as a backing
> bean that you need to prepare a search screen that is completely
> different when searching for a "domestic" employee versus an "abroad"
> employee? To handle setting up different types of pages with a prerender
> looks like it would involve logic within the prerender method (pull some
> kind of requesst variables which is ugly enough to do in JSF) or you
> would have to create multiple types of Actions. Whereas doing things
> without the prerender you can have "prepareDomesticSearch"
> "prepareForeignSearch" methods in the same bean.
This seems to be the place where you are doing things in a way that is
counter to what ViewController is designed to support, and are therefore
struggling. You should ***not*** be using the same backing bean to prepare
data for different views. I don't understand your scenario above well enough
to comment (I would have thought you'd search *before* you got to the
employee action screen, rather than *after*), but in short what I think
you're talking about is a scenario like this:
* Employee Details page has a "Search" button on it
* Need to do different kinds of searches for domestic and international
employees.
Is that close enough? If so, on your EmployeeDetails page you'd have a
"Search" button bound to a search action method in the backing bean for the
Employee Details page:
<h:commandButton id="search" value="Search" action="#{
EmployeeDetails.search_action}"/>
And, in the EmployeeDetails.java class (the backing bean for this page),
you'd have an action method that navigated to the right place, based on data
currently on this form:
public String search_action() {
; // A missing detail goes here -- see below
if (... this is a domestic employee ...) {
return "domesticSearch";
} else {
return "internationalSearch";
}
}
These outcome values would be fed into your navigation rules, and would
navigate to "/DomesticSearch.jsp" or "/InternationalSearch.jsp".
Now, where do you do your setup logic for a domestic search? In the
prerender() method of the DomesticSearch.java backing bean, *not* in the
prerender() method of the EmployeeDetails bean! (Same exact scenario for
international searches). Note that no conditional logic is needed inside
prerender -- you know what kind of a search you're doing already, based on
which prerender() method got called.
There is a missing link here (mentioned in the code clip above) -- how do
the search screens know what employee you are starting from? For that
purpose, you've got the following kinds of choices:
(1) The prerender() method knows what form you navigated
*from*, and therefore what request parameter to consult
to find out the employee id.
(2) The prerender() method knows what view id you navigated
*from* and therefore what page bean to reference, and then
call the getEmployeeId() method on it.
(3) The original search_action() method can store the employee id
of the relevant employee in some request scope attribute that
both pages know the name of.
(4) The original search_action() method can store the employee id
as a property of some other managed bean that both pages know about.
Options (1) and (2) are not recommended, because they require too much
coupling between views ... having to know where you came from means it gets
hairy to add new navigation paths to the same existing page later on. Option
(3) or (4) minimizes the coupling -- you only have to know the place where
an employee id will have been stored, not anything about who is storing it.
3) Lastly I'm not so sure I always want the prerender method being
> called. For example if I'm using the same backingBean for genearating a
> list of employees and for setting up an edit page, what would the
> prerender actually setup and would I want it always firing?
If you use prerender() the way it's intended to be used (on the destination
page, not the origin page -- and not trying to share them across multple
pages) you'll quickly discover that you really do want it called every time.
Using prerender only seems to make sense in light of very specific
> backing beans that are always going to behave in the same fashion.
Please don't carry over bad habits from Struts based architectures :-).
I could be very well way off-base so I'd be interested in other comments.
>
> --
> Rick
Craig
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
