RE: Binding to nodes that do not exist

Hi Chimezie,

> I have a scenario where I need to display action buttons to trigger a
> process for 'adding' nodes to an XForms instance (an 'Add New' button,
> for instance).  However, I'd like for these buttons to be displayed
> only if the node in question does *not* appear in the instance.  I
> can't figure how this could be done since the mechanism for binding to
> instance nodes depends on whether or not the binding XPath evaluates
> to a nodeset or not.  I could use the XPath 1.0 'not' function (wrapped
> around the path to the node), but that would only return a boolean value
> of 'true' which would cause any control/group bound to it to *not* appear
> (since it's not a nodeset with size).  Is there an easy solution to this
> problem that I'm overlooking?

The most obvious thing would be to place the test on the parent element. The
XPath would then be to show the trigger if there is a parent of the right
type, but with no children.

However, there are a many situations in XForms where the actual data itself
isn't quite right for driving the UI. In most of the forms we do that are of
any complexity, we invariably have to place an instance at the top of all of
our forms called something like 'inst-control'. This contains all of the
rules that will control the UI itself. So if, for example, you have previous
and next triggers that step through a set of values, and you want to show
and hide the triggers based on the position in the list, then we'd place two
nodes in the control instance, and set up a relevance expression based on
the position within the appropriate nodeset.
 
It sounds to me like you could do something similar if testing the parent is
not appropriate, and I would say it's not actually a bad solution; the extra
level of indirection (i.e., creating nodes that will hold the results of
some rules, rather than using rules on the data itself) allows you more
complex rules, and something we find very important, it allows you to re-use
the logic (or pattern).

For example, two triggers that are disabled at the beginning and end of a
list could be defined like this:
 
  <xf:instance id="inst-control">
    <control xmlns="">
      <current >
      <next />
      <prev />
    </control>
  </xf:instance>
 
  <xf:instance id="inst-data">
    <customers>
      <customer />
      <customer />
    </customer>
  </xf:instance>
 
  <xf:bind nodeset="instance('inst-control')>
    <xf:bind
     id="f-next"
     nodeset="next"
     relevant="../current &lt;
       count(instance('inst-data')/customer)"
    />
    <xf:bind
     id="f-prev"
     nodeset="prev"
     relevant="../current &gt; 0"
    />
  </xf:bind>
 
  <xf:trigger bind="f-next">
    ...
  </xf:trigger>
 
  <xf:trigger bind="f-prev">
    ...
  </xf:trigger>
 
And so on.
 
Regards,
 
Mark
 

Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Thursday, 8 September 2005 16:24:18 UTC