We should look at the Xml events standard as a way to define multiple
events. Xml events provides a nice way to abstract out the event
definition from the components and allows developers to define more than
one event handler per event. We would be able to adapt this approach in
the future to allow developers to add the events to the browser
navigation stack.
The Expression syntax used by the event handlers should be simplified
and may consistent with the client-side object model. This mean
developers would only need to learn one syntax. For example:
onCommand="mco.myMco.callFunction(event, ui.myComponent)"
Should be equivalent to say
session.mco.myMco.callFunction(session.event, session.ui.myComponent);
or
session.mco.get("myMco").callFunction(session.event,
session.ui.get("myComponent")
One last thing on events: Our event syntax is doesn't provide a
mechanism to interact with the component to perform operations on them
to do common tasks. One last example: how does a developer close a
dialog from an event handler? They have to call an mco or create a
macro to remove the object from the DOM, an easier approach would be
onCommand="ui.myWindow.close()"
Bob
-----Original Message-----
From: David Gennaco [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 07, 2007 2:43 PM
To: [email protected]
Subject: RE: [jira] Commented: (XAP-317) It would be good to have
stackable events for our elements.
I've been thinking about this a little. If you were going to have
multiple event handlers chained sequentially, why not simply add a
property on the in-process client event on which it would be understood
that the return value could be set by any event handling code. That
way, during sequential processing, arbitrarily complex information could
be placed on the event proper and shared by the various handlers in the
sequence. If a short-circuit mechanism is desired, this could also be
part of the client event specification so a handler could indicate to
stop processing the sequence.
-----Original Message-----
From: Michael Turyn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 07, 2007 4:27 PM
To: [email protected]
Subject: RE: [jira] Commented: (XAP-317) It would be good to have
stackable events for our elements.
I thought of that ( mco:foo( mco:bar(event),event) ) but thought that
our declarative argument parser was hairy enough as it was; admittedly
you could just recurse in when you find an mco, but I think (what is
essentially) piped output is clearer and makes the evaluation order
first-last, as it would have been if my initial,
multiple-"onXXX=aHandler" proposal were permissible.
(Of course, keep in mind that I'm not fond of the mco syntax; I still
want an xml syntax with named parameters...this is distinct from any
illusion we'll get it.)
-----Original Message-----
From: Trevor Oldak (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Wed 3/7/2007 3:39 PM
To: [email protected]
Subject: [jira] Commented: (XAP-317) It would be good to have stackable
events for our elements.
[
https://issues.apache.org/jira/browse/XAP-317?page=com.atlassian.jira.pl
ugin.system.issuetabpanels:comment-tabpanel#action_12478885 ]
Trevor Oldak commented on XAP-317:
----------------------------------
Suppose we could say:
mco:A.bar(mco:A.foo(event), event)
thus making a mco a valid argument for another mco call. That was we use
the mco's already exist unique identifier (its ID) and elminate any
issues from people who want an element with id LAST_RESULT.
> It would be good to have stackable events for our elements.
> -----------------------------------------------------------
>
> Key: XAP-317
> URL: https://issues.apache.org/jira/browse/XAP-317
> Project: XAP
> Issue Type: Improvement
> Components: Macros, MCOs, Widgets, XML Dom / Parsing
> Reporter: Turyn, Michael
>
> I think >1 "onXXX" event attributes on an element should be allowed;:
> <aWidgetTag onMouseDown="mco:A.foo()"
> onMouseDown="mco:A.bar(...)" ..../> ---on the mouse down event they
would be called in the order declared; this would be good for
cutting-and-pasting functionality modularised as MCOs and Macros.
> This is one of the best things about the Dojo connect() mechanism, and
also seems to be in place for Yahoo UI dragging events.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
