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.
Regards,
Gabriel
--
View this message in context:
http://www.nabble.com/reworking-CForms-Repeater-tp17489343p17552351.html
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
