Re: Best practices for choosing managed bean scope
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
Re: Best practices for choosing managed bean scope
Hi, to my knowledge, in trinidad client side state saving is not comparable to the myfaces` equivalent. It goes more to server side state saving. But i would refer to trinidad user list or their project documentation in order to get out more on this topic (if you really want to use it). 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
Re: Best practices for choosing managed bean scope
I think Adam Winer was developing something to improve client side state saving. Not sure if this made it into the code base. If you are planning on a system with a large # of simultaneous requests, you may want to do some preliminary stress testing with client side state saving. Dennis Byrne >-Original Message- >From: Naresh Bhatia [mailto:[EMAIL PROTECTED] >Sent: Tuesday, September 19, 2006 12:38 AM >To: 'MyFaces Discussion' >Subject: RE: Best practices for choosing managed bean scope > >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 >> > >
RE: Best practices for choosing managed bean scope
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 >
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 >
Best practices for choosing managed bean scope
Title: 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
