3.4 The case Element Child of the toggle Element

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

3.4 The case Element Child of the toggle Element

dr.cw.ray
Is the xforms 1.1 specification for "3.4 The case Element Child of the
toggle Element" supported by mozilla xforms (the status report is not
clear on this, showing "partial" with no notes).

Whether or not it is, can someone tell me if the below is a proper
minimal example of such a use. In this example, my interpretation,
nothing but the label will show until clicked and then the case would
become relevant (I'm not real sure I'm interpreting this use case
correctly). Any comments appreciated.

<?xml version="1.0"?>
<h:html
 xmlns:h="http://www.w3.org/1999/xhtml"
 xmlns:ev="http://www.w3.org/2001/xml-events"
 xmlns:xf="http://www.w3.org/2002/xforms"
 xmlns:xs="http://www.w3.org/2001/XMLSchema">

<h:head>
   <h:title> Template </h:title>
      <!--===========================-->
      <xf:model id="mm">
         <xf:instance>
            <data xmlns="">
            <ztext>zzzz zzzz zzzzzz zzzz</ztext>
            </data>
         </xf:instance>
      </xf:model>
      <!--===========================-->
</h:head>
   <!--==============================-->
   <h:body>
      <xf:trigger>
         <xf:label>click to view text</xf:label>
         <xf:toggle>
            <xf:case value="//ztext"/>
         </xf:toggle>
      </xf:trigger>
   </h:body>
   <!--==============================-->
</h:html>
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 The case Element Child of the toggle Element

Aaron Reed
It is supported in the nightlies.  It was fixed via
https://bugzilla.mozilla.org/show_bug.cgi?id=494848.  There is a
testcase on the bug that you could use as a sample to help you get started.

--Aaron

dr.cw.ray wrote:

> Is the xforms 1.1 specification for "3.4 The case Element Child of the
> toggle Element" supported by mozilla xforms (the status report is not
> clear on this, showing "partial" with no notes).
>
> Whether or not it is, can someone tell me if the below is a proper
> minimal example of such a use. In this example, my interpretation,
> nothing but the label will show until clicked and then the case would
> become relevant (I'm not real sure I'm interpreting this use case
> correctly). Any comments appreciated.
>
> <?xml version="1.0"?>
> <h:html
>  xmlns:h="http://www.w3.org/1999/xhtml"
>  xmlns:ev="http://www.w3.org/2001/xml-events"
>  xmlns:xf="http://www.w3.org/2002/xforms"
>  xmlns:xs="http://www.w3.org/2001/XMLSchema">
>
> <h:head>
>    <h:title> Template </h:title>
>       <!--===========================-->
>       <xf:model id="mm">
>          <xf:instance>
>             <data xmlns="">
>             <ztext>zzzz zzzz zzzzzz zzzz</ztext>
>             </data>
>          </xf:instance>
>       </xf:model>
>       <!--===========================-->
> </h:head>
>    <!--==============================-->
>    <h:body>
>       <xf:trigger>
>          <xf:label>click to view text</xf:label>
>          <xf:toggle>
>             <xf:case value="//ztext"/>
>          </xf:toggle>
>       </xf:trigger>
>    </h:body>
>    <!--==============================-->
> </h:html>
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 The case Element Child of the toggle Element

dr.cw.ray
On Aug 21, 2:41 am, Aaron Reed <[hidden email]> wrote:

> It is supported in the nightlies.  It was fixed viahttps://bugzilla.mozilla.org/show_bug.cgi?id=494848.  There is a
> testcase on the bug that you could use as a sample to help you get started.
>
> --Aaron
>
> dr.cw.ray wrote:
> > Is the xforms 1.1 specification for "3.4 The case Element Child of the
> > toggle Element" supported by mozilla xforms (the status report is not
> > clear on this, showing "partial" with no notes).
>
> > Whether or not it is, can someone tell me if the below is a proper
> > minimal example of such a use. In this example, my interpretation,
> > nothing but the label will show until clicked and then the case would
> > become relevant (I'm not real sure I'm interpreting this use case
> > correctly). Any comments appreciated.
>
> > <?xml version="1.0"?>
> > <h:html
> >  xmlns:h="http://www.w3.org/1999/xhtml"
> >  xmlns:ev="http://www.w3.org/2001/xml-events"
> >  xmlns:xf="http://www.w3.org/2002/xforms"
> >  xmlns:xs="http://www.w3.org/2001/XMLSchema">
>
> > <h:head>
> >    <h:title> Template </h:title>
> >       <!--===========================-->
> >       <xf:model id="mm">
> >          <xf:instance>
> >             <data xmlns="">
> >             <ztext>zzzz zzzz zzzzzz zzzz</ztext>
> >             </data>
> >          </xf:instance>
> >       </xf:model>
> >       <!--===========================-->
> > </h:head>
> >    <!--==============================-->
> >    <h:body>
> >       <xf:trigger>
> >          <xf:label>click to view text</xf:label>
> >          <xf:toggle>
> >             <xf:case value="//ztext"/>
> >          </xf:toggle>
> >       </xf:trigger>
> >    </h:body>
> >    <!--==============================-->
> > </h:html>

