Return-Path: Delivered-To: apmail-myfaces-users-archive@www.apache.org Received: (qmail 84982 invoked from network); 13 Jul 2007 13:11:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Jul 2007 13:11:13 -0000 Received: (qmail 52843 invoked by uid 500); 13 Jul 2007 13:11:10 -0000 Delivered-To: apmail-myfaces-users-archive@myfaces.apache.org Received: (qmail 52817 invoked by uid 500); 13 Jul 2007 13:11:10 -0000 Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Discussion" Delivered-To: mailing list users@myfaces.apache.org Received: (qmail 52806 invoked by uid 99); 13 Jul 2007 13:11:10 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jul 2007 06:11:10 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [207.236.211.109] (HELO mx1.optimumgroup.com) (207.236.211.109) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jul 2007 06:11:07 -0700 Received: from mx1.optimumgroup.com [10.10.0.190] by mx1.optimumgroup.com - SurfControl E-mail Filter (5.5.0); Fri, 13 Jul 2007 09:09:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C54E.B6AE8CDF" Subject: RE: Trinidad table paging Date: Fri, 13 Jul 2007 09:07:06 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Trinidad table paging Thread-Index: AcfFLE+bJqqbJzmVSEi4khgW5WngbwAHoCkg References: From: "Laperle, Denis" To: "MyFaces Discussion" X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-Processed: 5_5_0_191__2007_07_13_09_09_52 X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C54E.B6AE8CDF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Francisco =20 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. =20 I will add some navigation cases and see what else I need to save within = process scope variables in a typical CRUD application. =20 Thank you =20 Denis =20 ________________________________ De : Francisco Passos [mailto:francisco.passos@gmail.com]=20 Envoy=E9 : 13 juillet 2007 05:00 =C0 : MyFaces Discussion Objet : Re: Trinidad table paging =20 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.=20 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: Hello =20 I'm trying to code a single page JSF application to get familiar with = Trinidad components (1.0.1) and the JSF framework. =20 I simply click on a command button to execute a method initialising a = List property of a managed bean (scope=3Drequest) and use a tr:table = component to display the 25 first element of the list. =20 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. =20 I just want to be sure that it's a normal behaviour and not something = I'm doing wrong. =20 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. =20 Please help clarifying this. =20 =20 ------_=_NextPart_001_01C7C54E.B6AE8CDF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Francisco<= /p>

 

=

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.

 

=

Thank = you

 

=

Denis

 =


De : = Francisco Passos [mailto:francisco.passos@gmail.com]
Envoy=E9 : 13 = juillet 2007 05:00
=C0 : 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 <DLaperle@optinf.ca> wrote:

Hello

 

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=3Drequest) 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.

 

 

------_=_NextPart_001_01C7C54E.B6AE8CDF--