Eclipse Community Forums: ServerTools (WTP)

Home » Language IDEs » ServerTools (WTP) » XSLT extensions

Sat, 12 September 2009 01:54

Eclipse User

I started working with a group that has written their own XSLT
extensions (both functions and elements). I considered extending a text
editor and slapping together a partition scanner to provide content
assist and syntax highlighting. But then we would miss out on all the
great things the XSL editor does now.

So I downloaded the source for the XSL UI and took a look at the editors
and content assist processing. As I might have suspected, the classes
depend on lots of other WST components. I don't mind digging into to it
a bit. But before I do, I wondered how feasible it would be to extend
the XSL editor's content assist.

I also wondered whether the XSL tooling will soon support templates
contexts other than New XSL. While I find this one very useful, I'd
also like to see the Tag context like the XML editor has. Then I could
define many of my favorite extensions as templates without having to
write a plug-in.

Re: XSLT extensions [message #485747 is a reply to message #485500]

Mon, 14 September 2009 15:34

Eclipse User

One of the items I'm looking into is adding an Extension point to allow adopters to add their own XSLT extensions for content assist.

Processor Specific extensions bug is here:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=243581

And general Content Assistance extensions are here:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=259721

Now, you can look at the org.eclipse.wst.xsl.ui.internal.StructuredTextViewerConfigur ationXSL and see where it invokes the XSLContentAssistProcessor. What you could do is extend this the StructuredTextViewerConfigurationXSL class, to add in your content assitance Processor as well as keep the existing processor class. You would then need to create your own Editor extension point that use your StructuredTextViewerConfigurationXSL.

However, with this said, I would encourage you to look at enhancing the existing code to provide a general ContentAssistance extension point and have XSLContentAssistProcessor leverage that. The existing content assitance could then be contributed through extension point, and adopters could add their own.

Content Assistance is best implemented by extending the AbstractXSLContentAssistRequest class. This is what all of the current content assitance classes do. You can find everything in org.eclipse.wst.xsl.ui.contentassist.

If you do implement the extension point route, please consider contributing it back, and I'll make sure that I devote some time to getting it into a build.

Re: XSLT extensions [message #485748 is a reply to message #485500]

Mon, 14 September 2009 15:37

Eclipse User

Paul Glezen wrote on Sat, 12 September 2009 01:54

I also wondered whether the XSL tooling will soon support templates
contexts other than New XSL. While I find this one very useful, I'd
also like to see the Tag context like the XML editor has. Then I could
define many of my favorite extensions as templates without having to
write a plug-in.

One more note, if you add these to the XML editors Templates, you should get them showing up in the XSL editor. The XSL Editor extends the existing XML editor, and adds XSL specific functionality ontop of the built in XML editors functionality. We could look at adding XSL tag specific entries in the XSL editor itself.

Please open an enhancement request in bugzilla for this.

Dave

Re: XSLT extensions [message #485971 is a reply to message #485748]

Tue, 15 September 2009 13:57

Eclipse User

Indeed, it does work. I had tried it, but gave up when ctrl-space
didn't provide me the hint after typing a few characters. I didn't
realize the templates only come up if you hit ctrl-space before typing
anything. But this was because I had chosen "XML Tag" as my context.
When I changed it to "All XML", it works much like content assist !!

The feature request for additional context types in XSL editor templates
is 289498.

Dave Carver wrote:
> Paul Glezen wrote on Sat, 12 September 2009 01:54
>> I also wondered whether the XSL tooling will soon support templates
>> contexts other than New XSL. While I find this one very useful, I'd
>> also like to see the Tag context like the XML editor has. Then I
>> could define many of my favorite extensions as templates without
>> having to write a plug-in.
>
>
> One more note, if you add these to the XML editors Templates, you should
> get them showing up in the XSL editor. The XSL Editor extends the
> existing XML editor, and adds XSL specific functionality ontop of the
> built in XML editors functionality. We could look at adding XSL tag
> specific entries in the XSL editor itself.
>
> Please open an enhancement request in bugzilla for this.
>
> Dave
>
>

Re: XSLT extensions [message #486693 is a reply to message #485500]

Fri, 18 September 2009 11:33

Eclipse User

I've documented an alternative way to accomplish what you want that may work better:

http://intellectualcramps.blogspot.com/2009/09/xslt-processo r-extensions.html

Previous Topic:	Outline: only show heading (or hide p tags etc.)
Next Topic:	How to set the docType of an IDOMDocument

Goto Forum:

-=] Back to Top [=-

Current Time: Fri Jul 25 01:02:29 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter