Eclipse Community Forums: ServerTools (WTP)

Home » Language IDEs » ServerTools (WTP) » XmlModel

Wed, 12 January 2005 19:36

Eclipse User

Originally posted by: not_real.not_real.com

I've started to take advantage of the XML model in M2 to manipulate XML
documents from within a design view. Currently I have a multipage
editor with a StructuredTextEditorXML in one of the pages. Eventually I
would like to get rid of the source editor tab yet I am still interested
in using the WebTools XML model because I am interested in the source
location (IndexedRegion) information it provides. I would like to know
two things:

1. How likely are XmlModel and related classes to change? I am hoping
not to have to rewrite a bunch of stuff when future WebTools milestones
are released.

2. Is it feasible to use the underlying XML model without actually
instantiating a structured text editor? Does anyone see problems with
this approach?

Thanks!

Re: XmlModel [message #65187 is a reply to message #65119]

Thu, 13 January 2005 00:05

Eclipse User

ka wrote:

> I've started to take advantage of the XML model in M2 to manipulate XML
> documents from within a design view. Currently I have a multipage
> editor with a StructuredTextEditorXML in one of the pages. Eventually I
> would like to get rid of the source editor tab yet I am still interested
> in using the WebTools XML model because I am interested in the source
> location (IndexedRegion) information it provides. I would like to know
> two things:

> 1. How likely are XmlModel and related classes to change? I am hoping
> not to have to rewrite a bunch of stuff when future WebTools milestones
> are released.

> 2. Is it feasible to use the underlying XML model without actually
> instantiating a structured text editor? Does anyone see problems with
> this approach?

> Thanks!

Hi,

1. I'd recommend programming to the standard DOM API where possible
(org.w3c.dom) since these are very stable API's. You'll likely only need
to duck down into the implementation specifics occasionally in order to
access things like source locations. And BTW ... things are likely to
change as we work out the API's in the coming months.

2. Yes, it's easy enough. See the class StructuredModelManager and
IModelManager for details (in the sse.core plugin).

I hope that helps. Thanks for your interest!

Re: XmlModel [message #65459 is a reply to message #65187]

Thu, 13 January 2005 14:39

Eclipse User

Originally posted by: not_real.not_real.com

Craig Salter wrote:

Thanks for your response. So for #1 I believe what you're saying is
that using the XMLModel is fine, but that I should stick to depending on
only the DOM interfaces that it implements rather than depending on some
if its concrete classes. This should support most of my needs, but I am
interested in using the IndexedRegion interface as well as it provides
source location information...

>
>
> Hi,
>
> 1. I'd recommend programming to the standard DOM API where possible
> (org.w3c.dom) since these are very stable API's. You'll likely only
> need to duck down into the implementation specifics occasionally in
> order to access things like source locations. And BTW ... things are
> likely to change as we work out the API's in the coming months.
>
> 2. Yes, it's easy enough. See the class StructuredModelManager and
> IModelManager for details (in the sse.core plugin).
>
> I hope that helps. Thanks for your interest!
>

Re: XmlModel [message #65521 is a reply to message #65459]

Thu, 13 January 2005 20:12

Eclipse User

ka wrote:

> Craig Salter wrote:

> Thanks for your response. So for #1 I believe what you're saying is
> that using the XMLModel is fine, but that I should stick to depending on
> only the DOM interfaces that it implements rather than depending on some
> if its concrete classes. This should support most of my needs, but I am
> interested in using the IndexedRegion interface as well as it provides
> source location information...

Right, I think you'll need to use some amount of 'sse/xml model' specific
code (e.g. IndexedRegion, StructuredModelManager) ... but you can mitigate
the risks of API changes by sticking to the standard DOM interfaces where
possible. BTW... I'd encourage you to post back and let us know what
'see/xml model' specific code you end up depending on. It'll help us
understand what we need to expose as API.

Re: XmlModel [message #69408 is a reply to message #65521]

Thu, 27 January 2005 22:34

Eclipse User

Originally posted by: not_real.not_real.com

Craig Salter wrote:
> ka wrote:
>
>> Craig Salter wrote:
>
>
>> Thanks for your response. So for #1 I believe what you're saying is
>> that using the XMLModel is fine, but that I should stick to depending
>> on only the DOM interfaces that it implements rather than depending on
>> some if its concrete classes. This should support most of my needs,
>> but I am interested in using the IndexedRegion interface as well as it
>> provides source location information...
>
>
> Right, I think you'll need to use some amount of 'sse/xml model'
> specific code (e.g. IndexedRegion, StructuredModelManager) ... but you
> can mitigate the risks of API changes by sticking to the standard DOM
> interfaces where possible. BTW... I'd encourage you to post back and
> let us know what 'see/xml model' specific code you end up depending on.
> It'll help us understand what we need to expose as API.
>
Here's the stuff I can think of off of the top of my head; there may be
more:
-IndexedRegion (both node->offset and offset->node)
-undo/redo functionality
-compound edits (begin/end recording)
-StructuredModelManager/IModelManager

Re: XmlModel [message #70608 is a reply to message #69408]

Mon, 31 January 2005 13:25

Eclipse User

> Here's the stuff I can think of off of the top of my head; there may be
> more:
> -IndexedRegion (both node->offset and offset->node)
> -undo/redo functionality
> -compound edits (begin/end recording)
> -StructuredModelManager/IModelManager
>

In principle these are all destined to become APIs ... but some of them will be modified as per exact arguments, exceptions thrown, etc. If you are closely relying on our interim releases, you might want to subscribe to wtp-dev ... we'll announce major changes there, after releasing to head, shortly before building them. At each milestone, we'll have some breif "api migration notes" as part of the release notes. We hope to make the "platform quality" effort as painless as possible, so don't hesitate to let us know if there's process errors we make (we can do almost anything, except leave a poor method signiture as API :)

Thanks,

Previous Topic:	Eclipse Web Tools Mentor
Next Topic:	Weekly PMC conference call notes

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Mar 12 16:28:20 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter