xforms-hide

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

xforms-hide

dr.cw.ray
Okay, well I don't think there's any such thing as xforms-hide, but
does anyone know if there are any plans for such a thing in the xforms
future? Let me explain.

I often have sections of my application that I want to hide behind a
button. I currently use two approaches. First, I use an xforms switch/
case with only two cases, the first case is empty and the second case
contains the data (or form elements) that I want to hide.
see http://ztags4xforms.com/wordpress/?p=33
This works really well but it is verbose and encumbers the page for
anything other than a small scale app.

The other approach is to use xforms-bind with the  relevance
attribute, but I feel as if this violates MVC. I don't like creating
and inserting new elements in my initial model--which should represent
only my working data, not the use of my controls. I can make another
model or instance for manipulating the relevance of controls, but this
can also be as cumbersome as using switch case, not to mention is
effects the .

I'm just wondering if anyone has ever discussed this at the standards
level, having a trigger that is represented like this:
<xforms-hide hidden="yes" appearance="minimal">
         data or form elements here
</xforms-hide> <!-- hidden="on" means the section is initially hidden
-->

<xforms-hide hidden="off" appearance="minimal">
         data or form elements here
</xforms-hide> <!-- hidden="off"  means the section is initially
displayed -->

It seems to me that everything is already in place; one could just
build a trigger on top of the switch/case toggle as in my example (I
think it could be done with XBL, but I'm not sure).
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: xforms-hide

Aaron Reed
Boy, the idea sounds familiar, but I'm not sure.  You'd have to check
the public archives of the working group to see if they've considered it
before (http://www.w3.org/MarkUp/Forms/#email11).  If you don't see it
in the archives, I'd suggest posting to one of the mailing lists with
your idea.

--Aaron

[hidden email] wrote:

> Okay, well I don't think there's any such thing as xforms-hide, but
> does anyone know if there are any plans for such a thing in the xforms
> future? Let me explain.
>
> I often have sections of my application that I want to hide behind a
> button. I currently use two approaches. First, I use an xforms switch/
> case with only two cases, the first case is empty and the second case
> contains the data (or form elements) that I want to hide.
> see http://ztags4xforms.com/wordpress/?p=33
> This works really well but it is verbose and encumbers the page for
> anything other than a small scale app.
>
> The other approach is to use xforms-bind with the  relevance
> attribute, but I feel as if this violates MVC. I don't like creating
> and inserting new elements in my initial model--which should represent
> only my working data, not the use of my controls. I can make another
> model or instance for manipulating the relevance of controls, but this
> can also be as cumbersome as using switch case, not to mention is
> effects the .
>
> I'm just wondering if anyone has ever discussed this at the standards
> level, having a trigger that is represented like this:
> <xforms-hide hidden="yes" appearance="minimal">
>          data or form elements here
> </xforms-hide> <!-- hidden="on" means the section is initially hidden
> -->
>
> <xforms-hide hidden="off" appearance="minimal">
>          data or form elements here
> </xforms-hide> <!-- hidden="off"  means the section is initially
> displayed -->
>
> It seems to me that everything is already in place; one could just
> build a trigger on top of the switch/case toggle as in my example (I
> think it could be done with XBL, but I'm not sure).
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: xforms-hide

dr.cw.ray
On Jun 4, 4:21 am, Aaron Reed <[hidden email]> wrote:

> Boy, the idea sounds familiar, but I'm not sure.  You'd have to check
> the public archives of the working group to see if they've considered it
> before (http://www.w3.org/MarkUp/Forms/#email11).  If you don't see it
> in the archives, I'd suggest posting to one of the mailing lists with
> your idea.
>
> --Aaron
>
> [hidden email] wrote:
> > Okay, well I don't think there's any such thing as xforms-hide, but
> > does anyone know if there are any plans for such a thing in the xforms
> > future? Let me explain.
>
> > I often have sections of my application that I want to hide behind a
> > button. I currently use two approaches. First, I use an xforms switch/
> > case with only two cases, the first case is empty and the second case
> > contains the data (or form elements) that I want to hide.
> > seehttp://ztags4xforms.com/wordpress/?p=33
> > This works really well but it is verbose and encumbers the page for
> > anything other than a small scale app.
>
> > The other approach is to use xforms-bind with the  relevance
> > attribute, but I feel as if this violates MVC. I don't like creating
> > and inserting new elements in my initial model--which should represent
> > only my working data, not the use of my controls. I can make another
> > model or instance for manipulating the relevance of controls, but this
> > can also be as cumbersome as using switch case, not to mention is
> > effects the .
>
> > I'm just wondering if anyone has ever discussed this at the standards
> > level, having a trigger that is represented like this:
> > <xforms-hide hidden="yes" appearance="minimal">
> >          data or form elements here
> > </xforms-hide> <!-- hidden="on" means the section is initially hidden
> > -->
>
> > <xforms-hide hidden="off" appearance="minimal">
> >          data or form elements here
> > </xforms-hide> <!-- hidden="off"  means the section is initially
> > displayed -->
>
> > It seems to me that everything is already in place; one could just
> > build a trigger on top of the switch/case toggle as in my example (I
> > think it could be done with XBL, but I'm not sure).

thanks for the link.  I think I'll at least pass on the idea.
Is something like this doable with XBL?  If so, I might give it a
shot, but I've never done XBL before, been looking for an opportunity
to see what that's all about.  Can I use XBL to convert my switch case
code into a single "hide" element of some kind?
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

RE: xforms-hide

Klotz, Leigh
In reply to this post by Aaron Reed
Yes, please do go ahead and post your ideas.

You don't need to add and remove nodes, by the way.  You can use a
second instance to model the capabilities, then use bind/@relevant to
assign relevance to the nodes indicating the various capabilities.
trigger/@ref then makes the trigger obey the capability relevance.
group/@ref does the same.

<instance id="capabilities">
  <data xmlns="">
    <canEdit />
    <canAdd />
    <canDelete />
  </data>
</instance>

<bind nodeset="instance('capabilities')">
  <bind nodeset="canEdit" relevant="instance('login')/username!=''" />
  <bind nodeset="canAdd" relevant="instance('session')/username ==
instance('document')/owner or instance('login')/username='admin'" />
  <bind nodeset="canDelete"
relevant="instance('login')/username=='admin'" />
</bind>


<group ref="instance('capabilities')/canEdit">
 <trigger ref="instance('capabilities')/canAdd">
  <label>Add</label>
  <insert ev:event="DOMActivate" ref="..." ... />
 </trigger>
 <trigger ref="instance('capabilities')/canDelete">
  <label>Delete</label>
  <delete ev:event="DOMActivate" ref="..." ... />
 </trigger>
</group>


Leigh.

-----Original Message-----
From: dev-tech-xforms-bounces+leigh.klotz=[hidden email]
[mailto:dev-tech-xforms-bounces+leigh.klotz=[hidden email]]
On Behalf Of Aaron Reed
Sent: Tuesday, June 03, 2008 1:22 PM
To: [hidden email]
Subject: Re: xforms-hide

Boy, the idea sounds familiar, but I'm not sure.  You'd have to check
the public archives of the working group to see if they've considered it
before (http://www.w3.org/MarkUp/Forms/#email11).  If you don't see it
in the archives, I'd suggest posting to one of the mailing lists with
your idea.

--Aaron

[hidden email] wrote:
> Okay, well I don't think there's any such thing as xforms-hide, but
> does anyone know if there are any plans for such a thing in the xforms

> future? Let me explain.
>
> I often have sections of my application that I want to hide behind a
> button. I currently use two approaches. First, I use an xforms switch/

> case with only two cases, the first case is empty and the second case
> contains the data (or form elements) that I want to hide.
> see http://ztags4xforms.com/wordpress/?p=33
> This works really well but it is verbose and encumbers the page for
> anything other than a small scale app.
>
> The other approach is to use xforms-bind with the  relevance
> attribute, but I feel as if this violates MVC. I don't like creating
> and inserting new elements in my initial model--which should represent

> only my working data, not the use of my controls. I can make another
> model or instance for manipulating the relevance of controls, but this

> can also be as cumbersome as using switch case, not to mention is
> effects the .
>
> I'm just wondering if anyone has ever discussed this at the standards
> level, having a trigger that is represented like this:
> <xforms-hide hidden="yes" appearance="minimal">
>          data or form elements here
> </xforms-hide> <!-- hidden="on" means the section is initially hidden
> -->
>
> <xforms-hide hidden="off" appearance="minimal">
>          data or form elements here
> </xforms-hide> <!-- hidden="off"  means the section is initially
> displayed -->
>
> It seems to me that everything is already in place; one could just
> build a trigger on top of the switch/case toggle as in my example (I
> think it could be done with XBL, but I'm not sure).
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: xforms-hide

dr.cw.ray
In reply to this post by Aaron Reed
On Jun 4, 4:42 am, "Klotz, Leigh" <[hidden email]> wrote:

> Yes, please do go ahead and post your ideas.
>
> You don't need to add and remove nodes, by the way.  You can use a
> second instance to model the capabilities, then use bind/@relevant to
> assign relevance to the nodes indicating the various capabilities.
> trigger/@ref then makes the trigger obey the capability relevance.
> group/@ref does the same.
>
> <instance id="capabilities">
>   <data xmlns="">
>     <canEdit />
>     <canAdd />
>     <canDelete />
>   </data>
> </instance>
>
> <bind nodeset="instance('capabilities')">
>   <bind nodeset="canEdit" relevant="instance('login')/username!=''" />
>   <bind nodeset="canAdd" relevant="instance('session')/username ==
> instance('document')/owner or instance('login')/username='admin'" />
>   <bind nodeset="canDelete"
> relevant="instance('login')/username=='admin'" />
> </bind>
>
> <group ref="instance('capabilities')/canEdit">
>  <trigger ref="instance('capabilities')/canAdd">
>   <label>Add</label>
>   <insert ev:event="DOMActivate" ref="..." ... />
>  </trigger>
>  <trigger ref="instance('capabilities')/canDelete">
>   <label>Delete</label>
>   <delete ev:event="DOMActivate" ref="..." ... />
>  </trigger>
> </group>
>
> Leigh.
>
> -----Original Message-----
> From: dev-tech-xforms-bounces+leigh.klotz=[hidden email]
>
> [mailto:dev-tech-xforms-bounces+leigh.klotz=[hidden email]]
> On Behalf Of Aaron Reed
> Sent: Tuesday, June 03, 2008 1:22 PM
> To: [hidden email]
> Subject: Re: xforms-hide
>
> Boy, the idea sounds familiar, but I'm not sure.  You'd have to check
> the public archives of the working group to see if they've considered it
> before (http://www.w3.org/MarkUp/Forms/#email11).  If you don't see it
> in the archives, I'd suggest posting to one of the mailing lists with
> your idea.
>
> --Aaron
>
> [hidden email] wrote:
> > Okay, well I don't think there's any such thing as xforms-hide, but
> > does anyone know if there are any plans for such a thing in the xforms
>
> > future? Let me explain.
>
> > I often have sections of my application that I want to hide behind a
> > button. I currently use two approaches. First, I use an xforms switch/
>
> > case with only two cases, the first case is empty and the second case
> > contains the data (or form elements) that I want to hide.
> > seehttp://ztags4xforms.com/wordpress/?p=33
> > This works really well but it is verbose and encumbers the page for
> > anything other than a small scale app.
>
> > The other approach is to use xforms-bind with the  relevance
> > attribute, but I feel as if this violates MVC. I don't like creating
> > and inserting new elements in my initial model--which should represent
>
> > only my working data, not the use of my controls. I can make another
> > model or instance for manipulating the relevance of controls, but this
>
> > can also be as cumbersome as using switch case, not to mention is
> > effects the .
>
> > I'm just wondering if anyone has ever discussed this at the standards
> > level, having a trigger that is represented like this:
> > <xforms-hide hidden="yes" appearance="minimal">
> >          data or form elements here
> > </xforms-hide> <!-- hidden="on" means the section is initially hidden
> > -->
>
> > <xforms-hide hidden="off" appearance="minimal">
> >          data or form elements here
> > </xforms-hide> <!-- hidden="off"  means the section is initially
> > displayed -->
>
> > It seems to me that everything is already in place; one could just
> > build a trigger on top of the switch/case toggle as in my example (I
> > think it could be done with XBL, but I'm not sure).
> _______________________________________________
> dev-tech-xforms mailing list
> [hidden email]://lists.mozilla.org/listinfo/dev-tech-xforms

Thanks Leigh,
Although I do use this approach sometimes, the problem with this
approach is that when you build a substantial app, you end up with
this huge instance just for controls with all these relevance binds
because each "hide/unhide" trigger for each section has to have a
separate relevance element, otherwise, one trigger would hide/unhide
all the sections at the same time. Usually, a person only wants to
hide/unhide one section at a time.   So you can see how unwieldy this
can get in a large app.  And it gets even worse if you have some of
these hide/unhides nested within one another. It also makes it
difficult from an xpath point of view to keep up with where the xpath
pointer is at any one time (I'm not an xpath expert so as I add more
and more models or instances I often can't get my form to act in the
way I expect and this costs me hours and hours of programming time
trying to figure the xpath reference).

Do you think that xbl is the way to go for now?  Like I said, I've
never done xbl, so I'd prefer some feedback as to whether it's even
possible before I delve into something that might not work.
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: xforms-hide

Aaron Reed

If I understand what you want, you just want a container that can hide
its contents upon command.  Should be pretty simple to do in XBL.  But
how would you notify it that it needs to hide or show its contents?
Toggle currently is hardwired to only work with case and switch.  But I
think that you should be able to make your own toggle (again, using xbl)
to trigger the hide element to show or hide itself (which would show or
hide its contents).

One thing to keep in mind is that just because you are hiding things
doesn't mean that it'll behave exactly as if things that are irrelevant.
  There are rules of relevancy that won't be enforced because the hidden
controls aren't irrelevant according to MVC, but rather they are just
visually hidden.

--Aaron

[hidden email] wrote:

> On Jun 4, 4:42 am, "Klotz, Leigh" <[hidden email]> wrote:
>> Yes, please do go ahead and post your ideas.
>>
>> You don't need to add and remove nodes, by the way.  You can use a
>> second instance to model the capabilities, then use bind/@relevant to
>> assign relevance to the nodes indicating the various capabilities.
>> trigger/@ref then makes the trigger obey the capability relevance.
>> group/@ref does the same.
>>
>> <instance id="capabilities">
>>   <data xmlns="">
>>     <canEdit />
>>     <canAdd />
>>     <canDelete />
>>   </data>
>> </instance>
>>
>> <bind nodeset="instance('capabilities')">
>>   <bind nodeset="canEdit" relevant="instance('login')/username!=''" />
>>   <bind nodeset="canAdd" relevant="instance('session')/username ==
>> instance('document')/owner or instance('login')/username='admin'" />
>>   <bind nodeset="canDelete"
>> relevant="instance('login')/username=='admin'" />
>> </bind>
>>
>> <group ref="instance('capabilities')/canEdit">
>>  <trigger ref="instance('capabilities')/canAdd">
>>   <label>Add</label>
>>   <insert ev:event="DOMActivate" ref="..." ... />
>>  </trigger>
>>  <trigger ref="instance('capabilities')/canDelete">
>>   <label>Delete</label>
>>   <delete ev:event="DOMActivate" ref="..." ... />
>>  </trigger>
>> </group>
>>
>> Leigh.
>>
>> -----Original Message-----
>> From: dev-tech-xforms-bounces+leigh.klotz=[hidden email]
>>
>> [mailto:dev-tech-xforms-bounces+leigh.klotz=[hidden email]]
>> On Behalf Of Aaron Reed
>> Sent: Tuesday, June 03, 2008 1:22 PM
>> To: [hidden email]
>> Subject: Re: xforms-hide
>>
>> Boy, the idea sounds familiar, but I'm not sure.  You'd have to check
>> the public archives of the working group to see if they've considered it
>> before (http://www.w3.org/MarkUp/Forms/#email11).  If you don't see it
>> in the archives, I'd suggest posting to one of the mailing lists with
>> your idea.
>>
>> --Aaron
>>
>> [hidden email] wrote:
>>> Okay, well I don't think there's any such thing as xforms-hide, but
>>> does anyone know if there are any plans for such a thing in the xforms
>>> future? Let me explain.
>>> I often have sections of my application that I want to hide behind a
>>> button. I currently use two approaches. First, I use an xforms switch/
>>> case with only two cases, the first case is empty and the second case
>>> contains the data (or form elements) that I want to hide.
>>> seehttp://ztags4xforms.com/wordpress/?p=33
>>> This works really well but it is verbose and encumbers the page for
>>> anything other than a small scale app.
>>> The other approach is to use xforms-bind with the  relevance
>>> attribute, but I feel as if this violates MVC. I don't like creating
>>> and inserting new elements in my initial model--which should represent
>>> only my working data, not the use of my controls. I can make another
>>> model or instance for manipulating the relevance of controls, but this
>>> can also be as cumbersome as using switch case, not to mention is
>>> effects the .
>>> I'm just wondering if anyone has ever discussed this at the standards
>>> level, having a trigger that is represented like this:
>>> <xforms-hide hidden="yes" appearance="minimal">
>>>          data or form elements here
>>> </xforms-hide> <!-- hidden="on" means the section is initially hidden
>>> -->
>>> <xforms-hide hidden="off" appearance="minimal">
>>>          data or form elements here
>>> </xforms-hide> <!-- hidden="off"  means the section is initially
>>> displayed -->
>>> It seems to me that everything is already in place; one could just
>>> build a trigger on top of the switch/case toggle as in my example (I
>>> think it could be done with XBL, but I'm not sure).
>> _______________________________________________
>> dev-tech-xforms mailing list
>> [hidden email]://lists.mozilla.org/listinfo/dev-tech-xforms
>
> Thanks Leigh,
> Although I do use this approach sometimes, the problem with this
> approach is that when you build a substantial app, you end up with
> this huge instance just for controls with all these relevance binds
> because each "hide/unhide" trigger for each section has to have a
> separate relevance element, otherwise, one trigger would hide/unhide
> all the sections at the same time. Usually, a person only wants to
> hide/unhide one section at a time.   So you can see how unwieldy this
> can get in a large app.  And it gets even worse if you have some of
> these hide/unhides nested within one another. It also makes it
> difficult from an xpath point of view to keep up with where the xpath
> pointer is at any one time (I'm not an xpath expert so as I add more
> and more models or instances I often can't get my form to act in the
> way I expect and this costs me hours and hours of programming time
> trying to figure the xpath reference).
>
> Do you think that xbl is the way to go for now?  Like I said, I've
> never done xbl, so I'd prefer some feedback as to whether it's even
> possible before I delve into something that might not work.
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

RE: xforms-hide

Klotz, Leigh
If all you want is a container than can show or hide, then group with
ref to a node whose relevance is controlled is 100% within the XForms
recommendation and will do it portably.  If you want an action, you can
have a handler that receives your custom event and does a setvalue.

You can even do something like this as a shorthand:

<group ref="instance('state')/thing1[.='shown']">
   ...
</group>

Then you can say
  <setvalue ref="instance('state')/thing1">shown</setvalue>
to show it and
  <setvalue ref="instance('state')/thing1">hidden</setvalue>
to hide it.

Strictly speaking you have to say
 <group ref="instance('state')/thing1Shown[self::node()='shown']">

but most XPath 1.0 processors allow . to mean self::node() in predicates
(it's an oversight in the XPath 1.0 spec that left it out of the
production rule, I think.)

Leigh.

-----Original Message-----
From: dev-tech-xforms-bounces+leigh.klotz=[hidden email]
[mailto:dev-tech-xforms-bounces+leigh.klotz=[hidden email]]
On Behalf Of Aaron Reed
Sent: Wednesday, June 04, 2008 9:36 AM
To: [hidden email]
Subject: Re: xforms-hide


If I understand what you want, you just want a container that can hide
its contents upon command.  Should be pretty simple to do in XBL.  But
how would you notify it that it needs to hide or show its contents?
Toggle currently is hardwired to only work with case and switch.  But I
think that you should be able to make your own toggle (again, using xbl)
to trigger the hide element to show or hide itself (which would show or
hide its contents).

One thing to keep in mind is that just because you are hiding things
doesn't mean that it'll behave exactly as if things that are irrelevant.

  There are rules of relevancy that won't be enforced because the hidden
controls aren't irrelevant according to MVC, but rather they are just
visually hidden.

--Aaron

[hidden email] wrote:
> On Jun 4, 4:42 am, "Klotz, Leigh" <[hidden email]> wrote:
>> Yes, please do go ahead and post your ideas.
>>
>> You don't need to add and remove nodes, by the way.  You can use a
>> second instance to model the capabilities, then use bind/@relevant to

>> assign relevance to the nodes indicating the various capabilities.
>> trigger/@ref then makes the trigger obey the capability relevance.
>> group/@ref does the same.
>>
>> <instance id="capabilities">
>>   <data xmlns="">
>>     <canEdit />
>>     <canAdd />
>>     <canDelete />
>>   </data>
>> </instance>
>>
>> <bind nodeset="instance('capabilities')">
>>   <bind nodeset="canEdit" relevant="instance('login')/username!=''"
/>

>>   <bind nodeset="canAdd" relevant="instance('session')/username ==
>> instance('document')/owner or instance('login')/username='admin'" />
>>   <bind nodeset="canDelete"
>> relevant="instance('login')/username=='admin'" /> </bind>
>>
>> <group ref="instance('capabilities')/canEdit">
>>  <trigger ref="instance('capabilities')/canAdd">
>>   <label>Add</label>
>>   <insert ev:event="DOMActivate" ref="..." ... />  </trigger>  
>> <trigger ref="instance('capabilities')/canDelete">
>>   <label>Delete</label>
>>   <delete ev:event="DOMActivate" ref="..." ... />  </trigger>
>> </group>
>>
>> Leigh.
>>
>> -----Original Message-----
>> From: dev-tech-xforms-bounces+leigh.klotz=[hidden email]
>>
>> [mailto:dev-tech-xforms-bounces+leigh.klotz=[hidden email]
>> rg]
>> On Behalf Of Aaron Reed
>> Sent: Tuesday, June 03, 2008 1:22 PM
>> To: [hidden email]
>> Subject: Re: xforms-hide
>>
>> Boy, the idea sounds familiar, but I'm not sure.  You'd have to check

>> the public archives of the working group to see if they've considered

>> it before (http://www.w3.org/MarkUp/Forms/#email11).  If you don't
>> see it in the archives, I'd suggest posting to one of the mailing
>> lists with your idea.
>>
>> --Aaron
>>
>> [hidden email] wrote:
>>> Okay, well I don't think there's any such thing as xforms-hide, but
>>> does anyone know if there are any plans for such a thing in the
>>> xforms future? Let me explain.
>>> I often have sections of my application that I want to hide behind a

>>> button. I currently use two approaches. First, I use an xforms
>>> switch/ case with only two cases, the first case is empty and the
>>> second case contains the data (or form elements) that I want to
hide.
>>> seehttp://ztags4xforms.com/wordpress/?p=33
>>> This works really well but it is verbose and encumbers the page for
>>> anything other than a small scale app.
>>> The other approach is to use xforms-bind with the  relevance
>>> attribute, but I feel as if this violates MVC. I don't like creating

>>> and inserting new elements in my initial model--which should
>>> represent only my working data, not the use of my controls. I can
>>> make another model or instance for manipulating the relevance of
>>> controls, but this can also be as cumbersome as using switch case,
>>> not to mention is effects the .
>>> I'm just wondering if anyone has ever discussed this at the
>>> standards level, having a trigger that is represented like this:
>>> <xforms-hide hidden="yes" appearance="minimal">
>>>          data or form elements here
>>> </xforms-hide> <!-- hidden="on" means the section is initially
>>> hidden
>>> -->
>>> <xforms-hide hidden="off" appearance="minimal">
>>>          data or form elements here
>>> </xforms-hide> <!-- hidden="off"  means the section is initially
>>> displayed --> It seems to me that everything is already in place;
>>> one could just build a trigger on top of the switch/case toggle as
>>> in my example (I think it could be done with XBL, but I'm not sure).
>> _______________________________________________
>> dev-tech-xforms mailing list
>> [hidden email]://lists.mozilla.org/listinfo/d
>> ev-tech-xforms
>
> Thanks Leigh,
> Although I do use this approach sometimes, the problem with this
> approach is that when you build a substantial app, you end up with
> this huge instance just for controls with all these relevance binds
> because each "hide/unhide" trigger for each section has to have a
> separate relevance element, otherwise, one trigger would hide/unhide
> all the sections at the same time. Usually, a person only wants to
> hide/unhide one section at a time.   So you can see how unwieldy this
> can get in a large app.  And it gets even worse if you have some of
> these hide/unhides nested within one another. It also makes it
> difficult from an xpath point of view to keep up with where the xpath
> pointer is at any one time (I'm not an xpath expert so as I add more
> and more models or instances I often can't get my form to act in the
> way I expect and this costs me hours and hours of programming time
> trying to figure the xpath reference).
>
> Do you think that xbl is the way to go for now?  Like I said, I've
> never done xbl, so I'd prefer some feedback as to whether it's even
> possible before I delve into something that might not work.
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

RE: xforms-hide

Klotz, Leigh
In reply to this post by dr.cw.ray
If you're finding that the existing interoperable techniques don't work,
and you'd rather not just use switch/case for other reasons, then it's
appropriate to move into XBL.  My advice is to try to use keep the
XForms markup expressing the intent, and use the XBL and CSS to control
the behavior tweaks.

When you write up your use case for this, please do send it to www-forms
because this issue is one that we'll be discussing next week at our
four-day group meeting, and it would be valuable to have your experience
as a form author on carving out your problem so that the markup
expresses the intent and the XBL (as Aaron says) can implement the
behavior.

Leigh.

From: dev-tech-xforms-bounces+leigh.klotz=[hidden email]
[mailto:dev-tech-xforms-bounces+leigh.klotz=[hidden email]]
On Behalf Of [hidden email]
Sent: Wednesday, June 04, 2008 1:39 AM
To: [hidden email]
Subject: Re: xforms-hide
...
Thanks Leigh,
Although I do use this approach sometimes, the problem with this
approach is that when you build a substantial app, you end up with this
huge instance just for controls with all these relevance binds because
each "hide/unhide" trigger for each section has to have a separate
relevance element, otherwise, one trigger would hide/unhide all the
sections at the same time. Usually, a person only wants to
hide/unhide one section at a time.   So you can see how unwieldy this
can get in a large app.  And it gets even worse if you have some of
these hide/unhides nested within one another. It also makes it difficult
from an xpath point of view to keep up with where the xpath pointer is
at any one time (I'm not an xpath expert so as I add more and more
models or instances I often can't get my form to act in the way I expect
and this costs me hours and hours of programming time trying to figure
the xpath reference).

Do you think that xbl is the way to go for now?  Like I said, I've never
done xbl, so I'd prefer some feedback as to whether it's even possible
before I delve into something that might not work.
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: xforms-hide

dr.cw.ray
In reply to this post by dr.cw.ray
On Jun 5, 1:08 am, "Klotz, Leigh" <[hidden email]> wrote:

> If you're finding that the existing interoperable techniques don't work,
> and you'd rather not just use switch/case for other reasons, then it's
> appropriate to move into XBL.  My advice is to try to use keep the
> XForms markup expressing the intent, and use the XBL and CSS to control
> the behavior tweaks.
>
> When you write up your use case for this, please do send it to www-forms
> because this issue is one that we'll be discussing next week at our
> four-day group meeting, and it would be valuable to have your experience
> as a form author on carving out your problem so that the markup
> expresses the intent and the XBL (as Aaron says) can implement the
> behavior.
>
> Leigh.
>
> From: dev-tech-xforms-bounces+leigh.klotz=[hidden email]
> [mailto:dev-tech-xforms-bounces+leigh.klotz=[hidden email]]
> On Behalf Of [hidden email]
> Sent: Wednesday, June 04, 2008 1:39 AM
> To: [hidden email]
> Subject: Re: xforms-hide
> ...
> Thanks Leigh,
> Although I do use this approach sometimes, the problem with this
> approach is that when you build a substantial app, you end up with this
> huge instance just for controls with all these relevance binds because
> each "hide/unhide" trigger for each section has to have a separate
> relevance element, otherwise, one trigger would hide/unhide all the
> sections at the same time. Usually, a person only wants to
> hide/unhide one section at a time.   So you can see how unwieldy this
> can get in a large app.  And it gets even worse if you have some of
> these hide/unhides nested within one another. It also makes it difficult
> from an xpath point of view to keep up with where the xpath pointer is
> at any one time (I'm not an xpath expert so as I add more and more
> models or instances I often can't get my form to act in the way I expect
> and this costs me hours and hours of programming time trying to figure
> the xpath reference).
>
> Do you think that xbl is the way to go for now?  Like I said, I've never
> done xbl, so I'd prefer some feedback as to whether it's even possible
> before I delve into something that might not work.
> _______________________________________________
> dev-tech-xforms mailing list
> [hidden email]://lists.mozilla.org/listinfo/dev-tech-xforms

Thanks Leigh and Aaron.
To answer Aaron, my use of the "hide" control, would behave exactly
like a switch with only two cases; the first case is empty (holds no
content) so therefore, all you see is a trigger. The second case would
hold the content and form elements of the hidden section that would
appear when the trigger is clicked--- so there should be no concern
for relevance  (see code posted below).

I'll try to do this in xbl.
If anyone is curious as to the behavior I'm talking about, here's the
code of the way I do this now using switch/case. You can see that
there is no content in the first "case".
This particular example seems simple, but as you add and nest more and
more into your application, it gets messy--especially when the hidden
content of the several switch/cases gets lengthy.

<!-- ********** SWITCH/CASE TOGGLE***************************** -->
<!-- Lorem ipsum -->
           <xf:switch>
               <xf:case id="shut">
                  <xf:trigger appearance="minimal">
                     <xf:label>:: toggle ::</xf:label>
                     <xf:toggle case="open" ev:event="DOMActivate"/>
                  </xf:trigger>
               </xf:case>
               <xf:case id="open">
                  <xf:trigger appearance="minimal">
                     <xf:label>:: toggle ::</xf:label>
                     <xf:toggle case="shut" ev:event="DOMActivate"/>
                  </xf:trigger>

                  <h:div style="color:olive; font-size:95%;">
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor
incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
quis nostrud
exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum
dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non
proident,
sunt in culpa qui officia deserunt mollit anim id est laborum.
                  </h:div>

               </xf:case>
            </xf:switch>

<!-- ******* END SWITCH/CASE TOGGLE***************************** -->

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

Re: xforms-hide

dr.cw.ray
On Jun 5, 2:06 pm, [hidden email] wrote:

> On Jun 5, 1:08 am, "Klotz, Leigh" <[hidden email]> wrote:
>
>
>
> > If you're finding that the existing interoperable techniques don't work,
> > and you'd rather not just use switch/case for other reasons, then it's
> > appropriate to move into XBL.  My advice is to try to use keep the
> > XForms markup expressing the intent, and use the XBL and CSS to control
> > the behavior tweaks.
>
> > When you write up your use case for this, please do send it to www-forms
> > because this issue is one that we'll be discussing next week at our
> > four-day group meeting, and it would be valuable to have your experience
> > as a form author on carving out your problem so that the markup
> > expresses the intent and the XBL (as Aaron says) can implement the
> > behavior.
>
> > Leigh.
>
> > From: dev-tech-xforms-bounces+leigh.klotz=[hidden email]
> > [mailto:dev-tech-xforms-bounces+leigh.klotz=[hidden email]]
> > On Behalf Of [hidden email]
> > Sent: Wednesday, June 04, 2008 1:39 AM
> > To: [hidden email]
> > Subject: Re: xforms-hide
> > ...
> > Thanks Leigh,
> > Although I do use this approach sometimes, the problem with this
> > approach is that when you build a substantial app, you end up with this
> > huge instance just for controls with all these relevance binds because
> > each "hide/unhide" trigger for each section has to have a separate
> > relevance element, otherwise, one trigger would hide/unhide all the
> > sections at the same time. Usually, a person only wants to
> > hide/unhide one section at a time.   So you can see how unwieldy this
> > can get in a large app.  And it gets even worse if you have some of
> > these hide/unhides nested within one another. It also makes it difficult
> > from an xpath point of view to keep up with where the xpath pointer is
> > at any one time (I'm not an xpath expert so as I add more and more
> > models or instances I often can't get my form to act in the way I expect
> > and this costs me hours and hours of programming time trying to figure
> > the xpath reference).
>
> > Do you think that xbl is the way to go for now?  Like I said, I've never
> > done xbl, so I'd prefer some feedback as to whether it's even possible
> > before I delve into something that might not work.
> > _______________________________________________
> > dev-tech-xforms mailing list
> > [hidden email]://lists.mozilla.org/listinfo/dev-tech-xforms
>
> Thanks Leigh and Aaron.
> To answer Aaron, my use of the "hide" control, would behave exactly
> like a switch with only two cases; the first case is empty (holds no
> content) so therefore, all you see is a trigger. The second case would
> hold the content and form elements of the hidden section that would
> appear when the trigger is clicked--- so there should be no concern
> for relevance  (see code posted below).
>
> I'll try to do this in xbl.
> If anyone is curious as to the behavior I'm talking about, here's the
> code of the way I do this now using switch/case. You can see that
> there is no content in the first "case".
> This particular example seems simple, but as you add and nest more and
> more into your application, it gets messy--especially when the hidden
> content of the several switch/cases gets lengthy.
>
> <!-- ********** SWITCH/CASE TOGGLE***************************** -->
> <!-- Lorem ipsum -->
>            <xf:switch>
>                <xf:case id="shut">
>                   <xf:trigger appearance="minimal">
>                      <xf:label>:: toggle ::</xf:label>
>                      <xf:toggle case="open" ev:event="DOMActivate"/>
>                   </xf:trigger>
>                </xf:case>
>                <xf:case id="open">
>                   <xf:trigger appearance="minimal">
>                      <xf:label>:: toggle ::</xf:label>
>                      <xf:toggle case="shut" ev:event="DOMActivate"/>
>                   </xf:trigger>
>
>                   <h:div style="color:olive; font-size:95%;">
> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
> eiusmod tempor
> incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
> quis nostrud
> exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
> Duis aute irure dolor in reprehenderit in voluptate velit esse cillum
> dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non
> proident,
> sunt in culpa qui officia deserunt mollit anim id est laborum.
>                   </h:div>
>
>                </xf:case>
>             </xf:switch>
>
> <!-- ******* END SWITCH/CASE TOGGLE***************************** -->

HI,
sorry to trouble you Aaron,
But did you mean that if I build a container to show and hide elements
with an XBL custom control, that if any of the content within the
container is an xform control or other such element that is dependent
on an xforms-bind @relevance, that these relevance binds won't be
operable within the container?  Obviously, you can put any kind of
bound form elements within a switch-case, but I think what you are
saying is that if I want the same behaviour in building a custom xbl
control, that I might run into trouble, is that right?
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: xforms-hide

Aaron Reed

In the spec, it says for case elements, "This element encloses markup to
be conditionally rendered. The content elements (e.g. form controls,
groups, switches, repeats and host language elements) within a
non-selected case behave as if they were in a non-relevant group (see
9.1.1 The group Element). Similarly, content elements in a case that
becomes selected behave as if they were in a group that has become
relevant.  The attribute selected determines the initial selected state."

I'm saying that there is more to 'behaving as if they were in a group
that has become relevant' or non-relevant than just showing and hiding
them.  For example, though styling, relevancy doesn't have to mean
showing and hiding but could mean other things.  The odds are none of
this will matter to you, I just wanted to point it out.

Another thing is that I've never tried writing a custom action element
(i.e. writing your own toggle) in XBL.  I don't think that there is any
reason that it won't work, though.  You'll just have to make sure that
you implement the correct interfaces.

--Aaron

[hidden email] wrote:

>
> HI,
> sorry to trouble you Aaron,
> But did you mean that if I build a container to show and hide elements
> with an XBL custom control, that if any of the content within the
> container is an xform control or other such element that is dependent
> on an xforms-bind @relevance, that these relevance binds won't be
> operable within the container?  Obviously, you can put any kind of
> bound form elements within a switch-case, but I think what you are
> saying is that if I want the same behaviour in building a custom xbl
> control, that I might run into trouble, is that right?
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

RE: xforms-hide

Klotz, Leigh
Too bad xslt stylesheets don't work with xforms in mozilla (yet).
This would be an excellent one to write as simple converter to switch.
Leigh.

-----Original Message-----
From: dev-tech-xforms-bounces+leigh.klotz=[hidden email]
[mailto:dev-tech-xforms-bounces+leigh.klotz=[hidden email]]
On Behalf Of Aaron Reed
Sent: Thursday, June 05, 2008 10:38 AM
To: [hidden email]
Subject: Re: xforms-hide


In the spec, it says for case elements, "This element encloses markup to
be conditionally rendered. The content elements (e.g. form controls,
groups, switches, repeats and host language elements) within a
non-selected case behave as if they were in a non-relevant group (see
9.1.1 The group Element). Similarly, content elements in a case that
becomes selected behave as if they were in a group that has become
relevant.  The attribute selected determines the initial selected
state."

I'm saying that there is more to 'behaving as if they were in a group
that has become relevant' or non-relevant than just showing and hiding
them.  For example, though styling, relevancy doesn't have to mean
showing and hiding but could mean other things.  The odds are none of
this will matter to you, I just wanted to point it out.

Another thing is that I've never tried writing a custom action element
(i.e. writing your own toggle) in XBL.  I don't think that there is any
reason that it won't work, though.  You'll just have to make sure that
you implement the correct interfaces.

--Aaron

[hidden email] wrote:
>
> HI,
> sorry to trouble you Aaron,
> But did you mean that if I build a container to show and hide elements

> with an XBL custom control, that if any of the content within the
> container is an xform control or other such element that is dependent
> on an xforms-bind @relevance, that these relevance binds won't be
> operable within the container?  Obviously, you can put any kind of
> bound form elements within a switch-case, but I think what you are
> saying is that if I want the same behaviour in building a custom xbl
> control, that I might run into trouble, is that right?
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

RE: xforms-hide

Clark, John
Oh my: XSLT + XForms in Mozilla?  You are SUCH a tease!  ;-)

Peace,

    John


-----Original Message-----
From: dev-tech-xforms-bounces+clarkj2=[hidden email] on behalf of Klotz, Leigh
Sent: Thu 6/5/2008 2:08 PM
To: Aaron Reed; [hidden email]
Subject: RE: xforms-hide
 
Too bad xslt stylesheets don't work with xforms in mozilla (yet).
This would be an excellent one to write as simple converter to switch.
Leigh.

-----Original Message-----
From: dev-tech-xforms-bounces+leigh.klotz=[hidden email]
[mailto:dev-tech-xforms-bounces+leigh.klotz=[hidden email]]
On Behalf Of Aaron Reed
Sent: Thursday, June 05, 2008 10:38 AM
To: [hidden email]
Subject: Re: xforms-hide


In the spec, it says for case elements, "This element encloses markup to
be conditionally rendered. The content elements (e.g. form controls,
groups, switches, repeats and host language elements) within a
non-selected case behave as if they were in a non-relevant group (see
9.1.1 The group Element). Similarly, content elements in a case that
becomes selected behave as if they were in a group that has become
relevant.  The attribute selected determines the initial selected
state."

I'm saying that there is more to 'behaving as if they were in a group
that has become relevant' or non-relevant than just showing and hiding
them.  For example, though styling, relevancy doesn't have to mean
showing and hiding but could mean other things.  The odds are none of
this will matter to you, I just wanted to point it out.

Another thing is that I've never tried writing a custom action element
(i.e. writing your own toggle) in XBL.  I don't think that there is any
reason that it won't work, though.  You'll just have to make sure that
you implement the correct interfaces.

--Aaron

[hidden email] wrote:
>
> HI,
> sorry to trouble you Aaron,
> But did you mean that if I build a container to show and hide elements

> with an XBL custom control, that if any of the content within the
> container is an xform control or other such element that is dependent
> on an xforms-bind @relevance, that these relevance binds won't be
> operable within the container?  Obviously, you can put any kind of
> bound form elements within a switch-case, but I think what you are
> saying is that if I want the same behaviour in building a custom xbl
> control, that I might run into trouble, is that right?
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms





===================================

P Please consider the environment before printing this e-mail

Cleveland Clinic is ranked one of the top hospitals
in America by U.S. News & World Report (2007).  
Visit us online at http://www.clevelandclinic.org for
a complete listing of our services, staff and
locations.


Confidentiality Note:  This message is intended for use
only by the individual or entity to which it is addressed
and may contain information that is privileged,
confidential, and exempt from disclosure under applicable
law.  If the reader of this message is not the intended
recipient or the employee or agent responsible for
delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If
you have received this communication in error,  please
contact the sender immediately and destroy the material in
its entirety, whether electronic or hard copy.  Thank you.
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: xforms-hide

dr.cw.ray
In reply to this post by Aaron Reed
On Jun 6, 1:37 am, Aaron Reed <[hidden email]> wrote:

> In the spec, it says for case elements, "This element encloses markup to
> be conditionally rendered. The content elements (e.g. form controls,
> groups, switches, repeats and host language elements) within a
> non-selected case behave as if they were in a non-relevant group (see
> 9.1.1 The group Element). Similarly, content elements in a case that
> becomes selected behave as if they were in a group that has become
> relevant.  The attribute selected determines the initial selected state."
>
> I'm saying that there is more to 'behaving as if they were in a group
> that has become relevant' or non-relevant than just showing and hiding
> them.  For example, though styling, relevancy doesn't have to mean
> showing and hiding but could mean other things.  The odds are none of
> this will matter to you, I just wanted to point it out.
>
> Another thing is that I've never tried writing a custom action element
> (i.e. writing your own toggle) in XBL.  I don't think that there is any
> reason that it won't work, though.  You'll just have to make sure that
> you implement the correct interfaces.
>
> --Aaron
>
> [hidden email] wrote:
>
> > HI,
> > sorry to trouble you Aaron,
> > But did you mean that if I build a container to show and hide elements
> > with an XBL custom control, that if any of the content within the
> > container is an xform control or other such element that is dependent
> > on an xforms-bind @relevance, that these relevance binds won't be
> > operable within the container?  Obviously, you can put any kind of
> > bound form elements within a switch-case, but I think what you are
> > saying is that if I want the same behaviour in building a custom xbl
> > control, that I might run into trouble, is that right?

Thanks Aaron, I get what your saying now.
_______________________________________________
dev-tech-xforms mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xforms
Reply | Threaded
Open this post in threaded view
|

Re: xforms-hide

dr.cw.ray
On Jun 6, 4:40 am, [hidden email] wrote:

> On Jun 6, 1:37 am, Aaron Reed <[hidden email]> wrote:
>
>
>
> > In the spec, it says for case elements, "This element encloses markup to
> > be conditionally rendered. The content elements (e.g. form controls,
> > groups, switches, repeats and host language elements) within a
> > non-selected case behave as if they were in a non-relevant group (see
> > 9.1.1 The group Element). Similarly, content elements in a case that
> > becomes selected behave as if they were in a group that has become
> > relevant.  The attribute selected determines the initial selected state."
>
> > I'm saying that there is more to 'behaving as if they were in a group
> > that has become relevant' or non-relevant than just showing and hiding
> > them.  For example, though styling, relevancy doesn't have to mean
> > showing and hiding but could mean other things.  The odds are none of
> > this will matter to you, I just wanted to point it out.
>
> > Another thing is that I've never tried writing a custom action element
> > (i.e. writing your own toggle) in XBL.  I don't think that there is any
> > reason that it won't work, though.  You'll just have to make sure that
> > you implement the correct interfaces.
>
> > --Aaron
>
> > [hidden email] wrote:
>
> > > HI,
> > > sorry to trouble you Aaron,
> > > But did you mean that if I build a container to show and hide elements
> > > with an XBL custom control, that if any of the content within the
> > > container is an xform control or other such element that is dependent
> > > on an xforms-bind @relevance, that these relevance binds won't be
> > > operable within the container?  Obviously, you can put any kind of
> > > bound form elements within a switch-case, but I think what you are
> > > saying is that if I want the same behaviour in building a custom xbl
> > > control, that I might run into trouble, is that right?
>
> Thanks Aaron, I get what your saying now.

I have a post and a snippet of code over at the xbl groups that sheds
some light on using xbl in this situation, you can check it out.
http://groups.google.com/group/mozilla.dev.tech.xbl/browse_thread/thread/5800f36c9d389a96#

In short, xforms-action elements have no effect currently in xbl,
although the xbl2.0 specs (see 3.2.1 Xforms Actions) indicate that it
is theoretically possible. I don't know if any developers are actively
moving in that direction though--but I hope so.  That would add some
tremendous power to xforms.

I did use xbl for a simple"hide" binding.   I did this by pulling out
the xforms-setvalue element from the binding and leaving it in the
main body of the document. However, it's probably not very practical
or any better than the normal way (using relevance, that is) other
than maybe getting just a bit of clutter out of the structure of your
main document. But it does work (see the xbl post above).

Switch/case on the other hand seems to be problematic in that even
though I pulled out the xforms-toggle elements and left them in the
main body, it still wouldn't work. I think that's because, as Aaron
said, the toggle is a unique element specifically tied to the switch
and case elements.


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