cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Gruber <>
Subject Re: reworking CForms Repeater
Date Fri, 30 May 2008 06:19:23 GMT

Hi Jeremy,

I'll try to give some feedback from my side. I am a heavy CForms user with
50+ forms mainly handling hibernate objects.

Jeremy Quinn wrote:
> The Dojo DnD libraries have more capabilities than are currently  
> supported in CForms. I am trying to work out which are realistic to  
> implement here.
> 1. move more than one row at the same time within a single Repeater
> 2. clone row(s) within a single Repeater
> 3. move row(s) from one Repeater to another
> 4. clone row(s) from one Repeater to another
> ....

In general the cloning option would be really a nice feature where I can
think of some usecases in our apps. We are using repeaters quite often and
it would indeed be nice to be able to clone an existing row. [Allthough I am
pretty sure you can do it with a custom CForms Action on the serverside by
creating a new Row and adding the content by hand.]

Jeremy Quinn wrote:
> The immediate problem I am facing is twofold :
> 1. We are adding rows, so the User's 'add-row' handler should probably  
> get the opportunity to run. It currently does not, so in the example  
> (based on: samples/blocks/forms/do-dojoRepeater.flow) the cloned  
> row(s) do not get a new unique ID.
> How do I ensure User handlers get executed?
> 2. All of the samples of 'add-row' handlers I see make the assumption  
> that the row that has just been added, has been added at the end of  
> the Repeater, eg.
> 	repeater.getRow(repeater.getSize() - 1).getChild("ID").setValue(count);
> Now we are using DnD, this assumption is no longer true, there may be  
> more than one new row and they may not be at the end.
> Should or do we have a way to find out what was added, from within a  
> User handler?
> Will this type of cloning cause problems further down the line, when  
> for instance it is used to edit a Repeater that represents a  
> Collection of Beans persisted via ORM (etc.)?
> ...

As you already stated it is absolutely necessary that in case of ORM binds
being binded that new rows get a NULL identifier. That means that the widget
which is declared in the <on-bind> section of the corresponging binding-xml
file does not get the value of the repeater-row, from where it was copied. 
In hibernate for instance these rows (with null identifier-widgets) would be
then saved as new objects to the database (if binding was done right).

In general I would prefer a solution which supports the old behavior and
events if possible.


View this message in context:
Sent from the Cocoon - Dev mailing list archive at

View raw message