- From: Avi Bryant <avi@beta4.com>
- Date: Fri, 25 Jun 2004 11:01:15 -0700 (PDT)
On Fri, 25 Jun 2004, Ian Hickson wrote: > I do agree that the [id] stuff is somewhat dodgy. I really am at a loss of > how to do a better solution, though. And it does work quite well. In other words: it's a useful hack. No argument there, as long as we agree that it would be nice to find something that *isn't* dodgy. > > Effectively you're upping the meta level: parts of the document are no > > longer HTML, but a description of how to produce HTML. > > HTML4 already has this (<object declare>). That's similar to having a a template without [id], but it doesn't set a precedent for macro expansion at all. <object declare> still treats the DOM as a semantic tree rather than as bits of text to be manipulated byte by byte, as the repetition model does. That's the part I find offensive. (Though at least the semantic rape is confined to attribute values). > I agree that the []-prefix hack is a hack. Do you have a better solution? My point is that the [id] hack necessarily begets other hacks, which is just further evidence of its hackishness. The only better solution is to get rid of [id]. > This is an interesting point. It means that if the author doesn't want any > of the [id] nonsense, he need simply not put an ID on the template, and > then that entire part of the model is simply ignored. I don't generally buy into that kind of argument. That way lies C++. An author may be able to confine themselves to a subset of the spec, but a browser vendor can't, and neither can a documentation writer, etc, all of which is going to indirectly affect the author even if he doesn't personally need the feature. If we can get rid of it wholly, we should. > There are cases where having uniquely numbered rows really helps with > the server-side processing (for example, some CGI libraries merge all > the values with the same name into one array, keeping the relative order > between individual control names, but losing the overall order that the > names came in). So, the problem is that with nested repeats you could end up with something like this (simplified): <div> <input name="customer" value="cust1"> <input name="account" value="account1"> <input name="account" value="account2"> </div> <div> <input name="customer" value="cust2"> <input name="account" value="account3"> </div> And on the server you'd have customer=[cust1,cust2] account=[account1, account2, account3] with no way to tell which accounts went with which customers. For people with CGI libs like that, one easy workaround would be this: after each set of repeats of a template, insert hidden fields with the same name as each input and and "end of group" marker value. For example: <div> <input name="customer" value="cust1"> <input name="account" value="account1"> <input name="account" value="account2"> <input name="account" type="hidden" value="--------"> </div> <div> <input name="customer" value="cust2"> <input name="account" value="account3"> <input name="account" type="hidden" value="--------"> </div> Then you end up with: customer=[cust1, cust2] account=[account1, account2, --------, account3, --------] Which would be trivial to assemble into the proper nested groups on the server side. > This is especially important with nested repeats, where > the "add" button has to refer to a template that has been repeated. > Templates are identified by IDs, so you need a unique ID for each > repeated template. (There's an example of this in the spec.) If buttons referred to templates by name instead of ID, this wouldn't be a problem - they would just be hooked up to the closest template of the right name (and I'm pretty sure we could find a suitable definition of "close").
Received on Friday, 25 June 2004 11:01:15 UTC