||Sat, 03 July 2010 11:31
| Steffen Heil
Registered: July 2009
On their own, they all work fine.
Is this possible? how?
||Thu, 08 July 2010 08:16
| Nitin Dahyabhai
Registered: July 2009
On 7/7/2010 10:02 PM, Dave Carver wrote:|
> Steffen Heil wrote on Sat, 03 July 2010 07:31
>> On their own, they all work fine.
>> However, in my own xml files (with correct xsd) I cannot find any way
>> Is this possible? how?
> Currently this isn't possible, as the editors don't know about
(Also applies to the very similar threads "How to syntax color/highlight
This question pops up every now and then, although without too many
specifics about what the use case is. The short answer is no, you can
a user can enable, and as it's not designed with scripting in mind, it's
not even something that can be added by a plug-in developer. At least
not for standard, generic, all-purpose XML files. If there's a public
standard around doing so that's widely-used and well-defined, I'd
really like to know about it, because otherwise I don't see this being
implemented in WTP.
It's not impossible, though. The XML Editor, and the SSE framework it's
built on, are strongly tied to the Eclipse Platform's content types and
built with flexibility in mind. SSE varies how its models are built and
how its editor(s) behave starting with content types, so the first task
their own Content Type . The platform supplies some describer classes
would might be of use, plus there is the recently introduced
class. Because you'll want to reuse the existing XML support as much as
possible, you'll want the org.eclipse.core.runtime.xml content type to
be the new content types's base type.
In SSE, everything revolves around the text document. For better or
worse that means having our own implementation of one, so the next task
is getting the Platform to use it for files of the new content type.
This is done with the deprecated extension point,
org.eclipse.core.filebuffers.documentCreation, associating your new
content type ID with our
class org.eclipse.wst.html.core's plugin.xml is a good example for this.
With the text document chosen, it's time to look at how languages get
combined together in SSE. For the most part, we lean on the Platform's
established concept of a document partition. Feel free to explore the
JavaDoc around this in depth, but the short of it is that a document is
divided into different typed partitions (confusingly you'll find a lot
of the text APIs also call this a content type, which makes sense in
context), and SSE loads and enables functionality using the partition
types. Here's where it gets tricky: partitions are created using a
document partitioner, and to identify the contents of a CDATA section
(or between special start/end tags) as anything other than CDATA
requires a new partitioner class. This is why standard, generic,
partition type for CDATA at all, and for the generic case, it needs to
keep being treated as CDATA. Hooking in a new partitioner class for a
new content type doesn't take a lot of code. Again using
org.eclipse.wst.html.core as an example, you use the
org.eclipse.wst.sse.core.modelHandler extension point to assign an SSE
model handler to your content type. That model handler specifies a
document loader class which, in turn, acts as a factory to create the
partitioner. The specifics of writing the partitioner I'll leave to the
want to keep returning the same partitions with the same types.
functionality into the editor using the new content type and partition
type. Keep in mind that most of the content assist and validation code
that exists there was written with a surrounding HTML or JSP document in
mind, so some custom code may need to be written, especially for content
assist and validation.
http://help.eclipse.org/helios/topic/org.eclipse.platform.do c.isv/reference/extension-points/org_eclipse_core_contenttyp e_contentTypes.html
Eclipse WTP Source Editing and JSDT
Eclipse WTP, IBM
Current Time: Tue Oct 21 05:23:45 GMT 2014
Powered by FUDForum
. Page generated in 0.01639 seconds