Mark,
I am using "conventional" model-based switching , if you look at the xforms
source you will see that the xf:case is used just as a normal single node
binding control.
When I set about writing the XForms processor I looked at what was
available, looked at design patterns currently used by my clients and
BPEL/Workflow and then set about creating these composite controls, nobody
does creating of composite controls better then Dojo and Yahoo!UI.
The inner details of why I used tabswitch case is that for very large forms
we only need to parse what workflow the client wants, with group I would
have to parse the whole forms!
Look at the XForms source and it answers many of your other questions.
I have a "pattern" documentation and some clients use it for Templating and
writing special composite controls.
Thanks
Francisco
From: www-forms-request (AT) w3 (DOT) org [mailto:www-forms-request (AT) w3 (DOT) org] Behalf
Mark Seaborne
Sent: 18 August 2006 10:14
To: www-forms
Subject: Re: Switch case construct
Francisco,
Surely the effect you achieve in your form, of using model based relevance
to determine which cases are potentially viewable by the user, is already
achievable using "conventional" model-based switching? You could use group
instead of switch/case, or, if you were using switch/case as currently
defined (rather than your own tabswitch/case) you would just bind triggers
styled to look like tabs to you model. Either way the same effect is
achieved.
The thing that stands out about your tabswitch element is that it manages
case selection directly without the need for some other mechanism, such as
triggers. That is rather neat. So if switch was to be changed to allow this
kind of @appearance="tabbed" (for example) then each case would
automatically get its own trigger, that would need to behave just like a
normal trigger, I guess with a default action of toggle to its parent case,
triggered by DMActivate.
I think that this might fall under the category of making common design
patterns easy for authors and could be considered by the WG.
The simplest pattern achievable like this is to say all cases would be
relevant. If you wanted the mechanism to support relevance then you would
either need ref/bind on case.
But then where would the auto-generated trigger get its label, etc from?
If you have to add to case single node binding, label, help, hint and action
it is arguable that you might as easily wrap them in a trigger element as
described above, which would give more flexibility with styling, etc.
So maybe switch/case is alright after all? I'm not sure.
All the best
Mark
18 Aug 2006, at 08:22, Francisco Monteiro wrote:
My take on the whole switch-case construct is that it is too restrictive.
The case element is a control so all rules about Xforms control should apply
by this I mean enabled, disabled etc. When you are doing workflow and have
tabbed switch, the case element is viewed as a "section" just as paper forms
are written today.
I have a small example here which demonstrates what I am implying and it can
be viewed here
<>
Most clients I have like it this way, they see up front what is enabled or
disabled. Xforms must be viewed in terms of workflow, anything which helps
users have a easy experience should be encouraged.
Regards
Francisco

Francisco,

But case doesn't take single node binding, and it isn't a form
control. The only benefit I can see that giving case single node
binding, etc is that you can set the relevance of a case rather than
the relevance of a trigger with a toggle action pointing at the case.
Logically your form still consists of a set of cases with triggers
used to toggle between them.

Is it definitely the case that the content of non-relevant groups
have to be in memory? It might be worth asking for clarification on
that from the working group.

John Boyer pointed out (
2006Aug/0059.html) that the working group has discussed this and come
to a resolution about the implications of a case not being selected.
Is this likely to satisfy your own requirement only to have to load
into memory as much of the form as is in active cases (I know of at
least 1 implementation that already does this)? If it does then I see
no reason why you couldn't just use:

<xf:trigger ref="instance('dojo')/wf1">
<xf:label>Section-I</xf:label>
<xforms:action ev:event="DMActivate">
<xf:message level="modal">case 1 select event</xf:message>
<xf:toggle case="Section-I"/>
</xforms:action>
</xf:trigger>

<xf:switch>
<xf:case id="Section-I">

etc

with CSS to style your triggers as the trigger portion of tabs.

All the best

Mark

18 Aug 2006, at 10:43, Francisco Monteiro wrote:

Mark,
I am using "conventional" model-based switching , if you look at
the xforms source you will see that the xf:case is used just as a
normal single node binding control.

When I set about writing the XForms processor I looked at what was
available, looked at design patterns currently used by my clients
and BPEL/Workflow and then set about creating these composite
controls, nobody does creating of composite controls better then
Dojo and Yahoo!UI.

The inner details of why I used tabswitch case is that for very
large forms we only need to parse what workflow the client wants,
with group I would have to parse the whole forms!

Look at the XForms source and it answers many of your other questions.

I have a "pattern" documentation and some clients use it for
Templating and writing special composite controls.

Thanks
Francisco

From: www-forms-request (AT) w3 (DOT) org [mailto:www-forms-request (AT) w3 (DOT) org]
Behalf Mark Seaborne
Sent: 18 August 2006 10:14
To: www-forms
Subject: Re: Switch case construct

