My opinion is that we should keep these two options as in some cases having
separate forms is exactly what someone might want. A few quick thoughts:
- there is an option to put the form elements in their own columns instead of
all in one, for either list or multi forms
- could we reduce redundancy without eliminating this option? yes, there is
some semi-redundancy but these are different things and do need some different
code (there shouldn't be much though...)
- is it really impossible with all form elements in a single cell to split
them? it makes it a little tricky, but you'd kind of just have two big cells
and split the elements between them
Anyway, I'm not really in favor of the idea of eliminating this functionality.
On the other hand, if the position attribute didn't do a good job with list
forms it wouldn't be the end of the world...
-David
Jacopo Cappellato wrote:
Right now a form widget type can be one of the following:
"single"/"upload" (for single forms)
"list" and "multi" for list based (tabular) forms
The main difference between "list" and "multi" forms is this:
a) in "list" forms, the input fields are grouped together into one form
that is put inside one cell of the row; for example, if we have a list
with 10 rows, we will have 10 forms, one per row
b) in "multi" forms, one big form is created (opened at the beginning of
the list and closed at the end) and the same input fields, in different
rows, are recognized using a special suffix/index; the suffix is then
stripped by the "service-multi" event handler
In my opinion we should always use one form per list (approach #b); so,
if a "list" form has the "target" attribute set (i.e contains input
fields) then it is rendered as a "multi" form.
Of course, if we want a button per row (as is now in "list" forms) we
could easily implement this by slightly improving the code responsible
for #b (for example, when the "submit" link is pressed, using Javascript
we could set to true an hidden field to select the row and then submit
the big form)
Advantages:
1) the code in ModelForm will be greatly simplified (there is a lot of
redundancy between list and multi forms)
2) the layout of input fields in "list" forms is ugly because we have to
put all the fields together into one cell
3) in the upcoming implementation of position attribute in list forms,
input fields could be in different rows (and with #a this is not possible)
What do you think?
Jacopo
