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" <[EMAIL PROTECTED]> > 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
