RE: xforms:choose/if?

Hi Mark,

I can agree that other languages besides xforms might need
conditional execution of the handlers associated with events.
I also agree with (and don't see what I said earlier as not
agreeing with) the assertion that it is the handlers and not
the events themselves that are conditionally occuring.

Therefore, I also agree that a syntax like the one you showed
here:

  <xf:action ev:event="my-delete">
    <xf:delete ... />
    <xf:insert ev:condition="[empty nodeset]" />
  </xf:action>

is workable.  I.e. putting the condition attribute
in the events namespace is just a matter of namespacing,
and the essential detail of having fine grain control
of action execution is achieved.

But putting 'condition' in the events namespace seems to
be incongruous with what XML events does, currently at least.
Unlike Section 3.5 of the current spec, is it the case that
the next version of XML events intends to "require an 
application that uses XML events to use" a "particular method 
for specifying handlers"?

What I'm getting at is simply that the condition attribute
indicates what a handler should be doing, and this is the
domain of the language that consumes XML events, not of XML
events (1.0 anyway).

Cheers,
John Boyer, Ph.D.
Senior Product Architect and Research Scientist
PureEdge Solutions Inc.



-----Original Message-----
From: Mark Birbeck [mailto:mark.birbeck@x-port.net]
Sent: Tuesday, April 05, 2005 3:51 AM
To: John Boyer
Cc: www-forms@w3.org; 'Klotz, Leigh'
Subject: RE: xforms:choose/if?


Hi John,

I understand your point, but XForms is not the only language with handlers,
and certainly as we move towards mixed-namespace documents (dare I say
"internet applications" ;) ) then we need to be able to make *any* handler
conditional.

But as it happens, I think my suggestion does what you want, John. Although
putting @condition on a handler looks like it is making the *event*
conditional, it actually can only make the handlers conditional.

The reason I say this is that 'conditional events' would need to be
consistent with DOM 2 Events [1], since it can only be XML mark-up layered
on top of the DOM. Of course we could add 'conditional events' to DOM 2
Events but that adds a whole other layer of work -- for a start we'd need to
modify the addEventListener() method on EventTarget [2], but then we'd also
have to decide whether you can have more than one listener for different
conditions on the same event (in which case removeEventListener() also needs
changing), we'd have to decide whether listeners with no conditions still
'see' the event, and so on, all of which would take a lot of time.

So, if we agree that we will register for events in the same way that we do
now, the conditional aspect has to come from the *handler* side; the event
fires no matter what the condition, but we test the condition in the handler
to see if we actually perform the action. This we *can* control, because we
can write our handleEvent() method on the EventListener [3] with a test
right at the top.

This means that the handleEvent() method for this:

  <xf:send ev:condition="a &gt; b" submission="s" />

would look like this:

  handleEvent(evt)
  {
    if (a > b)
    {
      /* do submission */
    }
    return;
  }

We've therefore left DOM 2 Events completely intact, and merely added some
mark-up that defines a condition to be tested in a handler. I believe that
this would give you exactly what you want, for example:

  <xf:action ev:event="my-delete">
    <xf:delete ... />
    <xf:insert ev:condition="[empty nodeset]" />
  </xf:action>

Regards,

Mark

[1] <http://www.w3.org/TR/DOM-Level-2-Events/>
[2] <http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventTarget>
[3]
<http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener>

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/ 

