Home » Language IDEs » ServerTools (WTP) » Manipulating the DOM model and keeping in sync with it
| Manipulating the DOM model and keeping in sync with it [message #136672] |
Tue, 06 September 2005 03:33  |
Eclipse User |
|
|
|
Hi guys,
I have some probelms figuring out the correct way of editing/manipulating
the
underlying DOM model and keeping in sync with it in e.g. a multi page
editor.
Is someone able to list me the basics for doing this ?
I have already tried making a AdapterFactory for INodeAdapter, but it seems
it is not the intention that I should create a MyModel speicfic
INodeAdapter
per DOMNode since IAbstractNotifier iterates over the existing adapters in
an array to find existing instances which quickly becomes very inefficient
,(
(and when I start manipulating nodes it apears the model quickly comes out
of sync if
I start being somewhat evil (moving nodes around, inserting-deleting bad
xml etc.) in the xml editor)
So, in short - what is the essiential steps to work with the provisional
API
to manipulate the DOM model of an xml editor and keep in sync with it in
e.g.
a different view/page.
With hope,
Max
|
|
|
| Re: Manipulating the DOM model and keeping in sync with it [message #136965 is a reply to message #136672] |
Wed, 07 September 2005 09:03  |
| Eclipse User |
|
|
|
Hi, Max.
I've been hacking the xml editor part of web tools these days. The approach
seems quite like what you're doing. (a multi page editor with two xml
editors in it. in fact, it's a tapestry editor based on web tools).
The way I tried to manipulatng the dom model is just directly using the
IDOMElement. They're interfaces inherating org.w3c.dom.Element, so you can
use whatever you use on w3c DOM model to read the model. on the write side,
you should cast the org.w3c.dom.Element to IDOMElement.
So, the code reads like:
StructuredTextEditorXML pageEditor;
.....
IDOMModel xmlModel = (IDOMModel) pageEditor.getModel();
IDOMDocument doc = xmlModel.getDocument();
// here we got the doc, IDOMDocument extends org.wc3.dom.Document
// so you can do anything on it as you like. My favorate way is using apache
xalan' XPath to read elements. like this:
// note: you can't use doc directly for there seems be a bug in
IDOMDocument, but you can use doc.getDocumentElement().
Element element = (Element) XPath.selectSingleNode(
doc.getDocumentElement(),
"/page-specification/component[@id='"
+ getJwcid() + "']");
//if you want to change the model. just cast it to IDOMElement
IDOMElement writableElement = IDOMElement(element);
writableElement..setAttribute("foo", "bar");
hope this helps.
cheers.
"Max Rydahl Andersen" <max.andersen@jboss.com>
??????:op.swn7aldrsj49yt@max...
> Hi guys,
>
> I have some probelms figuring out the correct way of editing/manipulating
> the
> underlying DOM model and keeping in sync with it in e.g. a multi page
> editor.
>
> Is someone able to list me the basics for doing this ?
>
> I have already tried making a AdapterFactory for INodeAdapter, but it
> seems
> it is not the intention that I should create a MyModel speicfic
> INodeAdapter
> per DOMNode since IAbstractNotifier iterates over the existing adapters in
> an array to find existing instances which quickly becomes very inefficient
> ,(
> (and when I start manipulating nodes it apears the model quickly comes out
> of sync if
> I start being somewhat evil (moving nodes around, inserting-deleting bad
> xml etc.) in the xml editor)
>
> So, in short - what is the essiential steps to work with the provisional
> API
> to manipulate the DOM model of an xml editor and keep in sync with it in
> e.g.
> a different view/page.
>
> With hope,
> Max
|
|
|
| Re: Manipulating the DOM model and keeping in sync with it [message #137047 is a reply to message #136965] |
Wed, 07 September 2005 11:47 |
| Eclipse User |
|
|
|
Hi Zhangwei,
Thanks for the tips - after some more messing around I found "a way" to do
things.
I don't know if it is "the way", but it works for me ;)
To sum it up:
1. Use the DOM interface to perform manipulations as you describe.
2. To keep the pages in sync you can use both of the following tactics:
a. Register a ModelStateListener via
document.getModel().addModelStateListener() and get global notifications
b. Create a subclass of AbstractAdapterFactory that creates
INodeAdapter for the nodes you want to monitor. These nodeadapters
can be instances of your model objects and thus keep a 1-1 link
between an adapter and a model OR (as I prefer) be mediators which
sends appropriate events to your model to have the right level of
notificaitons (no to global and not to fine grained)
someone should write an WTP validated example of this ;)
/max
> Hi, Max.
> I've been hacking the xml editor part of web tools these days. The
> approach
> seems quite like what you're doing. (a multi page editor with two xml
> editors in it. in fact, it's a tapestry editor based on web tools).
> The way I tried to manipulatng the dom model is just directly using the
> IDOMElement. They're interfaces inherating org.w3c.dom.Element, so you
> can
> use whatever you use on w3c DOM model to read the model. on the write
> side,
> you should cast the org.w3c.dom.Element to IDOMElement.
> So, the code reads like:
>
> StructuredTextEditorXML pageEditor;
> ....
> IDOMModel xmlModel = (IDOMModel) pageEditor.getModel();
> IDOMDocument doc = xmlModel.getDocument();
> // here we got the doc, IDOMDocument extends org.wc3.dom.Document
> // so you can do anything on it as you like. My favorate way is using
> apache
> xalan' XPath to read elements. like this:
> // note: you can't use doc directly for there seems be a bug in
> IDOMDocument, but you can use doc.getDocumentElement().
> Element element = (Element) XPath.selectSingleNode(
> doc.getDocumentElement(),
> "/page-specification/component[@id='"
> + getJwcid() + "']");
> //if you want to change the model. just cast it to IDOMElement
> IDOMElement writableElement = IDOMElement(element);
> writableElement..setAttribute("foo", "bar");
>
> hope this helps.
> cheers.
>
> "Max Rydahl Andersen" <max.andersen@jboss.com>
> ??????:op.swn7aldrsj49yt@max...
>> Hi guys,
>>
>> I have some probelms figuring out the correct way of
>> editing/manipulating
>> the
>> underlying DOM model and keeping in sync with it in e.g. a multi page
>> editor.
>>
>> Is someone able to list me the basics for doing this ?
>>
>> I have already tried making a AdapterFactory for INodeAdapter, but it
>> seems
>> it is not the intention that I should create a MyModel speicfic
>> INodeAdapter
>> per DOMNode since IAbstractNotifier iterates over the existing adapters
>> in
>> an array to find existing instances which quickly becomes very
>> inefficient
>> ,(
>> (and when I start manipulating nodes it apears the model quickly comes
>> out
>> of sync if
>> I start being somewhat evil (moving nodes around, inserting-deleting bad
>> xml etc.) in the xml editor)
>>
>> So, in short - what is the essiential steps to work with the provisional
>> API
>> to manipulate the DOM model of an xml editor and keep in sync with it in
>> e.g.
>> a different view/page.
>>
>> With hope,
>> Max
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: Manipulating the DOM model and keeping in sync with it [message #137123 is a reply to message #137047] |
Wed, 07 September 2005 17:14 |
| Eclipse User |
|
|
|
On Wed, 07 Sep 2005 11:47:05 -0400, Max Rydahl Andersen <max.andersen@jb=
oss.com> wrote:
> someone should write an WTP validated example of this
Thanks for volunteering :)
I can confirm your basic approach is correct. We will be looking to clea=
nup some of this
code and provide better documentation and examples. And ... of course, y=
ou experiences
and feedback is greatly appreciated. [I doubt we'll change 'adapter' to =
'mediator',
though. But you are correct, its often used as a mediator].
The things I "hear" in the series of notes that will change (er, be impr=
oved)
at some point (some before 1.0, some after) ... the "getModel" from edit=
or
won't be API ... but we'll document how to get it.
The "modelState" listener will likely change, but will have similar repl=
acement
concept.
One thing to caution, the 'child deleted' adapter noticiation does not a=
lways work
as expected ... sometimes some parts of the DOM tree "disappear" before =
we know to
notifiy everyone ... that will take some deep work to improve, but just =
thought
I'd "warn" you in case you see funny stuff with 'delete'.
Hope this helps confirm the direction.
|
|
|
| Re: Manipulating the DOM model and keeping in sync with it [message #137235 is a reply to message #137123] |
Thu, 08 September 2005 03:07 |
| Eclipse User |
|
|
|
>> someone should write an WTP validated example of this
>
>
> Thanks for volunteering :)
:) (when there is a more stable api, then maybe ;)
> I can confirm your basic approach is correct. We will be looking to
> cleanup some of this
> code and provide better documentation and examples. And ... of course,
> you experiences
> and feedback is greatly appreciated. [I doubt we'll change 'adapter' to
> 'mediator',
> though. But you are correct, its often used as a mediator].
I actually haven't found any example where it is not a mediator unless
it is on a model that has an exact 1-1 relationship and even there I
find it hard to have something clean to keep the model in sync (since node
instances can be replaced even though the node tags are simply moved)
> The things I "hear" in the series of notes that will change (er, be
> improved)
> at some point (some before 1.0, some after) ... the "getModel" from
> editor
> won't be API ... but we'll document how to get it.
Yes, i'm not using that because of the deprecation - im using
editor.getAdapter(Document.class) instead,
which gives me an IDOM that I can call getModel() on, don't know if that
is better ,)
> The "modelState" listener will likely change, but will have similar
> replacement
> concept.
I actually only use it know to debug and see if I missed an
"adaption/mediation"
> One thing to caution, the 'child deleted' adapter noticiation does not
> always work
> as expected ... sometimes some parts of the DOM tree "disappear" before
> we know to
> notifiy everyone ... that will take some deep work to improve, but just
> thought
> I'd "warn" you in case you see funny stuff with 'delete'.
hehe - because of this and the fact that attribute changes also doesnt
seem to propagate
the old value i'm doing coarse grained updates to be more in sync.
One thing I miss though is some API for handling "massupdates" so you can
tell the notify mechanism
to only notify me when it is all done and then just report
"structure/contents changed" on the common
ancestor (and possibly have a list of intermediate notifcations as an
argument to the notifyChange...just a thought)
The "massupdate" is mostly used to mimic "reconcilidation" which the SSE
docs seem to say users can just
implement them selves and thus SSE always fire an event....that is true,
but would be less errorprone if there were
a mechanism in SSE to do that.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
Goto Forum:
Current Time: Sun Jul 27 06:25:50 EDT 2025
Powered by FUDForum. Page generated in 0.03929 seconds |
Home