- From: T.V Raman <raman@google.com>
- Date: Wed, 2 May 2007 16:41:14 -0700
- To: Leigh.Klotz@xerox.com
- Cc: boyerj@ca.ibm.com, public-forms@w3.org
Sorry I missed today's call. One way to think of readonly vs relevant on things like triggers based on XForms' model-centric design: enabled trigger == the rendered control is actually wired to something. readonly == the bound data item is readonly So for instance, it makes perfect sense to bind a repeat to a nodeset containing 20 nodes, and have the repeat displaying upto 5 items, and to have triggers that scroll the repeating list. Now, if an input control (or any other control that mutates data ) is bound to a data node that is readonly then that control becomes disabled -- but it's not purely a consequence of MIP "readonly" -- but rather as a consequence of two bits: A) Control mutates data B) Bound data is immutable Thus, an input control that is bound to a readonly node can essentially become an output control. Klotz, Leigh writes: > John, > Here's my opinions on this summary: > > I think the key thing we came up with was that, unlike the recent notice > that disabled form controls don't receive events, we are *not* going to > say that about trigger bound to readonly node. That appears to be point > 1. We also decided that readonly has no effect on trigger's behavior in > other unspecified ways, so that's point 2a. > > As for point 2b, Im not sure a "countenance". If it means style, and > the host language supports some styling mechanism such as CSS, an author > (or user agent default) can certainly style it however desired. Our > informative CSS3 style sheet does show anything for xf|trigger:readonly > but I don't see how we can proscribe it. (I think Mark Birbeck made the > argument that we should avoid saying anything about presentation here, > but maybe I'm confused.) > > I'd be happier to see these two responses split up: > - Put (1) and (2a) in the spec document as an inforamative note. > - The body of (2) remains where it is (the minutes, this discussion) but > not in the spec document. > - Change 2b to an email response and say we aren't putting anything in > our informative CSS style sheet section for xf|trigger:readonly. > > I suspect that some implementations might use XBL or some other > customization mechanism to take advantage of the readonly MIP or the > :disabled CSS pseudo-property to affect behavior, and again, while we > might think it's unclean to do so, we can't really prohibit it; at the > same time, we have recognized the request already for extensible MIPs > for use in styling and XBL binding, so I don't think we need to act > further on this for XForms 1.1. In other words, those who have XBL or > their own extension mechanism are allowed to warp trigger:disabled > behavior and style, but should know that it's not the path going > forward, and they probably want to pay attention XForms futures for > extensible MIPs. > > How does this all sound? > Leigh. > > > ________________________________ > > From: public-forms-request@w3.org [mailto:public-forms-request@w3.org] > On Behalf Of John Boyer > Sent: Wednesday, May 02, 2007 12:53 PM > To: public-forms@w3.org > Subject: Conclusion to effects of readonly on trigger > > > > I think we were pretty close to a conclusion on the telecon about the > interpretation of the readonly MIP for trigger. > > Whatever the decision, it seems worthwhile make note of it in the spec > given that we had some work to do getting through the points ourselves. > > Let's see if we can get this wrapped up on the list during the week > and/or get a clear statement of resolution that folks can vote on next > week if necessary. > > Here is what I understood from the discussion: > > 1) Like all other events for MIPs, the xforms-readonly and > xforms-readwrite events are received by a trigger bound to a node (when > the processing model says those events are to be dispatched, of course). > > > 2) The readonly MIP is a statement about the what can happen to the data > node. Since a trigger does not directly manipulate the data node via > its UI binding, there is no direct relationship between the data node > being readonly and presentational properties of the trigger. > Specifically, > > a) The ability to activate a trigger is not disabled if the trigger is > bound to a readonly node > b) The default countenance of the trigger is unaffected, i.e. it does > not take on a disabled countenance > > Cheers, > John M. Boyer, Ph.D. > STSM: Lotus Forms Architect and Researcher > Chair, W3C Forms Working Group > Workplace, Portal and Collaboration Software > IBM Victoria Software Lab > E-Mail: boyerj@ca.ibm.com > > Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer > > -- Best Regards, --raman Title: Research Scientist Email: raman@google.com WWW: http://emacspeak.sf.net/raman/ Google: tv+raman GTalk: raman@google.com, tv.raman.tv@gmail.com PGP: http://emacspeak.sf.net/raman/raman-almaden.asc
Received on Wednesday, 2 May 2007 23:41:32 UTC