RE: Selected attribute in case element

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
SATEC
 
 

  _____  

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 


To
<www-forms@w3.org> 

cc

Subject
Selected attribute in case element

	





Hi, 


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". 


Regards, 


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