Francisco,

Surely the effect you achieve in your form, of using model based
relevance to determine which cases are potentially viewable by the
user, is already achievable using "conventional" model-based
switching? You could use group instead of switch/case, or, if you
were using switch/case as currently defined (rather than your own
tabswitch/case) you would just bind triggers styled to look like
tabs to you model. Either way the same effect is achieved.

The thing that stands out about your tabswitch element is that it
manages case selection directly without the need for some other
mechanism, such as triggers. That is rather neat. So if switch was
to be changed to allow this kind of @appearance="tabbed" (for
example) then each case would automatically get its own trigger,
that would need to behave just like a normal trigger, I guess with
a default action of toggle to its parent case, triggered by
DMActivate.

I think that this might fall under the category of making common
design patterns easy for authors and could be considered by the WG.

The simplest pattern achievable like this is to say all cases would
be relevant. If you wanted the mechanism to support relevance then
you would either need ref/bind on case.

But then where would the auto-generated trigger get its label, etc
from?

If you have to add to case single node binding, label, help, hint
and action it is arguable that you might as easily wrap them in a
trigger element as described above, which would give more
flexibility with styling, etc.

So maybe switch/case is alright after all? I'm not sure.

All the best

Mark
--
18 Aug 2006, at 08:22, Francisco Monteiro wrote:
>
>My take on the whole switch-case construct is that it is too
>restrictive. The case element is a control so all rules about
>Xforms control should apply by this I mean enabled, disabled etc.
>When you are doing workflow and have tabbed switch, the case
>element is viewed as a "section" just as paper forms are written
>today.
>I have a small example here which demonstrates what I am implying
>and it can be viewed here
>
>Most clients I have like it this way, they see up front what is
>enabled or disabled. Xforms must be viewed in terms of workflow,
>anything which helps users have a easy experience should be
>encouraged.
>Regards
>Francisco
>

At the time we defined "case", we explicitly defined it to be
conceptually equivalent to group its content model is the
same as group.

We did not put binding attrs on case because case is for UI-based
switching; as MarkB pointed out, model-based switching with one
of many panes visible can be implemented with group.

Mark Seaborne writes:
Francisco,

But case doesn't take single node binding, and it isn't a form
control. The only benefit I can see that giving case single node
binding, etc is that you can set the relevance of a case rather than
the relevance of a trigger with a toggle action pointing at the case.
Logically your form still consists of a set of cases with triggers
used to toggle between them.

Is it definitely the case that the content of non-relevant groups
have to be in memory? It might be worth asking for clarification on
that from the working group.

John Boyer pointed out (
2006Aug/0059.html) that the working group has discussed this and come
to a resolution about the implications of a case not being selected.
Is this likely to satisfy your own requirement only to have to load
into memory as much of the form as is in active cases (I know of at
least 1 implementation that already does this)? If it does then I see
no reason why you couldn't just use:

<xf:trigger ref="instance('dojo')/wf1">
<xf:label>Section-I</xf:label>
<xforms:action ev:event="DMActivate">
<xf:message level="modal">case 1 select event</xf:message>
<xf:toggle case="Section-I"/>
</xforms:action>
</xf:trigger>

<xf:switch>
<xf:case id="Section-I">

etc

with CSS to style your triggers as the trigger portion of tabs.

All the best

Mark

18 Aug 2006, at 10:43, Francisco Monteiro wrote:

Mark,
I am using "conventional" model-based switching , if you look at
the xforms source you will see that the xf:case is used just as a
normal single node binding control.

>

When I set about writing the XForms processor I looked at what was
available, looked at design patterns currently used by my clients
and BPEL/Workflow and then set about creating these composite
controls, nobody does creating of composite controls better then
Dojo and Yahoo!UI.

>

The inner details of why I used tabswitch case is that for very
large forms we only need to parse what workflow the client wants,
with group I would have to parse the whole forms!

>

Look at the XForms source and it answers many of your other questions.

>

I have a "pattern" documentation and some clients use it for
Templating and writing special composite controls.

>

Thanks
Francisco

>

From: www-forms-request (AT) w3 (DOT) org [mailto:www-forms-request (AT) w3 (DOT) org]
Behalf Mark Seaborne
Sent: 18 August 2006 10:14
To: www-forms
Subject: Re: Switch case construct

>

Francisco,

>

Surely the effect you achieve in your form, of using model based
relevance to determine which cases are potentially viewable by the
user, is already achievable using "conventional" model-based
switching? You could use group instead of switch/case, or, if you
were using switch/case as currently defined (rather than your own
tabswitch/case) you would just bind triggers styled to look like
tabs to you model. Either way the same effect is achieved.

