Home » Language IDEs » ServerTools (WTP) » Javascript inside XML editing(How to use the javascript editor inside xml other than xhtml)
| |
| Re: Javascript inside XML editing [message #545537 is a reply to message #545485] |
Thu, 08 July 2010 08:16  |
|
On 7/7/2010 10:02 PM, Dave Carver wrote:
> Steffen Heil wrote on Sat, 03 July 2010 07:31
>> In eclipse I often use the html, javascript and xml editors.
>> On their own, they all work fine.
>>
>> Also, javascript embedded in html is working fine.
>> However, in my own xml files (with correct xsd) I cannot find any way
>> to tell eclipse to enable the javascript editor for embedded javascript.
>>
>> Is this possible? how?
>>
>> Regards,
>> Steffen
>
>
> Currently this isn't possible, as the editors don't know about
> javascript content. Please open an enhancement request.
(Also applies to the very similar threads "How to syntax color/highlight
Javascript node inside XML node?" and "Javascript highlighting in CDATA
content")
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
not enable JavaScript support within the XML Editor. It's not something
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
would be to identify the files in which JavaScript should be enabled as
their own Content Type [1]. The platform supplies some describer classes
would might be of use, plus there is the recently introduced
org.eclipse.jst.jsf.core.internal.contenttype.XMLDocumentEle mentAttributeContentDescriber
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
org.eclipse.wst.sse.core.internal.filebuffers.BasicStructure dDocumentFactory
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,
all-purpose XML won't be supporting JavaScript--it can't vary the
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
reader, but for everything but CDATA to be treated as JavaScript, you'll
want to keep returning the same partitions with the same types.
So now that the JavaScript is identified as JavaScript, you'll want to
use org.eclipse.wst.jsdt.web.ui as a guide for where to plug JavaScript
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.
[1]
http://help.eclipse.org/helios/topic/org.eclipse.platform.do c.isv/reference/extension-points/org_eclipse_core_contenttyp e_contentTypes.html
--
Nitin Dahyabhai
Eclipse WTP Source Editing and JSDT
IBM Rational
_
Nitin Dahyabhai
Eclipse Web Tools Platform
|
|
|
Goto Forum:
Current Time: Fri Apr 26 18:29:28 GMT 2024
Powered by FUDForum. Page generated in 0.03473 seconds |
] 
Search
Help
Register
Login
Home