Thanks Aaron,
I reviewed the test suite (don't know why I didn't think of that
before).
No wonder I had it all wrong, I thought that case as child of toggle
was somehow supposed to simplify things, e.g. doing away with the need
for a switch element and multiple case containers ( I was thinking of
it more like turning a single container on and off (relevant/not-
relevant) without the need for an empty case in switch or without the
need to bind an xforms-group container to a node based on relevance).

At any rate, I'm confused, not only does it not simplify things, it
doesn't seem to add anything except the ability to put a value in
case.  So now we have two xforms-case elements, one that acts like a
container and one that acts inside a toggle as a bind to another
case?.

Since the toggle no longer requires the case attribute, I don't
understand how the processor can distinguish between a case element
which refers to another case's IDREF or an xpath expression or for
what other purposes the value might be used.

But this is all my problem, I'm sure I'll work through it sooner or
later.

Thanks :)

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 The case Element Child of the toggle Element

Dion Sole
2009/8/21 dr.cw.ray <[hidden email]>:

> Thanks Aaron,
> I reviewed the test suite (don't know why I didn't think of that
> before).
> No wonder I had it all wrong, I thought that case as child of toggle
> was somehow supposed to simplify things, e.g. doing away with the need
> for a switch element and multiple case containers ( I was thinking of
> it more like turning a single container on and off (relevant/not-
> relevant) without the need for an empty case in switch or without the
> need to bind an xforms-group container to a node based on relevance).
>
> At any rate, I'm confused, not only does it not simplify things, it
> doesn't seem to add anything except the ability to put a value in
> case.  So now we have two xforms-case elements, one that acts like a
> container and one that acts inside a toggle as a bind to another
> case?.
>
> Since the toggle no longer requires the case attribute, I don't
> understand how the processor can distinguish between a case element
> which refers to another case's IDREF or an xpath expression or for
> what other purposes the value might be used.
>
> But this is all my problem, I'm sure I'll work through it sooner or
> later.
>
> Thanks :)

The case element/attribute (the one that can appear within a toggle)
always refers to an IDREF. It's just that now you can dynamically
generate the IDREF through an xpath expression, as opposed to the case
attribute which must be declared ahead of time (and thus can't
change).

This lets you determine which case to change to based on values stored
in an instance.
For example, a sort of navigation history similar to a normal browser
history, by storing the previous and next case's IDs within an
instance and then simply having "back" and "forwards" triggers that
toggle to whatever case is stored in those instance nodes. I've done
this in a number of forms I've written, since there's multiple
possible entry points to each case.
Similarly, if you have case IDs that follow a common pattern ("case1",
"case2" for example), you can save a fair bit of typing by using the
case element to generate the appropriate IDREF based on whichever one
you're currently in.
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: 3.4 The case Element Child of the toggle Element

dr.cw.ray
In reply to this post by dr.cw.ray
On Aug 21, 5:30 am, dion sole <[hidden email]> wrote:

> 2009/8/21 dr.cw.ray <[hidden email]>:
>
>
>
> > Thanks Aaron,
> > I reviewed the test suite (don't know why I didn't think of that
> > before).
> > No wonder I had it all wrong, I thought that case as child of toggle
> > was somehow supposed to simplify things, e.g. doing away with the need
> > for a switch element and multiple case containers ( I was thinking of
> > it more like turning a single container on and off (relevant/not-
> > relevant) without the need for an empty case in switch or without the
> > need to bind an xforms-group container to a node based on relevance).
>
> > At any rate, I'm confused, not only does it not simplify things, it
> > doesn't seem to add anything except the ability to put a value in
> > case.  So now we have two xforms-case elements, one that acts like a
> > container and one that acts inside a toggle as a bind to another
> > case?.
>
> > Since the toggle no longer requires the case attribute, I don't
> > understand how the processor can distinguish between a case element
> > which refers to another case's IDREF or an xpath expression or for
> > what other purposes the value might be used.
>
> > But this is all my problem, I'm sure I'll work through it sooner or
> > later.
>
> > Thanks :)
>
> The case element/attribute (the one that can appear within a toggle)
> always refers to an IDREF. It's just that now you can dynamically
> generate the IDREF through an xpath expression, as opposed to the case
> attribute which must be declared ahead of time (and thus can't
> change).
>
> This lets you determine which case to change to based on values stored
> in an instance.
> For example, a sort of navigation history similar to a normal browser
> history, by storing the previous and next case's IDs within an
> instance and then simply having "back" and "forwards" triggers that
> toggle to whatever case is stored in those instance nodes. I've done
> this in a number of forms I've written, since there's multiple
> possible entry points to each case.
> Similarly, if you have case IDs that follow a common pattern ("case1",
> "case2" for example), you can save a fair bit of typing by using the
> case element to generate the appropriate IDREF based on whichever one
> you're currently in.

Dion, Thanks! Your first paragraph cleared things up immediately, and
your example demonstrates greater flexibility than was previously had
in xforms 1.0. I think that will be very handy and useful.

_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms