RE: Can toggle@case or case@selected be calculated?

I couldn't have said Leigh's #1 better.

His #2 is probabaly just a matter of definition, so perhaps not a 
reasonable objection to your suggestiong, Roger.

However, a third issue is that we are attempting to contain the switching 
action within an actual action so that it is clear when the switch should 
occur.  Using xpaths for the selected attribute is actually a good 
suggestion, but it does leave open some details about when in a UI 
refreshment the case should actually be switched.

To be honest, we have a few remaining problems with switch.  For example, 
if you have events like xforms-invalid that go to controls in non-selected 
cases, do the action handlers execute?  Offhand I believe that the answer 
should be no based on what I believe is a a natural interpretation of the 
semantics of a switch.  I believe that a switch should behave as if the 
content of only one case 'exists' at a time.  The working group discussed 
the matter some time ago and assigned me the action item of making a 
correction that is similar to the above interpretation, except that it 
would be very careful to *not* use a wording that would suggest document 
DOM mutations but rather 'deactivation' of the content.

Anyway, due to completing scores of higher priority action items, I have 
not yet returned to this one, but when I do, it will be clearer that the 
timing of the case switch will have an effect on which controls get 
various UI refreshment messages.  In short, there would be a fair bit of 
picky technical work that would have to be done to fully articulate the 
idea you proposed.

In the meantime, we want to massively contain the scope of XForms 1.1 but 
at the same time at least solve the more immediate problem of how to make 
the toggle action more flexible. 

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

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





"Klotz, Leigh" <Leigh.Klotz@xerox.com> 
08/16/2006 11:01 AM

To
Rogelio Pérez Cano <rogeliop@satec.es>, John Boyer/CanWest/IBM@IBMCA
cc
<www-forms@w3.org>
Subject
RE: Can toggle@case or case@selected be calculated?






Two issues come to mind:
1. Currently @selected it's defined as an xsd:boolean (an enumeration of 
the strings "true", "false", "1", and "0".
Unfortunately, "true" isn't an XPath expression that evaluates to "true"; 
that would have to be "true()", so there's not the smooth upgrade path 
that it seems like there might be.
2. Question: What if you had more than one of @selected evaluate to true?

Leigh.

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf 
Of Rogelio Pérez Cano
Sent: Wednesday, August 16, 2006 9:14 AM
To: 'John Boyer'
Cc: www-forms@w3.org
Subject: RE: Can toggle@case or case@selected be calculated?


Hi all,
 
Maybe I´m missing something but I wonder why the selected attribute in a
<case> element is not an XPath expression convertible to XPath boolean?

Something like this: 


<switch>
  <case id="in" selected="some/node/your_name = 'yes'">
    <input ref="yourname">
      <label>Please tell me your name</label>
      <toggle ev:event="DOMActivate" case="out"/>
    </input>
  </case>
....
</switch>

>From my point of view, it could be really usefull, in that way you can 
have
a dinamic condition in the case.

Regards

Roger

________________________________

De: www-forms-request@w3.org [mailto:www-forms-request@w3.org] En nombre 
de
John Boyer
Enviado el: jueves, 10 de agosto de 2006 20:48
Para: mark.birbeck@x-port.net
CC: Flinton Adam; Kugelman, John; www-forms@w3.org; 
www-forms-request@w3.org
Asunto: Re: Can toggle@case or case@selected be calculated?



Also, for XForms 1.1 you will be able to selectively run a toggle based on 
a
condition using the 'if' attribute. 

It's not pretty but it works. 

Also, at the last face to face meeting, we explored an idea from Mikko
Honkala that allows us in XForms 1.1 to override an attribute value 
(@action
on submission) using a subelement. 

Speaking for myself, this idea looks really good to me because it allows 
us
to control where we add more variablility, so we can cleanly and more
quickly consider adding it where it is most needed, such as the toggle and
setfocus actions.  So, I would think you should be able to say something
like: 

<toggle ...> 
    <case value="concat('case-', some/node)"/> 
</toggle> 

or 

<setfocus ...> 
    <control value="concat('control-', some/node)"/> 
</setfocus> 

This is far superior to using 'if', but please beware that it's not
happening until our group agrees that it is! 

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

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





"Mark Birbeck" <mark.birbeck@x-port.net> 
Sent by: www-forms-request@w3.org 

08/10/2006 09:17 AM 
Please respond to
mark.birbeck@x-port.net


To
                 "Kugelman, John" <jkugelman@progeny.net> 
cc
                 "Flinton Adam" <Adam.Flinton@cfh.nhs.uk>, 
www-forms@w3.org 
Subject
                 Re: Can toggle@case or case@selected be calculated?

 





Hi John,

> Has the working group ever considered allowing the active case to be
> calculated declaratively, like relevance?

Yes, I think it's even in a requirements document somewhere!

However, some of the things you describe can already be done. For example:

>     <switch select="concat('case-', x)">
>       <case id="case-1"/>
>       <case id="case-1"/>
>       <case id="case-1"/>
>     </switch>

is:

 <group ref="x[text() = '1']">
   ...
 </group>

 <group ref="x[text() = '2']">
   ...
 </group>

etc. You don't need a bind statement to make this work.

I like this because you can spread the groups about, but if you do
want to keep them together to look more like switch/case, you could do
this:

 <group ref="x">
   <group ref=".[text() = '1']">
     ...
   </group>

   <group ref=".[text() = '2']">
     ...
   </group>
 </group>

Speaking only for myself, I don't have any problem with making this
kind of construct easier, but I think it would be better to achieve
this through some extra mechanisms, rather than changing switch/case.
By binding that to the model you introduce all sorts of quirky things
like what should happen if the user toggles a case that is bound to
the model--should the underlying data change?

At the moment switch/case is purely a UI construct, and although it
often *feels* like you need to bind it to the model, you'll actually
find that this usually indicates you don't need a switch/case.

That probably sounds a bit obtuse...what I'm getting at is that
switch/case currently operates via an action, rather than being bound
to data. The moment you mix the two, things start to get messy. I
would like to see switch/case kept as something that is action driven,
since that's very useful; but then we could also make it easier to
define 'relevance' sections without having the hassle of creating
extra instances. There are lots of ways that could be done, such as
improving lazy authoring, adding DI selectors, and so on.)

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/