- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Fri, 02 Jun 2006 18:14:39 +0200
- CC: www-forms@w3.org
Mark Birbeck wrote: > Switch state is completely independent of the model, and should be > seen as comparable to the scroll position of a text area or the > open/close state of a drop-box. You could say the same for repeat index information, and in fact the WG is workin on enhanced separation between index state and model. However, this clearly does not mean that index state is no longer kept and appropriately updated upon insertion and deletion which operate on an instance, of course. The exact same pattern occurs with switch state within a repeat. > If an author wants more than this--i.e., to preserve the state > across various interactions with the form, or to associate a state > with a node--then they need to place the information in an instance > and use model-based switching. Again, the whole point of making switch work in repeat is to provide an alternative to model-based switching, which has certaily benefits but also serious drawbacks (i.e. you must design your instance to be able to hold nodes to which MIPs can be bound). > So I would say, that if a node is duplicated, for example, the > switch state is *not* duplicated, since it is completely unrelated > to the node itself. (It is in the UI, not the model.) The particular case of duplication can be discussed, but what about insertions and deletions? If switch within repeat cannot decently behave upon insertion or deletion, it becomes close to being useless for many practical purposes, and we could as well say that it is not supported. Again, I will point to the parallel with updates to repeat indices. The state of the indices is kept somehow, somewhere, and both model and control have access to it. The same should go for switch state, and whatever formulation we find in the spec to better specify the relationship between repeat indices and model should apply to handling switch state. Bottom line: I don't think independence of the switch state from the model is an argument in favor of not handling switch state correctly. -Erik -- Orbeon - XForms Everywhere: http://www.orbeon.com/blog/
Received on Friday, 2 June 2006 16:14:47 UTC