Re: [wsrp] Ajax - event source

[Rich Thompson <richt2@us.ibm.com>]

Browsers are free to reuse event objects
once processing the event ends, so it would not be save to try and pass
it to the callback function. The proposal was to pass the element in the
DOM which caused the original event to the callback function. There should
be some well-defined semantics for when the Consumer script does not have
such an element ... probably passing null to the callback script.

Unless we pass such a pointer, the only
chance the portlet has to connect back to the cause of the interaction
is to have a script of its own also execute. I see no reason to require
this ....

By the way, the easy cross-browser technique
for doing this is to always pass a param named event to the eventHandler.
In IE this will reference the global event object and in FF it will reference
the dynamic one. I haven't tested it, but would guess it would work in
other browsers as well. I think the only time IE's global event object
doesn't have a value is when a script is called asynchronously (e.g. XHR
or from a timer). In FF, I think it only has a value when it is explicitly
passed from the initial event handler. The difference is not something
the Consumer can help, but that just raises the need to define what will
be passed if the Consumer script does know what element sourced the event.

Another interesting thought about useful
things to supply the callback function ... wouldn't a pointer to the Portlet's
subtree within the DOM be useful? This would remove a requirement for a
namspaced id attribute ...

Rich

Subbu Allamaraju <subbu@bea.com>

05/09/06 02:39 PM

To	wsrp@lists.oasis-open.org
cc
Subject	[wsrp] Ajax - event source

At the F2F, it was suggested that the callback function
receive the 
source of the event so that the callback would know what caused the
submission.

In IE, "event" is a global object, and the consumer function
can get 
event.srcElement and pass it to the callback.

But, in Firefox/mozilla browsers, event is not global, and to get the 
event, event handler function must explicitly have the event argument,
from which it can extract event.target.

To make this work across browsers, the consumer supplied function will
have to include an event arg which may or may not make sense depending
on where the URL is used. For instance, what is the event source when a
URL is used in an inline script? The document itself?

Two questions:

1. Do you see any implementation issues if we require that the consumer
to (optionally?) pass on the event source to the callback?

2. Is there a need for the event source? Since the portlet knows the 
context in which the URL is being used, it can get the source from the
document.

Thanks for any comments.

Subbu

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries
 and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted
 and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php