Re: [wsrp] Ajax - event source

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

I think the semantics of the event source
and the root node for the Portlet's markup are sufficiently different that
I wouldn't intermix them. What would be the advantage of passing one or
the other rather than always passing both?

Rich

Subbu Allamaraju <subbu@bea.com>

05/10/06 01:30 AM

To	Rich Thompson/Watson/IBM@IBMUS
cc	wsrp@lists.oasis-open.org
Subject	Re: [wsrp] Ajax - event source

Rich Thompson wrote:
> 
> 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

Yes. I think we are referring to the same thing.

> semantics for when the Consumer script does not have such an element
... 
> probably passing null to the callback script.

Seems reasonable to pass a null when there is no context. More below.

> 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 ....

I agree.

> 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 

Yes. That's what I was referring to below. I have not traced the path,
but Opera seems happy as well.

> 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.

True.

> 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
...

How about supplying the portlet's DOM tree when there is no event 
context available? Seems better than passing a null.

Subbu

> 
> 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
> 
> 
> ---------------------------------------------------------------------
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

_______________________________________________________________________
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