I'm now using the process scope feature of Trinidad and it's works fine but it means that I will have to clear the process scope context manually at the appropriate time within the application to avoid high memory consumption on the server side.
I will add some navigation cases and see what else I need to save within process scope variables in a typical CRUD application.
De : Francisco Passos
Envoyé : 13 juillet 2007 05:00
À : MyFaces Discussion
Objet : Re: Trinidad table paging
As I have come to understand, this is expected. Although personally I believe it is not intuitive at all for any user.
What happens is your bean is request scoped and as such its contents are lost when you make the second request. What you need is either request-scoped state saving (for instance using Tomahawk's saveState component) or using Trinidad's processScope, which I'm convinced uses session-scoped variables to keep state in a clever way.
Personally I'm using t:saveState and everything works like a charm - table paging and inner table support (having tables render inside a column of a table) with paging.
On 7/12/07, Laperle, Denis wrote:
I'm trying to code a single page JSF application to get familiar with Trinidad components (1.0.1) and the JSF framework.
I simply click on a command button to execute a method initialising a List property of a managed bean (scope=request) and use a tr:table component to display the 25 first element of the list.
If I use the built-in paging support of the tr:table component to see the 25 next elements, the list elements disappears and a new managed bean gets instantiated.
I just want to be sure that it's a normal behaviour and not something I'm doing wrong.
If I set the managed bean with the session scope attribute it works fine but I thought it wouldn't be necessary to deal with session beans till I add some complexities like selecting an element in the list to display its detailed information on a second page.
Please help clarifying this.