This appears to directly defeat a variety of optimizations:
client-side, it defeats the use of innerHTML, server-side it defeats
DOM diff short circuits.

If the number of listeners is "small", then for each listener we
could store the DOM node before the update and check its DOM status
(walk up to root) after the update is applied. If it is not in the DOM, the listener would be called. (The question is whether this works on IE; if there are difficulties, perhaps checking the root node for identity against the current root node would work.)

Essentially we're trying to do this:

https://developer.mozilla.org/en-US/docs/DOM/Mutation_events

1.5x - 7x slowdown in DOM operations

A server-side implementation of this would require substantial interaction with the "old" DOM, which is likely to be inefficient (this requirement was not realized when the server-side technique was originally proposed).

The main point is that this listener technique should be avoided as much as possible.

The worst case for the server-side implementation is likely the cost of serializing the old DOM, so approximately 10% CPU overhead. This would be acceptable for some applications and would make client-side performance more deterministic in some cases.
Note, however, that if a large number of components make use of onElementUpdate, even if the callbacks are determined server-side, iteration through these callbacks will remain a serious performance issue on some browsers.

I am currently looking at two algorithm variants, either using attributes in old DOM or by using an auxiliary data structure and will add details shortly.

A few weeks ago, Ted and I discussed a means of components writing a note into the server DOM where they register their client-side onElementUpdate callbacks. Each note would cause a count to increment for the ancestor elements. When a DOM update or delete is detected, then the server could recurse down into the update, collecting the element ids within it that are noted, and earlying out of the recursion when the counts drop to zero. The collected ids would be sent to the browser, where there would be a Map<id -> callback array>. If context param was set disabling the server acceleration feature, or the list was too long, then the server could send no list, and the browser would proceed with it's own existing detection mechanism.

The following strategy would be straightforward to implement:

• when a component requires onElementUpdate notification, data-onElementUpdate="true" is written to the root node of the component.
• keep the old DOM for the duration of the duration of the current request (currently it is discarded once the diff is calculated)
• for each update ajax edit operation, scan the old DOM for data-onElementUpdate and collect the IDs

On the client we have two options. Use data-onElementUpdate="callback" where callback(id, context) would be invoked. This is the most memory efficient. Alternatively, maintain an id/callback table on the client where onElementUpdate IDs in the list invoke the stored callback. The storage of these callbacks is potentially large (due to DOM references) and has the potential to leak, so the declarative callback would be preferred.

Assuming we are going to use the marking of component root elements with data-onElementUpdate we still might run into performance problems:

Lets say we have the following DOM update:

.
      e1
    / | \
   e2 e3 e4 <-- component root
         /\
        e5 e6
        |   |
        e7  e8
            /\
           e9 e10

It seems there are two kind of searches that need to be executed in order to collect the IDs of the elements that are updated:

a) If the entire markup of a component is included by the update a search needs to be made from the e1 down, e4 would be found as the marked root of a component. We then need to collect the IDs of all its children and send them to the bridge. On the bridge the IDs will be used to lookup the corresponding onElementUpdate callbacks (if there are any), and then execute them.

b) If the update is just for the component subtree, lets say e6 then we need to check if e6 has a parent marked with data-onElementUpdate. If it does then once again collect the IDs of e6 children and send them to the bridge.

As Ted mentioned the searches will need the old DOM document to find the IDs of the children elements of the root element in the update.

We have cases when the old DOM does not exist but we still prepare a partial update. It is not clear how we would handle this, simply sending all the IDs in the update is expensive and still might mis certain elements since the previous DOM held by the browser could be different.

The type of searches mentioned above will generate additional updates (the ones containing the IDs) proportional with the size of the update (bigger natural updates, more IDs sent).

Avoiding the searches by using the data-onElementUpdate markers only for the elements that have a corresponding callback will put a lot of burden on the component developer to remember which element needs to be marked.

