[whatwg] Order of repeating blocks; other misc comments

[Ian Hickson]

On Mon, 28 Jun 2004, Stuart Ballard wrote:
>
> As I understand the current draft, the only way to determine the order
> that individual blocks appeared in a form submission is the order that
> they occur in the posted data. This doesn't work well with existing
> server-side systems, where that information is often unavailable. It
> seems to me that working with existing server-side technology is just as
> important for adoption as working with existing client-side tech.

In my research, I found that while the exact order of all the controls was
often unavailable (which is what spawned the whole [id] stuff in the first
place), the order of values of a particular field were all available. That
is, most often the data would be returned in the form of a hash (or
equivalent structure) with the names in an order different than the
submission order, but the values for each name given in the submission
order. As in:

   real submission:
      fieldB=10
      fieldB=20
      fieldA=1
      fieldB=30
      fieldA=2

   resulting data structure:
      fieldA = 1, 2
      fieldB = 10, 20, 30

If you have the order of the values, then you need just include a single
hidden control:

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

...and then when you get the data back, process it in the order given by
the field named "order". This is what I do in the demo:

   http://whatwg.org/demos/repeat-01/


> Proposal #1:
>    For each instantiation of the template, the instantiation itself
> contains an implied successful form control with the name
> (templateId).(index).position, eg (for the example in section 3.1 of the
> draft) "order.1.position". The index here is the same index used for
> other form controls in the record. The value of this form control is the
> position that this record has been moved to by 'up' and 'down' buttons.

This is pretty much what happens in the XML submission model.


> Another issue: I didn't see a way to initially populate the *values* of
> form fields in repetition blocks. If you're manipulating an order form,
> it's quite possible, if not likely, that the form has some initial data
> that needs to appear. It's not clear from the draft whether it's
> permitted to actually fill in the contents of the initial state of
> repetition blocks (if it is, that raises all sorts of other questions,
> like what if the initial content doesn't match the template) but if it
> isn't, how do you initially populate the form fields?

Just include the repetition blocks with the values prefilled. There is
nothing special that happens if the repetition block is different than the
template.

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