RE: Selected attribute in case element

Hi Rafel,
 
Your suggestion has come up on a number of occasions. Speaking for myself I
have always been against it, as I'll try to explain.
 
In XForms we have a number of different ways that activities can be
'driven'. Some are more akin to the traditional procedural model, in that
they are controlled by actions. Toggling one of the xf:cases in a xf:switch
is in this category.
 
Another way to perform actions is to state your intentions using declarative
mark-up, and then let the processor take care of the rest. Using @relevant
on xf:bind falls into this category, since when the state of a data node
changes, *all* bound UI controls have their CSS classes updated to reflect
this, without the author having to use actions to do this.
 
By requesting that xf:case/@selected have an XPath statement you are mixing
up these two 'modes', which would make for a difficult architecture. In
particular, an unwritten, but important, design principle is that the UI
cannot be out of step with the data model. With your proposal, what should
happen if a case is toggled by an action, but the @selected statement
implies a different state? Should the action be ignored? The data model
updated?
 
To achieve the functionality you want you can simply use xf:group with
@relevant. This gives you complete flexibility, including the ability to
have more than one 'case' active. (You'll also find if you look at the RSS
Reader that comes with formsPlayer that you can create far more complex
structures than you can ever create with xf:switch/xf:case, in particular
each 'case' not requiring a common 'switch' parent.)
 
I'm not saying by the way, that there couldn't be a model-driven version of
xf:switch/xf:case added to XForms--this could be an abbreviated version of
the very flexible technique I have described using xf:group-- but what I am
saying is that I believe xf:switch/xf:case/xf:toggle should be left alone,
and any further features added in some other way.
 
Regards,
 
Mark
 
 

Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/ 

 


  _____  

From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
Of Rafael Benito
Sent: 01 September 2005 08:55
To: 'John Boyer'
Cc: www-forms@w3.org; www-forms-request@w3.org
Subject: 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