With t:updateActionListener (embedded e.g. in a commandlink) you took out a value (mostly the id of an entity) and set it to any bean in the model where you can read it out and check to which entity the value corresponds.
I often use it in order to get a fresh entity out of a dataTable - fetching from db. t:saveState is the perfect choice if you want to get any beans which are more than request scope, but fewer than session scope. The usecase i currently use this approach: Page beans (gui representation in the model) which are used for a wizard. If you click forward or backward, the bean should always be the same. Hope this helps, cheers, Gerald On 9/19/06, Naresh Bhatia <[EMAIL PROTECTED]> wrote:
Thanks Dennis. I briefly looked at t:saveState and t:updateActionListener - don't think I understand them right now. You are right - the learning curve is pretty steep. Also doesn't Trinidad have some facilities that are supposed to be more efficient for saving state (org.apache.myfaces.trinidad.CLIENT_STATE_METHOD)? Naresh Bhatia Expert, Platform | Sapient desk: +1.617.761.1771 -----Original Message----- From: Dennis Byrne [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 12:22 AM To: MyFaces Discussion Subject: Re: Best practices for choosing managed bean scope Naresh, I would stick to the same knowledge you've used for scoping decisions in any web app. I have tended to favor request scope for the reasons you have mentioned. You may want to check out t:saveState and t:updateActionListener if you have not already. I think most experienced JSF developers will agree this unfortunately makes application development more expensive because of the learning curve and work required to manage state over a stateless protocol. I place read only managed beans in app scope. Dennis Byrne >-----Original Message----- >From: Naresh Bhatia [mailto:[EMAIL PROTECTED] >Sent: Monday, September 18, 2006 09:39 PM >To: 'MyFaces Discussion' >Subject: Best practices for choosing managed bean scope > >What are the best practices for choosing managed bean scope? In the >past, I have been avoiding session scope in favor of request scope for >obvious reasons (memory requirements, no need for session failover etc). >But I see that many JSF examples put beans in session scope without >explaining why this is needed. For example, the Trinidad TreeTable demo >puts its managed beans in session. Is this really necessary? Are there >any best practices in trying to decide the scope of managed beans? > >Thanks. >Naresh >
-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
