[whatwg] Web Forms 2.0: Repeating blocks and move-up/move-down

[Ian Hickson]

On Thu, 27 Oct 2005, Ian Bicking wrote:
>
> I've been implementing a form repetition Javascript library, basing it 
> on the Web Forms spec as closely as I can.  But during that I've become 
> confused about the purpose of move-up and move-down, as well as other 
> things to define order (like having an add button inside a repetition 
> block).
> 
> Because these don't effect the index in any way (that I can see) and so 
> don't effect the names of any fields inside the repetition block, how is 
> the server supposed to make any use of the order?

The submission order reflects the order in which the user put the blocks.


> I suppose the order of the fields as submitted would indicate that, but 
> few web programming frameworks give easy access to that ordering, 
> especially for POST variables.

I guess this gives a good reason for those frameworks to change! :-) It's 
pretty simple to reflect this order.

Generally the order only has to be reflected in the context of a single 
field; for example, make all your repetition blocks contain:

    <input type="hidden" name="order" value="[row]">

...and then use the order of the values of the "order" field to read the 
data back out, with each "row"'s data having the [row] in the field name, 
as in:

    <input type="text" name="address[row]" value="">

So if you get back "2", "1", "4" as the values for "order", you know you 
have to read "address2", "address1", "address4" in that order.


> Even though it seems more complicated to implement, changing the 
> repetition index would make the reordering functionality much more 
> useful.

It would be REALLY difficult to do this.


> Considering it from an implementation perspective, I'd guess that when 
> creating a repetition block I'd track which attributes needed rewriting. 
> Then when changing the index (as would happen when reordering) I'd 
> re-rewrite those attributes.  E.g., I'd add a templateAttributes 
> property to any DOM node where I rewrote attributes when creating a 
> block, which would be a list of the original (unmodified) attributes.

This is a lot of data to keep track of, and makes the whole templating 
system much more stateful than it already is (at the moment you can 
serialise the DOM to XML and get it back and you've not lost any state).


> Tangentially, I wasn't clear how the template index was supposed to be 
> stored.  Is it a property of the template node?  Is it an attribute?

It's an intrinsic property of the template; the repetitionIndex DOM 
attribute returns it. It isn't stored in the content attributes. The index 
isn't actually that important, you can reload the entire DOM and the next 
time you need an index a new one will be determined that doesn't clash 
with the existing reptition blocks.


> Also, there's no example of using <input> tags for add/remove buttons. 
> These are (sensibly) discouraged; but if they are used, are they 
> expected to be used like <input type="add" value="Add a Block"> ?  
> I.e., as another input type?

Yes.


> There's also no specific description of .addRepetitionBlockByIndex(), or 
> what its intended use is.

It is defined in 3.6.1. It is used in sction 6.2.


> Lastly, it's occurred to me that a form like:
> 
>   <div repeat="template" id="foo">
>     <input type="hidden" name="foo-order" value="[foo]">
>     ...
>   </div>
> 
> would be easier to handle, as you could reorder the (unordered) input 
> based on the foo-order values, as most frameworks do preserve the order 
> of values when multiple variables with the same name are submitted, even 
> if they don't preserve any order between differently named variables. If 
> this is the intention, then some suggestion along those lines in the 
> spec would be useful.

Added a hint section on this (3.1.3).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'