The complexity for the update of e6 arises because the onElementUpdate callback is expected for the update of e4 or any child of e4. Can the components be implemented so that they do not require the onElementUpdate if their child is modified, only if their root node is modified? Also, can the components be implemented so that they can perform appropriate cleanup given only the onElementUpdate callback with the ID of the component?

"Also, can the components be implemented so that they can perform appropriate cleanup given only the onElementUpdate callback with the ID of the component?"

Well, in the component that use onElementUpdate callbacks I already see that they are used to a finer detail. Constraining how the callbacks to cover more coarse detail might very cause decrease performance.

Anyway, this is a question for the component team...

Components might register their onElementUpdate on their root, or on their script's wrapper span, so don't make assumptions that it will be on the root element.

When components register their onElementUpdate for an element id, they could place an object that has a destroy() function inside the element's data-destroy attribute. These same components would render with the data-onElementUpdate marker in the server DOM. This way the framework could transmit the list of element ids that were updated which had data-onElementUpdate markers set, and the bridge could simply do the getElementById, find the data-destroy attribute's object and call destroy() on it, with no need for looking through lists. These components should probably pass some parameter into their onElementUpdate registration, so that they'd only be added to the lists when the server side acceleration is not available.

Naming this attribute data-component where the object has a destroy() method would allow a component state object for other purposes as well.

Depending on the time available to re-write components, data-destroy might contain the component object itself, or it might just be a separate enclosure object, and so be different than what we store for our widgetVar replacement.

Implemented server-side determination of the updated elements that potentially can have onElementUpdate callbacks registered on the client side. The method used is already described above, the only difference is that if the search through the parents succeeds in finding a marked element then the DSF starting from the updated element is no longer necessary.

The components that are known to use onElementUpdate callbacks need now to mark the root of the generated markup by using ComponentUtils.enableOnElementUpdateNotify method.

The following components were modified so that their renderers mark the root element as being eligible (with all its children) for element update notifications: ace:checkboxButton, ace:linkButton, ace:dateTimeEntry, ace:dataTable, ace:submitMonitor, ace:themeSelect, ace:pushButton, ace:tableConfigPanel, ace:tree.

Here's is the algorithm used for collecting the IDs belonging to the elements that are updated:

When an replace or remove update is detected the ID element of the update is used to lookup the original element into the old DOM. From this element a search is started down through its ancestors.

If one of these ancestors is marked with data-elementupdate attribute then Element.getElementByTagName("*") is executed on the start element to eventually filter and collect the IDs of all children (regardless of depth).

If the first type of search reaches the document root then it is assumed that the update includes the whole generated markup of one or more components. From the start element then a depth-first-search is executed until one or more children are found as being marked with data-elementupdate attribute. If marked elements are found their ID and the IDs of their children are collected to be sent to the bridge.

This sounds like a component is notified if the DOM is modified for any of the component's children. Isn't it sufficient to notify a component just when its root node is modified?

Components need only be notified when their registered element or an ancestor of it is updated/removed, not when a child is.

Re-opening the JIRA just to be clear on the ancestor/child aspect of notification.

Mark, I don't understand your last comment. The components are not notified, the elements renderer by a certain component might have their onElementUpdate callbacks invoked.

Ted, what exactly is not clear in ancestor/child aspect? I did explain in here in my previous comment plus you can always look for more details into the code.

Test for the existence of the looked up element before trying to assign its corresponding onElementUpdate callback. If not found a warning is logged.

Modified server-side algorithm of finding elements marked as requiring onElementUpdate notification. Now the search starts from the updated elements and sends only the IDs of the marked child elements. Introduced org.icefaces.clientSideElementUpdateDetermination context parameter that can be used to switch the implementation of finding the elements with onElementUpdate callbacks to client or server side.

org.icefaces.clientSideElementUpdateDetermination is set to false by default.

ACE SubmitMonitor now supported.

icefaces3 trunk
Subversion 34997

ICE PanelTabSet now supported.

icefaces3 trunk
Subversion 34998