W3C home > Mailing lists > Public > www-forms@w3.org > September 2005

RE: Selected attribute in case element

From: Rafael Benito <rbenito@satec.es>
Date: Thu, 1 Sep 2005 09:54:35 +0200
To: "'John Boyer'" <boyerj@ca.ibm.com>
Cc: <www-forms@w3.org>, <www-forms-request@w3.org>
Message-ID: <E1EAjuM-00054x-7L@lisa.w3.org>
Let me share with you our experiences in this field. We developrd a product
for PDAs implementing a subset of  the current XForms spec with some
changes. One of them was to extend the selected attribute to a XPath
expression. When the switch block is evaluated, those controls that are "not
selected" are not even shown to the end user. If a change in the model that
affects the XPath expression is made, among other things, the UI is
refreshed to take it into account. There is the UI binding you mention. In
our implementation "relevant" produces the effect to disable controls but
they are still shown to the user. The selected attribute produces the effect
of not even displaying them.
This has proved very useful in many of the applications we develop using our
tool. In fact, in our subset, toggle is absent because we thoght the
selected extension made it unnecessary. The problem of what to do if more
than one or none are evaluated to true, I think it is common to our
implementation and to the W3C Recommendation. If I remember it right, some
paragraphs are included telling what to do under that circumstances.
Probably we are deriving more into procedural XML scripting than was
intended by the XForms group but still useful.
Rafael Benito


De: John Boyer [mailto:boyerj@ca.ibm.com] 
Enviado el: miércoles, 31 de agosto de 2005 19:25
Para: Rafael Benito
CC: www-forms@w3.org; www-forms-request@w3.org
Asunto: Re: Selected attribute in case element

There are several attribute that currently have literal values only but
which would benefit from 
an XPath expression.  We are looking at, possibly for 1.1, addressing some
of these concerns. 

This is the first I've heard of needing it for selected, though this may be
because we'd like to 
do something for the case attribute of toggle, which would be almost as
effective (i.e. allow the 
same flexibility, though with a bit more effort). 

The three biggest needs are the control attribute on setfocus, the case of a
toggle, and the 
action of a submission. 

We think we should be able to use the notation of th e"attribute value
template"  In other words, 
if the attribute's value is surrounded by curly braces {}, then treat it as
an xpath and take the result 
as the value of the attribute. 

In 1.1, we would more likely focus on the three mentioned above because they
are evaluated at 
a specific moment in time as opposed to requiring constant update based on
changes of data. 
Adding an xpath to the selected attribute of case would be like creating a
UI binding in that it would 
have to be notified for any change of referenced data.  We'd then climb into
dynamic UI bindings 
being needed, and of course dealing with conflicts (what if all report false
or more than one is true). 

John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

"Rafael Benito" <rbenito@satec.es> 
Sent by: www-forms-request@w3.org 

08/29/2005 03:56 AM 



Selected attribute in case element



I would like to know if to enhance the "selected" attribute of a case
element to accept an Xpath expression evaluated to boolean and not only
"true" or "false" was ever considered. This gives the switch case structure
a more dynamic nature, similar to what can be achieved with "relevant". 


Rafael Benito Ruíz de Villa
Responsable Sistemas de Negocio en Red
Móvil (+34) 617 314 293
 <mailto:rbenito@satec.es> rbenito@satec.es 

MADRID <http://www.satec.es/>  

Avda. Europa, 34 A
28023 Aravaca
Telf.: (+34) 91 708 90 00 / 91 211 03 00
Fax: (+34) 91 708 90 90 / 91 211 03 90 

(image/gif attachment: ATT00007.gif)

(image/gif attachment: ATT00010.gif)

Received on Thursday, 1 September 2005 07:57:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:15 UTC