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.
good
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
Repeaters.
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
scenario)
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.
