Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Web Tools Project (WTP) » INodeNotifier behavior on SSE editor
INodeNotifier behavior on SSE editor [message #206851] Tue, 15 January 2008 20:54 Go to next message
fchen is currently offline fchen
Messages: 22
Registered: July 2009
Junior Member
In one of my projects I need to listen to the changes on SSE source
editor. After some digging I found the interfaces I need: INodeNotifier
and INodeAdapter. I am now able to listen to most of the changes made to
the source. However I did find updating the name of an attribute wouldn't
trigger anything on my INodeAdapter. Why is this the case? Are there any
other modifications that won't go through this notification mechanism? And
what can I do in this case? Thanks in advance for your help.
Re: INodeNotifier behavior on SSE editor [message #206867 is a reply to message #206851] Wed, 16 January 2008 15:13 Go to previous messageGo to next message
Nitin Dahyabhai is currently offline Nitin Dahyabhai
Messages: 2237
Registered: July 2009
Senior Member
Feng wrote:
> In one of my projects I need to listen to the changes on SSE source
> editor. After some digging I found the interfaces I need: INodeNotifier
> and INodeAdapter. I am now able to listen to most of the changes made
> to the source. However I did find updating the name of an attribute
> wouldn't trigger anything on my INodeAdapter. Why is this the case? Are
> there any other modifications that won't go through this notification
> mechanism? And what can I do in this case? Thanks in advance for your help.

Are you certain that there's no notification at all to your adapter
on that Node? Perhaps it's just with different values than you
expected.

---
Nitin Dahyabhai
Eclipse WTP Source Editing
IBM Rational


---
Nitin Dahyabhai
Eclipse WTP, IBM
Re: INodeNotifier behavior on SSE editor [message #206889 is a reply to message #206867] Wed, 16 January 2008 16:53 Go to previous messageGo to next message
fchen is currently offline fchen
Messages: 22
Registered: July 2009
Junior Member
I stepped through quite a few scenarios in debug mode and this was what I
found. For example if I want to add a (class="heading") attribute to a
tag. When I type 'c', there is a notification of type CHANGE on the
element that corresponds to the tag, the changedFeature of the event is
the newly created AttrImpl. This is kind of strange since one would expect
an ADD notification in this case. Then I continue to type 'l', there is no
notification events on any nodes. I looked at the source afterwards, it
seemed like it was calling AttrImpl.setName() instead of notifyXXX(). If I
went on and removed the attribute, it triggered a CHANGE notification
instead of a REMOVE as well.

Is there a particular reason why attribute modifications don't follow the
normal notification pattern? What can I do in this case? Thanks.
Re: INodeNotifier behavior on SSE editor [message #207261 is a reply to message #206889] Sun, 20 January 2008 03:34 Go to previous messageGo to next message
David Williams is currently offline David Williams
Messages: 696
Registered: July 2009
Senior Member
On Wed, 16 Jan 2008 16:53:47 -0500, Feng <fchen8@gmail.com> wrote:

>
> Is there a particular reason why attribute modifications don't follow the normal notification pattern? What can I do in this case? Thanks.
>

I'd have to dig around a lot to really recall and re-understand, but in general, we may just have never found a need to.
These adapters are primarily used to keep two models in synch and most the models, I'd guess, didn't care too much about attributes.
And, part of the reason for that is that the attribute values are "always in synch". That is, anytime a model needed it, it would simply get the value.

Are you too using it to keep another model up to date with the DOM ... or, something else?

I think some clients that needed real fine level notificaiton also listen to IDocument events.

There were some parts of the INode Notification that was also determined by performance needs ... again, I don't recall for sure, but I think Text Nodes acts a little differently for this reason.

It'd be interesting to hear what you're using it for.
Re: INodeNotifier behavior on SSE editor [message #207263 is a reply to message #207261] Sun, 20 January 2008 16:36 Go to previous messageGo to next message
Eclipse User
Originally posted by: dcarver.starstandard.org

David Williams wrote:
> I'd have to dig around a lot to really recall and re-understand, but in general, we may just have never found a need to.
> These adapters are primarily used to keep two models in synch and most the models, I'd guess, didn't care too much about attributes.
> And, part of the reason for that is that the attribute values are "always in synch". That is, anytime a model needed it, it would simply get the value.
>
> Are you too using it to keep another model up to date with the DOM ... or, something else?
>
> I think some clients that needed real fine level notificaiton also listen to IDocument events.
>
> There were some parts of the INode Notification that was also determined by performance needs ... again, I don't recall for sure, but I think Text Nodes acts a little differently for this reason.
>

Some of this might explain why when an attribute node is deleted through
a DOM call, it doesn't appear that the underlying model is updated
correctly right away. The W3C DOM Level 1 confornmance tests have lots
of problems with the way the attributes are implemented by the DOM that
overlays the SSE model.

Dave
Re: INodeNotifier behavior on SSE editor [message #207849 is a reply to message #207261] Thu, 31 January 2008 23:16 Go to previous messageGo to next message
fchen is currently offline fchen
Messages: 22
Registered: July 2009
Junior Member
Thanks for the explanation. I finally got through the things I need to do.
SSE DOM behaves in a way that is quite different from DOM from other app
such as a browser. It might has a lot to do with its text editing origin.
Though it might deviate from W3C DOM, I found it behave in its own
consistent way, which is most important for my purpose. You are right that
I use the DOM to sync two models, just the other model happens to be a
browser.

Regarding the performance concern, I see what you were saying. SSE use
XMLModelNotifierImpl to consolidate the events into a coarse form for
better performance. The events before XMLModelNotifierImpl, IMHO, were
actually of good granular level. I end up reconstruct some of the events
out of the coarse form.

Any idea will SSE go to W3C DOM level 3?
Re: INodeNotifier behavior on SSE editor [message #207919 is a reply to message #207849] Sat, 02 February 2008 11:23 Go to previous message
Eclipse User
Originally posted by: dcarver.starstandard.org

Feng wrote:
> Thanks for the explanation. I finally got through the things I need to
> do. SSE DOM behaves in a way that is quite different from DOM from other
> app such as a browser. It might has a lot to do with its text editing
> origin. Though it might deviate from W3C DOM, I found it behave in its
> own consistent way, which is most important for my purpose. You are
> right that I use the DOM to sync two models, just the other model
> happens to be a browser.

> Any idea will SSE go to W3C DOM level 3?

You might be interested in following this bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=214439

It has to do with trying to get the SSE DOM so that it passes as many of
the W3C DOM Level 1 conformance tests as possible. Unfortunately, I
have not be able to find any conformance tests for DOM Level 2 and Level
3. It seems that only DOM Level 1 tests were ever completed.

My personal goal would be to have the SSE DOM fully conformant, but this
is going to take a lot of work and verification to find out what it will
break with the existing implementation.

Dave
Previous Topic:Tutorials "Creating a top-down Axis2 Web service" and "Creating a bottom-up Axis2 Web
Next Topic:Best strategy to have jars deploy into WEB-INF/lib?
Goto Forum:
  


Current Time: Wed Jul 30 09:16:10 EDT 2014

Powered by FUDForum. Page generated in 0.01643 seconds