cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: reworking CForms Repeater
Date Fri, 30 May 2008 19:43:10 GMT

On 30 May 2008, at 07:19, Gabriel Gruber wrote:

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

Thanks Gabriel

> 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.]

Correct, the current dojo-repeaters sample using  
CFormsDragAndDropRepeater works like this. It requires you to supply  
your own clone function named in the 'dnd-action' parameter.

Part of what I am trying to do is to remove this requirement, by  
providing generic clone handlers, much like the generic 'move' handler  
(used for moving a row within a single Repeater). I am adding 'copy',  
'copy-to' and 'move-to', where the '*-to' handlers work between  

> 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).

Yes, thanks for reminding me.

These are the steps that take place :
1) On the client-side a row-clone operation is performed.
2) The client sends an Ajax Request with parameters that specify what  
is being cloned and to where, plus which handler should be run.
3) The generic handler calls Repeater.addRow which builds a new row  
from the Template and runs the binding (?).
4) The handler recursively copies the values from the source row to  
the target row.
5) The changed Repeater(s) are rendered and their html replaces the  
content in the client-side.

So the problem is this, I think :
Regardless of whether the binding runs in step (3) or not, the handler  
does not know which field is being used to hold the ORM identifier, so  
would copy it, if it were in the model.

Is it realistic to have a CForm which usefully edits and creates  
Objects /without/ the CForm Model containing the ORM identifier?  
(AFAIK, there is no immutable widget).

(I don't actually /know/ when or if the binding happens in this  

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

I am not planning on changing the existing Request parameters, except  
because I am supporting move/copy on several rows simultaneously, I am  
allowing the 'from' parameter to be a value-list instead of just a  
single value.

I also plan to leave in support for 'dnd-action', so that the built-in  
handlers may be optionally replaced by custom a user-supplied handler  
in the model.

Thanks for the feedback

regards Jeremy

BTW. The other big change that is happening to repeaters is that you  
would no longer specify the particular dojo widget to use in your  
Template (this was bad for lots of reasons IMHO). There will be a  
couple of extra optional parameters on the repeater in the model to  
control what is allowed to be dragged into it and a few new stylings  
in the template to control the styling and behaviour of dnd (it will  
be off by default). Form generation via JX Macros will output repeater  
tags, there will once again be built-in xslt to render repeaters.


View raw message