Do we really need the type "multi" in form definitions?

[Jacopo Cappellato <ti...@sastau.it>]

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

Re: Do we really need the type "multi" in form definitions?

[Jacques Le Roux <ja...@les7arts.com>]

Hi Jacopo,

Just as a quick answer (did not look at the code) this seems like a good idea to me.

Jacques

De : "Jacopo Cappellato" <ti...@sastau.it>
> 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

Re: Do we really need the type "multi" in form definitions?

[David E Jones <jo...@hotwaxmedia.com>]

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