I printed your answer and hung it on my cubical wall, where it will continue to help me in the future.
24k gold, Thank you! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Monday, April 24, 2006 4:03 PM To: Struts Users Mailing List Subject: Re: [Shale] AbstractViewController for Dummies On 4/24/06, James Reynolds <[EMAIL PROTECTED]> wrote: > > > My understanding of the JSF lifecycle is a bit tenuous. As a result, > I'm confused about the proper use of init(), preprocess(), and > prerender(). Thus far, I've just been using init() and destroy() to > handle the creation and closing of Connections and other minor duties > because they have just worked for what I needed. Now, I'm moving on > with some more complex pages and I want to be sure that I'm leveraging > the AbstractViewController for all it's worth. > > The documentation does a good job of explaining when and under what > conditions the events are fired, however, my weakness is that I just > don't know what kind of jsf programming events to stuff in each one. > > "If I have a component that uses select items (that don't live in the > application or session scopes), should I build them in init() or > prerender()?" These are the kinds of questions I wrestle with. That's a really useful question to help you understand the differences. The short answer is "either of these will technically work". Some help, huh :-). But there is an important difference in behavior that can help you choose. * The init() method is *always* called if this view controller is ever instantiated. * The prerender() method is *only* called if the corresponding view is actually going to be rendered. If you have navigated to some different page, the prerender() method on *that* page's view controller will be called instead of this one. That can save you from having to do a bunch of expensive database queries that you do not need. So, one way to look at what event method should be used for what kind of application logic is to consider the following two questions: (1) Do I need the results of this computation in order to process a form submit? (2) Do I need the results of this computation in order to render the page? Based on the anaswers, I would suggest sorting things out like this: * Use init() for "(1) and (2)" * Use preprocess() for "(1) only" * Use prerender for "(2) only" And, you can always put any necessary cleanup code in destroy(). So, what's the answer for the use case you just described? It turns out that init() is actually the correct answer -- because when you the form for this view, the UISelectOne or UISelectMany component performs validation on the input value(s) against the set of select items that are defined. If you are not storing the items in session or application scope, then you will need to reload them in order for these validations to not fail. On the other hand, if you *did* have the select items in session or application scope, then you could move the logic to prerender() and only spend the effort to accumulate the items list the first time it is rendered. An actual issue that I'm working through now is this: I have a page that > lists 'Contracts'. If the user clicks one, the plan is to navigate to > a detail page, with the Contract's id number stored in the parameter map. > The detail page's backing bean needs to instantiate a Contract object > based on the id value, but do I do that in the bean constructor, the > init() or the prerender() methods? Does the detail page itself have a form that can be submitted back in again? If so, then init() would be the right place -- by the same logic as above (you need it for both form processing and rendering). If the page just has navigation links, prerender() would work. Any advice would be appreciated. > > Thanks Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
