Return-Path: 
 <dev-return-69117-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 66785 invoked from network); 7 Dec 2004 14:36:08 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 7 Dec 2004 14:36:08 -0000
Received: (qmail 19547 invoked by uid 500); 7 Dec 2004 14:34:57 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 19392 invoked by uid 500); 7 Dec 2004 14:34:55 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 18952 invoked by uid 99); 7 Dec 2004 14:34:47 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Received: from viefep13-int.chello.at (HELO viefep13-int.chello.at)
 (213.46.255.15)
  by apache.org (qpsmtpd/0.28) with ESMTP; Tue, 07 Dec 2004 06:34:44 -0800
Received: from [192.168.1.31] (really [62.178.239.20])
          by viefep13-int.chello.at
          (InterMail vM.6.01.03.05 201-2131-111-107-20040910) with ESMTP
          id <20041207143414.OXCG8090.viefep13-int.chello.at@[192.168.1.31]>
          for <dev@cocoon.apache.org>; Tue, 7 Dec 2004 15:34:14 +0100
Message-ID: <41B5BF61.7040302@apache.org>
Date: Tue, 07 Dec 2004 15:34:09 +0100
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [cforms] Repeater and large collections
References: <41B5B011.7030908@apache.org> <41B5B515.6050207@apache.org>
In-Reply-To: <41B5B515.6050207@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Sylvain Wallez wrote:
> Reinhard Poetz wrote:

<snip/>

> Interesting problem... I understand that you don't want changes to be 
> committed when the user just asks for another page of the repeater.
> 
> That would require to hold a list of modifications "in front" of the 
> actual collection. By "in front", I mean that when populating the 
> repeater starting at a given index, you should check this collection for 
> modified/deleted rows and fall back to the actual data collection. That 
> would minimize the form data that must be held server-side.
> 
> The problem becomes tricky if you also want to allow reordering.

I think of holding a list of all repeater rows with data that has changed. A 
second list contains all rows that are displayed. When rendering the table, all 
rows of the "display-list" are shown, but if a modified row in the 
"modified-list" exists, its values are taken to be displayed.

The tricky part for me is the lazy loading from the business object because this 
  is in contradiction to the way how binding works today, isn't it?

Maybe we can work out a solution also including your binding ideas 
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109950611823830&w=2)

Anyway, I'm speaking withoug having looked into the code yet :-/ and I fear that 
it won't be easy to implement it, especially for me who hasn't touched cForms 
code in those deep layers yet.

>> WDYT? Other suggestions?
> 
> Something that really should be studied for this is the use of 
> XmlHttpRequest to post only row data and update only the table.

For tables and selection lists, yep.
One of the points that should be thought through before we mark cForms as stable ...

-- 
Reinhard