Hi again,
Many Thanks to all, for the answers.
Only a question to close this issue.
In the previous example replacing the first <action> element with a
<message>:
....
<xforms:trigger id="trigger1">
<xforms:label>Button1</xforms:label>
<xforms:message level="modal" ev:event="DOMActivate" ev:target="trigger1"
ev:observer="trigger1" ev:handler="#action2">
First Hello!!
</xforms:message>
</xforms:trigger>
<xforms:trigger>
<xforms:label>Button2</xforms:label>
<xforms:message id="action2" level="modal" ev:event="DOMActivate">
Second Hello
</xforms:message>
</xforms:trigger>
....
I think the first message shouldnÂ´t be triggered because it doesnÂ´t work as
a handler, but IÂ´m not pretty sure, what do you think?
Regards.
Roger.
-----Mensaje original-----
De: www-forms-request@w3.org [mailto:www-forms-request@w3.org] En nombre de
Mark Birbeck
Enviado el: viernes, 28 de julio de 2006 19:10
Para: www-forms@w3.org
Asunto: Re: Event questions.
Hi Rogelio,
> 1- The latest XForms 1.0 recommendation doesnÂ´t forbid a handler
> attribute in an <action> element,so does it mean that an <action> can
> be defined with a handler attribute pointing to another <action>?
>
> (This can be usefull in order to reuse code).
>
> Something like that should it work?
>
> ....
>
> <xforms:trigger id="trigger1">
> <xforms:label>Button1</xforms:label>
> <xforms:action ev:event="DOMActivate" ev:target="trigger1"
> ev:observer="trigger1" ev:handler="action2"/> </xforms:trigger>
> <xforms:trigger>
> <xforms:label>Button2</xforms:label>
> <xforms:message id="action2" level="modal" ev:event="DOMActivate">
> Hi again!!</xforms:message>
>
> </xforms:trigger>
> ......
>
> I mean, when the "Button1" is pressed should the message be shown?
Yes. (Although you would specify @handler="#action2".)
> 2- What is the interpretation of an <action> in terms of XML Events,
> is it a listener or can be always considered like a handler?
Mmm...well, it's sort of both. In DOM 2 Events there isn't much of a
distinction between the two. We have EventListener objects, which are added
to the list of listeners waiting for an event to be fired, and when the
event actually arrives, the handleEvent() method on the EventListener object
is invoked. Since the handleEvent() method is always 'on' the EventListener
object then any reuse of handlers you might have is outside of the scope of
DOM 2 Events, and would be achieved by making handleEvent() call some other
function.
But in XML Events the listener and the handler can be separate.
Elements like xf:setvalue are *always* handlers, but they can also be
listeners if they have @ev:event on them. xf:action is a handler too, but
it's role is simply to invoke the handleEvent() methods of its children. As
with other handlers, whether it is also a listener depends on whether it has
the @ev:event attribute.
> 3- What is the aim of having events in a <model> element, more
> specifically what does this sentence mean?
>
> "Attributes from XML Events are allowed on this element to facilitate
> creating observers"
I don't really know why that's in the spec, since although it's true, it's
no more true for xf:model than it is for any other element. All it's saying
is that you can place attributes from XML Events onto xf:model, but that
doesn't make it an action handler, just a listener.
So you could do this:
<xf:model ev:event="xforms-submit-error"
ev:handler="#allsubmiterrorsgohere">
...
</xf:model>
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/