- From: Olav Junker Kjær <olav@olav.dk>
- Date: Sun, 16 Jan 2005 18:06:35 +0100
Hallvord R M Steen wrote: > Regarding submitting all the changes: A specific row in the table > could be submitted to a new window or another frame, or be submitted > without updating the page, and you could keep making other changes. Good point. With replace=data it definitely makes sense to update one row at a time. This is how database clients often work, you edit one row at a time and when focus leaves the row, the entire row is updated in the background. The WA1 datagrid should support something like this. The real problem is that there is no way to declare that all form controls in a single table row is part of the same dataset and should be submitted (and updated) as a unit, since HTML does not allow TR elements to be contained directly by a FORM. This is a serious problem, since tabular data which you want to edit "row by row" is exactly the type of data TABLE was intended for. (Somebody pointed out that this is actually possible in current browsers, but apparently this is supported only for the sake of backwards compatibility and involves scary hacks and shouldn't be relied on.) Anyway, It doesn't seem like the obvious solution to redefine the relationship between forms and form fields from simple containment to be many-to-many and orthogonal to document structure. But maybe its just because I understand the semantics of the form element incorrectly? I think of a form as as a grouping of related input fields which is edited by the user as a whole. By this understanding, it makes sense to have the form defined by containment. OTOH, if the form element is thought of more like the data model in XForms, then it makes sense to define the FORM separately from the input widgets, and allow widgets to bind to several data models. I dont think this fits too well with how forms usually are thought of in HTML, though. Regards Olav Junker Kj?r
Received on Sunday, 16 January 2005 09:06:35 UTC