Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 77015 invoked from network); 21 Jun 2005 08:50:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 21 Jun 2005 08:50:54 -0000 Received: (qmail 40522 invoked by uid 500); 21 Jun 2005 08:50:53 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 40289 invoked by uid 500); 21 Jun 2005 08:50:52 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 40272 invoked by uid 99); 21 Jun 2005 08:50:51 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Jun 2005 01:50:51 -0700 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=HTML_40_50,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [207.234.129.118] (HELO mailgwvw01.freelance.com) (207.234.129.118) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Jun 2005 01:50:53 -0700 Received: from mailgwvw02.freelance.com (mailgwvw02.freelance.com [207.234.129.52]) by mailgwvw01.freelance.com (8.12.3/8.12.3) with ESMTP id j5L8oqvE022960; Tue, 21 Jun 2005 10:51:20 +0200 Received: from [192.168.0.2] ([82.123.235.1]) by mailgwvw02.freelance.com (Lotus Domino Release 5.0.12) with ESMTP id 2005062110495425:8590 ; Tue, 21 Jun 2005 10:49:54 +0200 Subject: Re: New "initId" attribute From: Sylvain Vieujot To: Manfred Geiler Cc: John Fallows , MyFaces Development In-Reply-To: <564d4f680506210033744ccd0d@mail.gmail.com> References: <83caac420506201336b86bc48@mail.gmail.com> <1119305172.3422.70.camel@sv> <83caac42050620171463ceaf5b@mail.gmail.com> <564d4f680506210033744ccd0d@mail.gmail.com> Date: Tue, 21 Jun 2005 04:50:07 -0400 Message-Id: <1119343807.3422.137.camel@sv> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) X-MIMETrack: Itemize by SMTP Server on mailgw01/Freelance(Release 5.0.12 |February 13, 2003) at 06/21/2005 10:49:54 AM, Serialize by Router on mailgw01/Freelance(Release 5.0.12 |February 13, 2003) at 06/21/2005 10:50:13 AM, Serialize complete at 06/21/2005 10:50:13 AM Content-Type: multipart/alternative; boundary="=-rDpwQguNmfTFd/tzQ3AI" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mailgwvw01.freelance.com X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on mailgwvw01.freelance.com X-Virus-Status: Clean X-Old-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE autolearn=no version=2.63 X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --=-rDpwQguNmfTFd/tzQ3AI Content-Transfer-Encoding: 7bit Content-Type: text/plain I agree with Manfred that preserveDataModel is quite efficient in it's implementation. But it doesn't solve the same kind of problem. preserveDataModel allows you to keep user modifications between requests. rowId would allow you to avoid concurrency problems as just using the preserveDataModel can't be safely used to modify critical data. The rowId approach is absolutely safe and efficient as no data is stored. It's also a very light modification as only the UIData.getClientId needs to be overridden. By the way, maybe a more explicit attribute name would be rowClientId. Sylvain. On Tue, 2005-06-21 at 09:33 +0200, Manfred Geiler wrote: > What do you mean by "preserveDataModel is too aggressive"? > It was introduced to exactly solve this common problem. Fact is, we > want UI components that behave as simple as fat client components > (Swing) do. What we expect is, that when an action is fired, a table > must not be changed in the meantime (regardless of what happend > technically in the meantime: response, request, post parameteres, > etc.). A data refresh must not happen before the new render phase > starts. And: the component user should not have to bother with these > kind of issues. Only thing he needs to worry about: the row objects > must be Serializable and should be lightweight. If they are not, than > wrap them! That's the difference between business objects and GUI > display objects as was mentioned before in this thread. > BTW, preserveDataModel does only save the 5 displayed rows of the > 1000. So, for 99% of user interfaces (where there are not displayed > 1000 rows on one page) the saved DataModel does not blow up the > transferred data amount at all. > > -Manfred > > > 2005/6/21, John Fallows : > > Hi Sylvian, > > > > On 6/20/05, Sylvain Vieujot wrote: > > > The solution you propose with an attached state is the same as the > > > x:dataTable's preserveDataModel attribute which solves the problem by ... > > > storing the data model. > > > > I was quite deliberate in avoiding the assumption that we would need > > to store the entire data model, and I agree that preserveDataModel is > > too aggressive in this regard. > > > > Wouldn't it be sufficient to only capture the mapping for rows > > currently being displayed? > > > > For example, even if the whole data model has 1000 rows, but only 5 > > are being displayed, why would we need the mapping for the other 995 > > rows that are not displayed? > > > > Kind Regards, > > John Fallows. > > --=-rDpwQguNmfTFd/tzQ3AI Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8 I agree with Manfred that preserveDataModel is quite efficient in it's implementation.
But it doesn't solve the same kind of problem.
preserveDataModel allows you to keep user modifications between requests.
rowId would allow you to avoid concurrency problems as just using the preserveDataModel can't be safely used to modify critical data.

The rowId approach is absolutely safe and efficient as no data is stored.
It's also a very light modification as only the UIData.getClientId needs to be overridden.

By the way, maybe a more explicit attribute name would be rowClientId.

Sylvain.

On Tue, 2005-06-21 at 09:33 +0200, Manfred Geiler wrote: 
What do you mean by "preserveDataModel is too aggressive"?
It was introduced to exactly solve this common problem. Fact is, we
want UI components that behave as simple as fat client components
(Swing) do. What we expect is, that when an action is fired, a table
must not be changed in the meantime (regardless of what happend
technically in the meantime: response, request, post parameteres,
etc.). A data refresh must not happen before the new render phase
starts. And: the component user should not have to bother with these
kind of issues. Only thing he needs to worry about: the row objects
must be Serializable and should be lightweight. If they are not, than
wrap them! That's the difference between business objects and GUI
display objects as was mentioned before in this thread.
BTW, preserveDataModel does only save the 5 displayed rows of the
1000. So, for 99% of user interfaces (where there are not displayed
1000 rows on one page) the saved DataModel does not blow up the
transferred data amount at all.

-Manfred


2005/6/21, John Fallows <john.r.fallows@gmail.com>:
> Hi Sylvian,
> 
> On 6/20/05, Sylvain Vieujot <svieujot@apache.org> wrote:
> >  The solution you propose with an attached state is the same as the
> > x:dataTable's preserveDataModel attribute which solves the problem by ...
> > storing the data model.
> 
> I was quite deliberate in avoiding the assumption that we would need
> to store the entire data model, and I agree that preserveDataModel is
> too aggressive in this regard.
> 
> Wouldn't it be sufficient to only capture the mapping for rows
> currently being displayed?
> 
> For example, even if the whole data model has 1000 rows, but only 5
> are being displayed, why would we need the mapping for the other 995
> rows that are not displayed?
> 
> Kind Regards,
> John Fallows.
>
--=-rDpwQguNmfTFd/tzQ3AI--