- From: John Boyer <boyerj@ca.ibm.com>
- Date: Wed, 3 Nov 2010 09:45:37 -0700
- To: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
- Cc: "Forms WG" <public-forms@w3.org>
- Message-ID: <OFB1FCAF0C.71F7D5A3-ON882577D0.005954AB-882577D0.005C1257@ca.ibm.com>
We've done such a huge amount of work, and it behooves us to review that work relative to new proposals for solving problems we may have already worked on. This is an example. One issue with this proposal is that it seems to only be good at assigning one property, due to being expressed as an attribute. What if you want more than one? Space-separated lists are a marginal solution when static, but imagine how bad it would be when computed. By comparison, check out this module Nick wrote not that long ago: http://www.w3.org//MarkUp/Forms/specs/XForms1.2/modules/model/bind/index-all.html esp. http://www.w3.org//MarkUp/Forms/specs/XForms1.2/modules/model/bind/index-all.html#N65990 Now, I personally prefer the name 'property' over 'mip', but that's minor compared to the difference in structure. Each custom property has its own element, so the expression that drives its dynamism is separated from other properties on the same node. We'd also have the ability to separately set the context of each property expression. Another difference relative to the proposal below is that the element version above has a type attribute that allows us to indicate what is the expected result of the property whereas the proposal below seems to assume only boolean properties. That aspect of the element version could be seen as an advantage because it is generalized. For example, all existing MIPs could alternatively be expressed using the property element. An advantage of the proposal below is that it maps to existing limitations in CSS properties, although we have worked around that limitation with pseudo-elements. However, if the limitation to boolean properties is desired, that could be as simple as not having a type attribute on the property element for now. In other words, it still seems better to design for the long term and choose a direction that has better growth potential as long as doing so doesn't significantly obfuscate, which does not appear to be the case here (in fact, the separation of multiple properties seems to do the opposite). Anyway, the meta-issue is that we have already discussed a number of issues that we now still face, and we have already created a number of solutions for them. Perhaps taking stock of those would be a good idea. Quite a few solutions appear in the specs/XForms1.2/modules directory, and further discussion and solutions appear here: http://www.w3.org/MarkUp/Forms/wiki/XForms_2.0_Refactoring Cheers, John From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> To: "Forms WG" <public-forms@w3.org> Date: 11/03/2010 08:12 AM Subject: Proposal for Exists+Events+in/visible Following on from our discussion yesterday, a strawman proposal that also covers my more general case: <bind ref="sum" property="if(.<0, 'negative', '')"/> ... <output ref="sum"><label>Total: </label></output> with CSS: output.negative {color: red} How a bound property maps to controls is host-language dependent, but for XHTML it would add the property name to @class. Steven
Received on Wednesday, 3 November 2010 16:46:19 UTC