>

The thing that stands out about your tabswitch element is that it
manages case selection directly without the need for some other
mechanism, such as triggers. That is rather neat. So if switch was
to be changed to allow this kind of @appearance="tabbed" (for
example) then each case would automatically get its own trigger,
that would need to behave just like a normal trigger, I guess with
a default action of toggle to its parent case, triggered by
DMActivate.

>

I think that this might fall under the category of making common
design patterns easy for authors and could be considered by the WG.

>

The simplest pattern achievable like this is to say all cases would
be relevant. If you wanted the mechanism to support relevance then
you would either need ref/bind on case.

>

But then where would the auto-generated trigger get its label, etc
from?

>

If you have to add to case single node binding, label, help, hint
and action it is arguable that you might as easily wrap them in a
trigger element as described above, which would give more
flexibility with styling, etc.

>

So maybe switch/case is alright after all? I'm not sure.

>

All the best

>

Mark

>
>

18 Aug 2006, at 08:22, Francisco Monteiro wrote:

>
>My take on the whole switch-case construct is that it is too
>restrictive. The case element is a control so all rules about
>Xforms control should apply by this I mean enabled, disabled etc.
>When you are doing workflow and have tabbed switch, the case
>element is viewed as a "section" just as paper forms are written
>today.
>I have a small example here which demonstrates what I am implying
>and it can be viewed here
>
>Most clients I have like it this way, they see up front what is
>enabled or disabled. Xforms must be viewed in terms of workflow,
>anything which helps users have a easy experience should be
>encouraged.
>Regards
>Francisco
>


