|
| Re: INodeNotifier behavior on SSE editor [message #206867 is a reply to message #206851] |
Wed, 16 January 2008 20:13   |
|
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 Web Tools Platform
|
|
|
|
| Re: INodeNotifier behavior on SSE editor [message #207261 is a reply to message #206889] |
Sun, 20 January 2008 08:34 |
 David Williams
Messages: 722
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 21:36 |
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 #207919 is a reply to message #207849] |
Sat, 02 February 2008 16:23 |
| 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
|
|
|
Powered by
FUDForum. Page generated in 0.03610 seconds
] 
Search
Help
Register
Login
Home
