RE: [Widex] Updated Widex framework draft

["Jin Yu" <[e-mail]>]

> It then outlines the means by which a Widex Server and Renderer
> can arrange for event listeners that forward events from the
> Widex Renderer to the Widex Server. I think we agree that at
> a high level this comes down to:
> 
>   1) by prior arrangement
>   2) a list of events passed at session establishment
>   3) dynamically during the application session

Yes, I agree.

> We agree that there are two ways for the Widex Server to dynamically
> add event listeners, one being based upon updating the markup
> through WO.Update messages and the other that uses WO.Selector
> messages to directly invoke the EventTarget interface.

Here is my understanding of how the EventTarget interface could be used to add /
remove listeners:

1. application code on the server side uses the interface to operate on the
virtual view / DOM; the server toolkit then serializes the interface calls into
WO.Selector messages.

2. the renderer receives the WO.Selector messages and then uses this interface
to manipulate the event listeners. Note that in this case it is the renderer
implementation that is using the interface.

3. application code on the render side (e.g. JavaScript) uses this interface to
manipulate the event listeners. In this case, the EventTarget interface has
nothing to do with WO.Selector messages.

So, "programming level" is not equivalent to WO.Selector messages, because:

- as I said in #3, script manipulation on the renderer side has nothing to do
with WO.Selector messages. Actually, I don't think #3 is relevant to our
discussion here; it's outside of the scope of Widex.

- using EventTarget is just one way of implementing and generating WO.Selector
messages. For example, one could have listener specifications in some
server-side template, and then the template could be loaded by the server to
output WO.Selector messages.

> Not all event listeners will forward their events to the Server,
> as markup languages may include local scripts. These could bind
> event listeners via either markup or the EventTarget interface.
> I don't think the terminology of inline and external listeners
> quite works. For instance, is an event listener bound through
> a line of script in a linked script file inline or external?
> It isn't inline in the markup, and yet it doesn't forward the
> event to the Widex Server.

Yes, you are right; external vs. inline may not be accurate in this case. I
think we agree on principals there are two ways to manage listeners, through
WO.Update messages and WO.Selector messages. I just don't feel very comfortable
with "programming level" being the defining factor, for the reasons stated
above.

Also, since you mentioned it, I'm wondering if it makes any sense to distinguish
local vs. remote event listeners? By local, I mean events are handled locally by
some scripts and not sent to the server; and for remote, the events will be sent
to the server and handled remotely. I think we are more concerned about remote
events, but of course, WO.Selector messages could include both local and remote
event listeners.

> BTW to support WO.Selector, I have proposed an extension to the DOM3
> Event specification. The idea is to define a pair of new events that
> are associated with adding or removing event listeners. If you think
> in terms of synchronizing DOM trees for the MVC View, then the
> action of adding a listener to the View results in the generation
> of a DOM AddListenerEvent that the Widex Server then forwards to the
> Widex Renderer to synchronize the Renderer's copy of the DOM tree.
> This works in just the same way as for DOM Mutation events. If
> this proposal is accepted, the REX specification would be extended
> to provide an XML serialization for the new events.

Yes, I think this will be great.

BTW, I have a terminology issue w.r.t. DOM3 Event and REX. I think the term
"event" is overloaded: mutation to the DOM is not the same as mutation event. I
regard the first as the "action" and the latter as the "event", and that action
triggers event. Therefore, DOM mutations trigger DOM mutation events. Obviously
here we are more interested in DOM mutations, not DOM mutation events.

The REX spec treats UI updates as DOM mutation events, which is somewhat
confusing. Similar concern has been raised in the public-webapi mailing list
(<http://lists.w3.org/Archives/Public/public-webapi/2006Feb/0030>).

The same applies to the event listeners, so I would call it AddListenerAction,
rather than AddListenerEvent.

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org


_______________________________________________
Widex mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/widex