cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject reworking CForms Repeater
Date Tue, 27 May 2008 12:29:29 GMT
Hi All

I am re-working CForms at the moment, upgrading the client-side to  
Dojo 1.1.
I am currently working on Repeaters, specifically rationalising their  
DnD behaviour.

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

I got item #1 working, by sending a list of source row indexes instead  
of just one, and process accordingly in  
o.a.c.forms.formmodel.Repeater's built-in 'move' action.

I am now working on item #2, and am at the proof-of-concept stage.

Dojo allows the user to clone rows by holding down a meta key (CTRL on  
PCs, Command on Macs, etc.) during the drag.

I am trying to work out if it is going to be realistic to have generic  
support for row-cloning in CForms Repeater, instead of forcing the  
User to write their own by hand, as is the case with the usage of the  
old CFormsDragAndDropRepeater.

I added a new built-in action to o.a.c.forms.formmodel.Repeater,  
called 'copy'. It reads the Request parameters to get the list of  
source rows and the destination row.
It adds new rows at the destination then copies across the values of  
each of the widgets in the row. Being proof-of-concept there is no  
support for nested ContainerWidgets yet, but it basically works.

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

Many thanks for any feedback!!

best regards


View raw message