<HTML><BDY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">Francisco,<DIV><BR class="khtml-block-placeholder"></DIV><DIV>But case doesn't take single node binding, and it isn't a form control.* The only benefit I can see that giving case single node binding, etc is that you can set the relevance of a case rather than the relevance of a trigger with a toggle action pointing at the case. Logically your form still consists of a set of cases with triggers used to toggle between them.*</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Is it definitely the case that the content of non-relevant groups have to be in memory? It might be worth asking for clarification on that from the working group.*</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>John Boyer pointed out (<A href=""></A>) that the working group has discussed this and come to a resolution about the implications of a case not being selected. Is this likely to satisfy your own requirement*only to have to load into memory as much of the form as is in active cases (I know of at least 1 implementation that already does this)? If it does then I see no reason why you couldn't just use:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><xf:trigger ref="instance('dojo')/wf1"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"></SPAN><xf:label>Section-I</xf:label></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"></SPAN><xforms:action*ev:event="DMActivate">*</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"></SPAN><xf:message level="modal">case 1 select event</xf:message></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"></SPAN><xf:toggle case="Section-I"/></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"></SPAN></xforms:action></DIV><DIV></xf:trigger></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><xf:switch></DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"></SPAN><xf:case id="Section-I"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>*etc</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>with CSS to style your triggers as the trigger portion of tabs.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>All the best</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Mark</DIV><DIV><BR><DIV><DIV18 Aug 2006, at 10:43, Francisco Monteiro wrote:</DIV><BR class="Apple-interchange-newline"><BLCKQUTE type="cite"<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="468033009-18082006">Mark,</SPAN></FNT></DIV<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="468033009-18082006">I am using *<FNT face="Times New Roman" color="#000000" size="3">"conventional" model-based switching <FNT face="Arial" color="#0000ff" size="2">, if you look at the xforms source you will see that the xf:case is used just as a normal single node binding control.</FNT></FNT></SPAN></FNT></DIV<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="468033009-18082006"></SPAN></FNT>*</DIV<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="468033009-18082006">When I set about writing the XForms processor I looked at what was available, looked at design patterns currently used by my clients and BPEL/Workflow*and then set about creating these composite controls, nobody does creating of composite controls better then Dojo and Yahoo!UI.</SPAN></FNT></DIV<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="468033009-18082006"></SPAN></FNT>*</DIV<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="468033009-18082006">The inner details of why I used tabswitch case is that for very large forms we only need to parse what workflow the client wants, with group I would have to parse the whole forms!</SPAN></FNT></DIV<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="468033009-18082006"></SPAN></FNT>*</DIV<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="468033009-18082006">Look at the XForms source and it answers many of your other questions.</SPAN></FNT></DIV<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="468033009-18082006"></SPAN></FNT>*</DIV<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="468033009-18082006">I have a "pattern" documentation and some clients use it for Templating and writing special composite controls.</SPAN></FNT></DIV<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="468033009-18082006"></SPAN></FNT>*</DIV<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="468033009-18082006">Thanks</SPAN></FNT></DIV<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="468033009-18082006">Francisco</SPAN></FNT></DIV><BR<DIV class="MessageHeader" lang="en-us" dir="ltr" align="left"<HR tabindex="-1"<FNT face="Tahoma" size="2"><B>From:</Bwww-forms-request (AT) w3 (DOT) org [<A href="mailto:www-forms-request (AT) w3 (DOT) org">mailto:www-forms-request (AT) w3 (DOT) org</A>] <BBehalf </B>Mark Seaborne<BR><B>Sent:</B18 August 2006 10:14<BR><B>To:</Bwww-forms<BR><B>Subject:</BRe: Switch case construct<BR></FNT><BR></DIV<DIV></DIV>Francisco, <DIV><BR class="khtml-block-placeholder"></DIV<DIV>Surely the effect you achieve in your form, of using model based relevance to determine which cases are potentially viewable by the user, is already achievable using "conventional" model-based switching? You could use group instead of switch/case, or, if you were using switch/case as currently defined (rather than your own tabswitch/case) you would just bind triggers styled to look like tabs to you model. Either way the same effect is achieved.</DIV<DIV><BR class="khtml-block-placeholder"></DIV<DIV>The thing that stands out about your tabswitch element is that it manages case selection directly without the need for some other mechanism, such as triggers. That is rather neat. So if switch was to be changed to allow this kind of @appearance="tabbed" (for example) then each case would automatically get its own trigger, that would need to behave just like a normal trigger, I guess with a default action of toggle to its parent case, triggered by DMActivate. </DIV<DIV><BR class="khtml-block-placeholder"></DIV<DIV>I think that this might fall under the category of making common design patterns easy for authors and could be considered by the WG. </DIV<DIV><BR class="khtml-block-placeholder"></DIV<DIV>The simplest pattern achievable like this is to say all cases would be relevant. If you wanted the mechanism to support relevance then you would either need ref/bind on case.</DIV<DIV><BR class="khtml-block-placeholder"></DIV<DIV>But then where would the auto-generated trigger get its label, etc from? </DIV<DIV><BR class="khtml-block-placeholder"></DIV<DIV>If you have to add to case single node binding, label, help, hint and action it is arguable that you might as easily wrap them in a trigger element as described above, which would give more flexibility with styling, etc.</DIV<DIV><BR class="khtml-block-placeholder"></DIV<DIV>So maybe switch/case is alright after all? I'm not sure.</DIV<DIV><BR class="khtml-block-placeholder"></DIV<DIV>All the best</DIV<DIV><BR class="khtml-block-placeholder"></DIV<DIV>Mark</DIV<DIV><BR class="khtml-block-placeholder"></DIV<DIV><BR<DIV<DIV18 Aug 2006, at 08:22, Francisco Monteiro wrote:</DIV><BR class="Apple-interchange-newline"<BLCKQUTE type="cite"<DIV dir="ltr" align="left"><SPAN class="828143706-18082006"><FNT size="+0"><FNT size="+0"><FNT face="Arial"><FNT color="#0000ff"><FNT size="2"><SPAN class="343282007-18082006"></SPAN>My take on the whole switch-case construct is <SPAN class="343282007-18082006">that </SPAN>it is too restrictive. The case element is a control so all rules about Xforms control should apply by this I mean enabled, disabled etc. When you are doing workflow and have tabbed switch, the case element is viewed as a "section" just as paper forms are written today.</FNT></FNT></FNT></FNT></FNT></SPAN></DIV<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="828143706-18082006"></SPAN></FNT></DIV<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="828143706-18082006">I have a small example here which demonstrates what I am implying and it can be viewed here</SPAN></FNT></DIV<DIV dir="ltr" align="left"><FNT face="Arial" color="#0000ff" size="2"><SPAN class="828143706-18082006"><A title="" href=""></A></SPAN></FNT></DIV<DIV><FNT face="Arial" color="#0000ff" size="2"><SPAN class="828143706-18082006"></SPAN></FNT></DIV<DIV><FNT face="Arial" color="#0000ff" size="2"><SPAN class="828143706-18082006">Most clients I have like it this way, they see up front what is enabled or disabled. Xforms must be viewed in terms of workflow, anything which helps users have a easy experience should be encouraged.</SPAN></FNT></DIV<DIV><FNT face="Arial" color="#0000ff" size="2"><SPAN class="828143706-18082006"></SPAN></FNT></DIV<DIV><FNT face="Arial" color="#0000ff" size="2"><SPAN class="828143706-18082006">Regards</SPAN></FNT></DIV<DIV><FNT face="Arial" color="#0000ff" size="2"><SPAN class="828143706-18082006">Francisco</SPAN></FNT></DIV></BLCKQUTE></DIV><BR></DIV></BLCKQUTE></DIV><BR></DIV></BDY></HTML>