W3C home > Mailing lists > Public > www-forms@w3.org > December 2003

RE: xforms for inhomogenous collections

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Fri, 19 Dec 2003 14:18:17 -0000
To: "'Borgrink, Susan'" <sborgrink@progeny.net>
Cc: <www-forms@w3.org>
Message-ID: <017f01c3c63a$f5b6b320$6b01a8c0@W100>

Susan,

>  ... what I stated was how I interpreted this line from the
> specification for the relevant property section 6.1.4.
>
> "Inheritance Rules: If any ancestor node evaluates to XPath false,
> this value is treated as false. Otherwise, the local value is used."
>
>  If that is not the case can you please explain to me what this
statement means.

There is nothing wrong with the spec. The issue is that you have mixed
up the UI and the model.

The concepts of 'ancestor' and 'inheritance' all relate to the instance
data. So if you have:

    <a>
      <b>
        <c />
      </b>
      <d />
    </a>

then if some rule makes <a> not relevant, unless some other rule makes
<b> and <c> relevant, then they too will be not relevant. That's the
meaning of the spec.

So, let's first set up a CSS rule so that the state of the model can be
reflected to the UI. I'll say that any form control bound to
non-relevant instance data is to have a blue background:

    <style>
      /* for formsPlayer */
      .disabled { background-color: blue; }
      /* for X-Smiles */
      *:disabled { background-color: blue; }
    </style>

Then we need a rule:

    <xf:bind nodeset="b" relevant="false()" />

With this rule, all of the following would have a blue background:

    <xf:output ref="b/c" />

    <xf:input ref="b"><xf:label /></xf:input>

    <xf:group ref="b">
      Some text here ... All in blue
      <xf:input ref="../d"><xf:label /></xf:input>
    <xf:group>

But note that the first control is blue because the instance nodes <c>
has inherited its relevant status from <b>. However, the xf:input using
<d> is blue only because it has inherited CSS properties from xf:group -
i.e., nothing to do with relevant. If you were to take the control out
of the xf:group then it would not be blue.

To complete the picture using my previous example, if we now create CSS
rules to hide form controls bound to non-relevant instance data:

    <style>
      /* for formsPlayer */
      .disabled { display: none; }
      /* for X-Smiles */
      *:disabled { display: none; }
    </style>

then the xf:input bound to <d> that is inside the xf:group would now be
hidden (along with the text). But as we've said, that would have nothing
to do with <d> inheriting a relevant property, since it is not a
descendant of <b> - instead it is to do with the CSS from the xf:group
propagating down.

I hope that helps. I know this is tricky, but if you're working on an
implementation then you have to get this type of thing exactly right;
the connections between the model and the UI are a large part of what
give XForms its power.

Best regards,

Mark


Mark Birbeck
CEO and CTO
x-port.net Ltd.

For 100% of the XForms spec:
http://www.formsPlayer.com/
Received on Friday, 19 December 2003 09:26:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:56 GMT