> -----Original Message-----
> From: www-forms-request@w3.org 
> [mailto:www-forms-request@w3.org] On Behalf Of John Boyer
> Sent: 05 April 2005 01:00
> To: Klotz, Leigh; jeacott@hardlight.com.au; Alexander Anokhin
> Cc: www-forms@w3.org
> Subject: RE: xforms:choose/if?
> 
> 
> As I see it, though, one problem with that approach is that 
> it is too coarse grain.
> 
> The conditional execution really needs to be coming from 
> XForms because what is frequently needed is the ability to 
> optionally run one (or more) of several actions in the 
> handler for an event.
> It would be hacky to have to handle these cases as dispatch actions.
> 
> For example, there is already some conditionality in certain 
> XForms actions, and it is quite useful.  I have a table-based 
> form in which the 'delete row' button should always set the 
> focus back to the table, but can do one of two things:
> 
> 1) Let the delete nodeset be empty if the last row.
> 2) Always delete, but if the last relevant row was deleted,
> 	only then insert from a non-relevant row containing
> 	prototypical instance data.
> 
> Note that this latter approach is *the only way* to sensibly 
> manage the outer-repeat of a two-level table.
> 
> When a delete or insert action has an empty nodeset, they 
> no-op.  Since the nodeset is expressed as XPath, you can do a 
> pretty good job of defining conditional execution for these 
> two actions. And, as stated above, there are real cases where 
> we need to conditionally execute just these actions within a 
> larger stream of actions in a single handler.
> 
> Cheers,
> John Boyer, Ph.D.
> Senior Product Architect and Research Scientist PureEdge 
> Solutions Inc.
> 
> 
> 
> 
> 
> -----Original Message-----
> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org]On
> Behalf Of Klotz, Leigh
> Sent: Monday, April 04, 2005 4:47 PM
> To: jeacott@hardlight.com.au; Alexander Anokhin
> Cc: www-forms@w3.org
> Subject: RE: xforms:choose/if?
> 
> 
> 
> I think an XSLT-like choose/when for XML Events handlers 
> would be great.
> I don't see it in the XForms 1.1 requirements document, but 
> as Mark Birbeck said, I would find it most welcome coming 
> from an XML Events 2 recommendation.
> Leigh.
> 
> -----Original Message-----
> From: www-forms-request@w3.org 
> [mailto:www-forms-request@w3.org] On Behalf Of Jason Eacott
> Sent: Friday, April 01, 2005 1:09 AM
> To: Alexander Anokhin
> Cc: www-forms@w3.org
> Subject: Re: xforms:choose/if?
> 
> 
> that's a lot of messing about to achieve a simple 'if then else' huh.
> I really hope that a better way becomes available soon.
> 
> 
> 
> Date sent:      	Fri, 01 Apr 2005 11:23:32 +0500
> From:           	Alexander Anokhin <ava@vaz.ru>
> Send reply to:  	ava@vaz.ru
> Organization:   	AVTOVAZ JSC
> To:             	Mark Birbeck <mark.birbeck@x-port.net>
> Copies to:      	www-forms@w3.org
> Subject:        	Re: xforms:choose/if?
> Forwarded by:   	www-forms@w3.org
> Date forwarded: 	Fri, 01 Apr 2005 06:24:53 +0000
> 
> > 
> > Mark Birbeck:
> > > Alexander,
> > > 
> > > The only way you can do this *today* is with a little bit 
> of script
> (see
> > > below).
> > > 
> > > For the future, some work has been done in XML Events 2 
> to provide 
> > > conditional event handlers, which would do pretty much what you
> want...
> > 
> > 
> > If someone interested in, the way i choose to realize such thing
> (thanx 
> > to Giovanni Motta for idea)
> > 
> > I've made an additional instance wich is contains one copy of 
> > "count_result" for every condition, like this:
> > <xforms:instance id="choose">
> >    <data xmlns="">
> >      <eq0>84</eq0>
> >      <eq1>84</eq1>
> >      <gt1>84</gt1>
> >    </data>
> > </xforms:instance>
> > 
> > ...add binds and event handlers:
> > 
> > <xforms:bind id="eq0_bind" nodeset="instance('choose')/eq0" 
> > constraint="not(. = '0') or . = ''"/>
> > <xforms:bind id="eq1_bind" nodeset="instance('choose')/eq1" 
> > constraint="not(. = '1') or . = ''"/>
> > <xforms:bind id="gt1_bind" nodeset="instance('choose')/gt1" 
> > constraint="not(. &gt; '1') or . = ''"/>
> > 
> > <xforms:action ev:event="eq0_event">
> >    <xforms:message level="modal">eq0</xforms:message>
> > </xforms:action>
> > 
> > <xforms:action ev:event="eq1_event">
> >    <xforms:message level="modal">eq1</xforms:message>
> > </xforms:action>
> > 
> > <xforms:action ev:event="changed3">
> >    <xforms:message level="modal">gt1</xforms:message>
> > </xforms:action>
> > 
> > Finally the hidden controls for dispatch "xforms-invalid" event:
> > 
> > <xforms:input bind="eq0_bind" style="display:none;">
> >      <xforms:dispatch ev:event="xforms-invalid" name="eq0_event" 
> > target="mymodel"/>
> > </xforms:input>
> > 
> > <xforms:input bind="eq1_bind" style="display:none;">
> >      <xforms:dispatch ev:event="xforms-invalid" name="eq1_event" 
> > target="mymodel"/>
> > </xforms:input>
> > 
> > <xforms:input bind="gt1_bind" style="display:none;">
> >      <xforms:dispatch ev:event="xforms-invalid" name="gt1_event" 
> > target="mymodel"/>
> > </xforms:input>
> > 
> > surely works on FormsPlayer 1.3.
> > 
> > --
> > Alexander Anokhin
> > AVTOVAZ JSC
> > email: ava@vaz.ru
> > icq: 123275798
> > 
> 
> 
> 
> 
> 
> 
>

Received on Tuesday, 5 April 2005 15:54:35 UTC