Interspersed.
On 9/16/05, Rick Reumann <[EMAIL PROTECTED]> wrote:
>
> Craig, if you're reading this, sorry to address you specifically in
> the subject, but I believe you commented once on this and said there was
> something wrong (or bad) about doing things this way and I want to make
> sure I'm doing things correct since I'm working on that CRUD
> example/lesson...
>
>
> My index.jsp (welcome file):
> ----------------------------
> <jsp:forward page="/employeesSearch.faces"/>
>
>
> Navigation rule:
> -----------------
> <navigation-rule>
> <navigation-case>
> <from-outcome>employeesSearch</from-outcome>
> <to-view-id>/employeesSearch.jsp</to-view-id>
> </navigation-case>
> </navigation-rule>
>
>
> A managed Bean for "employeesSearch":
> -------------------------------------
> <managed-bean>
> <managed-bean-name>employeesSearch</managed-bean-name>
>
> <managed-bean-class>net.reumann.EmployeesSearchAction</managed-bean-class>
> <managed-bean-scope>request</managed-bean-scope>
> <managed-property>
> <property-name>employeesListBean</property-name>
> <value>#{employeesListBean}</value>
> </managed-property>
> <managed-property>
> <property-name>employee</property-name>
> <value>#{employee}</value>
> </managed-property>
> <managed-property>
> <property-name>searchCriteria</property-name>
> <value>#{searchCriteria}</value>
> </managed-property>
> </managed-bean>
I presume that "employeesListBean", "employee", and "searchCriteria" are all
the names of other managed beans? That would be necessary for this to work
correctly.
Also, the navigation rule you define above is not involved in the welcome
page processing ... but you might need it for other navigation in the app.
Result:
> -------
> EmployeesSearchAction has a prerender() that fires when index.jsp is hit
> and the user is forwarded to the employeesSearch.jsp screen.
To be a little pedantic, the order of events is actually slightly different
than this:
* The welcome JSP page forwards to the "/employeeSearch.jsp" view
(you are correct to use the ".faces" extension here to trigger the JSF
lifecycle, but the view identifiers inside JSF actually use ".jsp").
* The JSF lifecycle tries to execute Restore View, and notices that
there is no previous state to restore. It creates a new component
tree, and forwards to Render Response phase.
* The init() method of your view controller gets executed the first
time that the corresponding managed bean (employeesSearch)
gets created. *Before* that call, the managed properties will already
have been evaluated and set, by sub-evaluations of the expressions
used to initialize them.
* The prerender() method of your view controller gets fired
(by Shale, in a pre-render-response phase listener).
* The actual Render Response logic causes a RequestDispatcher.forward()
call to the JSP page itself.
* The destroy() method of your view controller gets fired.
Question:
> ---------
> Is the above the approriate way to handle an etnry point into an
> application when typically you want to go to somewhere different than
> the initial index page and you need a prerender to fire in a backing
> bean in order to setup that resulting page you forward(redirect) to?
Yep, this approach makes sense. Note that it also works in exactly the same
way if you navigate to the "/employeesSearch.jsp" view from anywhere else in
the application ... it's not just for the initial welcome screen.
Craig
