RE: [Widex] Proposed rewording for Framework draft

> It seems that Jin isn't keen on the use of the term "programming
> level" in section 3.1, so how about replacing:
> 
>   DOM model describes mainly two ways to associate an event
>   listener to a node in the tree:
> 
>   1.  at the programming level, using the EventTarget interface as
>       specified by DOM3.Events [W3C.WD-DOM-Level-3-Events-20060413]
>       or a method specific to the UI markup language.
>   2.  at the document level, using XML Events
>       [W3C.REC-xml-events-20031014] or an ad-hoc syntax, as the
>       ones provided by the UI markup language itself, e.g.  XHTML
>       [W3C.REC-xhtml1-20020801] or SVG 1.1 [W3C.REC-SVG11-20030114].
> 
> By
> 
>   The DOM describes two ways to associate an event
>   listener to a node in the tree:
> 
>   1.  Using the DOM EventTarget interface as specified by
>       DOM3.Events [W3C.WD-DOM-Level-3-Events-20060413] or a
>       method specific to the UI markup language.
>   2.  Using markup, either with XML Events
>       [W3C.REC-xml-events-20031014] or a language specific
>       syntax, e.g.  XHTML [W3C.REC-xhtml1-20020801] or SVG 1.1
>       [W3C.REC-SVG11-20030114].
> 
> And replacing:
> 
>   Following the DOM model, associating event listeners to a node
>   in the tree at document level is done using WO.Update messages
>   as described in Section 4.1, while at the programming level is
>   done using WO.Selector messages as described in Section 4.3.
> 
> By
> 
>   The Widex Framework enables event listeners to be attached
>   to DOM nodes using either WO.Update messages as described in
>   Section 4.1, or through WO.Selector messages as described in
>   Section 4.3.
> 
> Which avoids the use of "programming" vs "document level".

Just want to clarify - later on you proposed to remove this paragraph (#1 and
#2), so the above replacement wouldn't be used anyway?

> However, this leaves open the issue of how to distinguish
> local and remote event listeners. The DOM EventTarget interface
> only deals with local event handlers. XML Events allows you
> to specify handlers via URIs but the assumption seems to be
> that these are scripts that are downloaded and executed locally
> by the markup language interpreter.

Yes, DOM EventTarget was not designed with remote events in mind. So that's why
in one of my previous mails I was saying it would be useful for us only in the
case when it operates on the server-side virtual DOM and then the calls in turn
get serialized into WO.Selector messages.

As for XML Events, you are right. I think implicitly the resource pointed to by
the handler attribute is to be downloaded and executed in the renderer side.
Perhaps, we can suggest some new wording or syntax for the handler attribute?
Actually, all we need is a magic value *remote*, so the renderer knows to send
the event to the server rather than handle it locally. 

> It seems to me that WO.Update messages can only be used to add local
> event listeners, unless there is specific provision for remote event
> listeners in the markup language itself. Remote event listeners can
> be added by WO.Selector messages, or as part of session
> establishment, or by prior arrangement.

I think it's good to clearly distinguish local and remote event listeners.
However, technically speaking, WO.Update messages could be used to update remote
event listeners if the UI language has the explicit support for the notion of
remote events. Similarly, there is no reason why WO.Selector can't be used to
update local listeners.

On the other hand, currently there is no UI language having explicit support for
remote event listeners. So I'm ok with saying that WO.Update messages are to be
used for managing local listeners only. But some explanation is needed to inform
our readers of the rationales behind this design.

We may also want to say something about the behavior of multiple event listeners
(a mix of local and remote listeners) for the same event. For example, in XUP,
if a local listener can fully handle an event locally, it can prevent a remote
listener from being called.

> I suggest we add something about how the MVC pattern allows
> server-side operations on the DOM to be reflected to the
> Widex Renderer as a way of helping to address the concerns
> over the terminology of DOM Mutation events.
> 
> How about:
> 
>   With the Model-View-Controller design pattern, updates to
>   the (virtual) DOM tree held by the Widex Server are reflected
>   as WO.Update messages that in turn result in the Widex
>   Renderer updating its copy of the DOM tree to match the
>   changes made by the Widex Server. A similar process occurs
>   when the Widex Server adds or removes event listeners,
>   where these changes are mediated by WO.Selector messages.

Yes, I think this is a good explanatory text.

>   In a little more detail, changes made by the Widex Server
>   to the XML DOM for the View, result in DOM events, e.g.
>   DOM Mutation events. The Widex Framework in the server
>   (as shown in Figure 1) can listen for these events to
>   generate the corresponding Widex messages. The Widex
>   Framework in the Renderer interprets these messages to
>   reflect the changes to its copy of the XML DOM for the
>   View. Note that the Widex messages are independent of
>   whether the Widex Server has an explicit or a virtual
>   View.

I think this is more like an implementation suggestion (i.e. using DOM mutation
events on the server side). There are other implementation techniques for the
server to trace and serialize the UI updates. For example, in the OpenXUP
server, we don't use DOM events at all for performance reasons. The server has a
UI tracker, which tracks every API calls to the UI tree; and at the end of the
request processing, the content of the UI tracker is serialized into UI updates
and sent to the client.

> We can take up the terminological issue of events versus
> actions in the REX specification. I don't think we need
> to cover that in Widex where we seem have consensus on
> the three kinds of messages (Update, Event, and Selector).

Yes, Widex's terminology is fine. My problems are with REX ...

Regards,

Jin
________________________________________
Jin Yu
OpenXUP.org

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex