W3C home > Mailing lists > Public > public-forms@w3.org > November 2010

Re: Proposal for Exists+Events+in/visible

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:54 UTC