Home » Language IDEs » ServerTools (WTP) » XMLBuddy and WST still collide
| XMLBuddy and WST still collide [message #111503] |
Wed, 15 June 2005 23:01  |
Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
Just a note. As of Wednesday's integration build, the WST XML editor
still collides with XMLBuddy Pro.
It's the nature of the 3.0 Text feature/bug that one editor works and
the rest don't. In this case, I installed WST first, tried it, exited,
installed XMLBuddy Pro and restarted. XMLBuddy Pro works fine but the
WST XML Editor (called "XML Editor" - why didn't I think of that?) only
works as a basic text editor. Syntax coloring doesn't work in the source
view and the tree view doesn't work at all.
Bob Foster
http://xmlbuddy.com/
|
|
| |
| Re: XMLBuddy and WST still collide [message #111529 is a reply to message #111517] |
Thu, 16 June 2005 03:28  |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
Sure. When I do that and your "XML Editor" is open I see:
Partitions: __dflt_partitioning
Partitioner:com.objfac.xmleditor.partition.XMLPartitioner@95a253
and the selection is within one of my partitions.
I've tried to explain, if two or more editors use the default
partitioner for the same content type/extension, only one of them wins.
It's just as likely to be XMLBuddy losing as you; it depends on install
order and other randomness. The only way to fix it is for all but one to
_not_ use the default partitioner (as the Ant editor realized) and
instead use the wacky 3.0 APIs.
I would do so myself except the 3.0 APIs break my editor because of
different listener order, which was _not_ easy to fix. I tried.
Check with the Ant people. They went through this in 3.0.
Please feel free to cc the Text people who made this mess in 3.0.
Bob
Nitin Dahyabhai wrote:
> Bob Foster wrote:
>
>> Just a note. As of Wednesday's integration build, the WST XML editor
>> still collides with XMLBuddy Pro.
>>
>> It's the nature of the 3.0 Text feature/bug that one editor works and
>> the rest don't. In this case, I installed WST first, tried it, exited,
>> installed XMLBuddy Pro and restarted. XMLBuddy Pro works fine but the
>> WST XML Editor (called "XML Editor" - why didn't I think of that?)
>> only works as a basic text editor. Syntax coloring doesn't work in the
>> source view and the tree view doesn't work at all.
>
>
> Bob,
> Could I get you to add
> " org.eclipse.wst.sse.ui/actioncontributor/debugstatusfields=t rue " to
> your -debug .options file and use the new status field at the bottom of
> the XML Editor (it'll have the current text selection in square
> brackets) to check the content type and partitioning? Double-clicking on
> the status field should bring up that kind of information.
>
|
|
| |
| Re: XMLBuddy and WST still collide [message #113436 is a reply to message #113410] |
Thu, 23 June 2005 17:50 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
> found we couldn't coexist with the CDT. Our document factory (3.0 API)
> only sets a default partitioner if one doesn't exist already,
And it does this why? If you're using only the 3.0 API there is never a
need to set the default partitioner, and doing so ensures that any
editor plugin that depends on 2.0 compatibility (and edits the same
extension) won't work. (Or yours won't. It's kinda random.)
Bob
Nitin Dahyabhai wrote:
> Bob Foster wrote:
>
>> Sure. When I do that and your "XML Editor" is open I see:
>>
>> Partitions: __dflt_partitioning
>> Partitioner:com.objfac.xmleditor.partition.XMLPartitioner@95a253
>>
>> and the selection is within one of my partitions.
>
>
> Were there any other partitionings available, specifically
> org.eclipse.wst.sse.core.default_structured_text_partitionin g? If not,
> are you using a custom document provider and specifying it using an
> extension point for *.xml? We're integrated with the 3.0 file buffer
> APIs at this point.
>
>> I've tried to explain, if two or more editors use the default
>> partitioner for the same content type/extension, only one of them
>> wins. It's just as likely to be XMLBuddy losing as you; it depends on
>> install order and other randomness. The only way to fix it is for all
>> but one to _not_ use the default partitioner (as the Ant editor
>> realized) and instead use the wacky 3.0 APIs.
>>
>> I would do so myself except the 3.0 APIs break my editor because of
>> different listener order, which was _not_ easy to fix. I tried.
>>
>> Check with the Ant people. They went through this in 3.0.
>
>
> I followed along with the Ant debacle and fixed the same problem when we
> found we couldn't coexist with the CDT. Our document factory (3.0 API)
> only sets a default partitioner if one doesn't exist already, and all of
> our UI code is set to use a private partitioning value other than the
> platform's default. My guess is that somehow our partitioner isn't even
> in there, and that the document type may not be of the instance we need.
>
|
|
|
| Re: XMLBuddy and WST still collide [message #113488 is a reply to message #113436] |
Thu, 23 June 2005 23:20 |
| Eclipse User |
|
|
|
Bob Foster wrote:
> > found we couldn't coexist with the CDT. Our document factory (3.0 API)
> > only sets a default partitioner if one doesn't exist already,
>
> And it does this why? If you're using only the 3.0 API there is never a
> need to set the default partitioner, and doing so ensures that any
> editor plugin that depends on 2.0 compatibility (and edits the same
> extension) won't work. (Or yours won't. It's kinda random.)
Just to be clear, when we're referring to 2.0, we're talking about
document providers in the text editors, right? The file buffers
that were introduced for 3.0 uses factories and setup participants,
and our particular problem was with the CDT setup participant always
overwriting the default partitioner. SSE editors no longer rely on
there being a default partitioner; we've moved fully into a separate
non-default partitioning that should be invisible to legacy code
that's unaware of multiple partitionings. Any functionality that
relies on partition information that isn't aware of the multiple
partitionings still requires that a (default) partitioner be
present, though, so SSE makes sure that one is provided. You make a
good point that setting one might itself cause problems, but the
prevailing assumption is that any setup participant that wants to
take the default partitioning for itself can go ahead and do that
after we've created the document, and that any participant that uses
its own private partitioning can live happily alongside the SSE
partitioning. The SSE editors shouldn't care about additional
partitionings at all.
Does XMLBuddy use a custom document provider and set the default
partitioner within it? I've seen this done to properly support
encoding elsewhere, and aside from XMLBuddy contributing a setup
participant that sets the default partitioner, it's the most likely
explanation for the debugging info you found. Was the
org.eclipse.wst.sse.core.default_structured_text_partitionin g
partitioning present?
--
- Nitin
|
|
|
| Re: XMLBuddy and WST still collide [message #113500 is a reply to message #113488] |
Fri, 24 June 2005 00:41 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
Nitin Dahyabhai wrote:
> Just to be clear, when we're referring to 2.0, we're talking about
> document providers in the text editors, right?
Right.
> The file buffers that
> were introduced for 3.0 uses factories and setup participants, and our
> particular problem was with the CDT setup participant always overwriting
> the default partitioner. SSE editors no longer rely on there being a
> default partitioner; we've moved fully into a separate non-default
> partitioning that should be invisible to legacy code that's unaware of
> multiple partitionings. Any functionality that relies on partition
> information that isn't aware of the multiple partitionings still
> requires that a (default) partitioner be present, though, so SSE makes
> sure that one is provided. You make a good point that setting one might
> itself cause problems, but the prevailing assumption is that any setup
> participant that wants to take the default partitioning for itself can
> go ahead and do that after we've created the document,
The assumption is wrong. You have no need to set the default partitioner
and doing so will only screw editors who operate according to the "2.0"
model.
> and that any
> participant that uses its own private partitioning can live happily
> alongside the SSE partitioning. The SSE editors shouldn't care about
> additional partitionings at all.
Good for SSE, but many other editors do.
> Does XMLBuddy use a custom document provider and set the default
> partitioner within it? I've seen this done to properly support encoding
> elsewhere, and aside from XMLBuddy contributing a setup participant that
> sets the default partitioner, it's the most likely explanation for the
> debugging info you found.
Yes it does. So do a raft of other third-party editors.
> Was the
> org.eclipse.wst.sse.core.default_structured_text_partitionin g
> partitioning present?
Don't know, but to play by the 3.0 rules the only way you should be
setting partitioners is through the extension point.
You might well ask why XMLBuddy doesn't play by the 3.0 rules, since
this would solve the XMLBuddy problem. ;-} The reason is partly
historical (they didn't work for most of the 3.0 beta cycle), they don't
allow editor-supplied document providers for all cases, etc. and partly
unwanted gratuitous side effects, like changing the order in which
listeners are called. It was a mess and still is.
That said, if you do what the Ant editor does (and only what it does)
you won't interfere with other editors.
Bob
|
|
|
Goto Forum:
Current Time: Tue Apr 22 16:40:34 EDT 2025
Powered by FUDForum. Page generated in 0.03670 seconds |
Home