Comment 1 Nick Sandonato 2009-02-06 11:28:19 EST

Dave,

I'm glad you're taking a look at using the new semantic highlighting API to contribute stylings to XSL. To begin, you will need to add the extension to "org.eclipse.wst.sse.ui.semanticHighlighting". This takes an extension element of <highlighting>. You need to define a class for it that implements ISemanticHighlighting and define target content types for the semantic highlighting to be valid for (org.eclipse.wst.xml.core.xslsource). It sounds like you want to set up a different highlighting strategy per namespace, so you'll need an extension element per namespace.

The implementation of ISemanticHighlighting contains the preference store that will be used to look up all of the text attributes for the style as well as if that specific highlighting is enabled. The method of particular interest is consumes(IStructuredDocumentRegion). This method tells the semantic highlighting reconciler if that structured document region is consumable by the semantic highlighting. For you, it might be useful to actually grab the structured model for the document and use the IndexedRegion at the offset of the structured document region. If the indexed region is an ElementImpl, it should support the method getNamespaceURI(), which would help you identify a unique namespace. Of course, obtaining the model and looking up the indexed region does come with a cost, but the highlighting is done on a second pass.

I hope this is the kind of information you wanted. If not, please let me know and I'll try to help out some more.

Comment 2 David Carver 2009-02-06 12:43:38 EST

Thanks Nick, I'll take a look at this early in 1.0M6.

> the structured document region. If the indexed region is an ElementImpl, it
> should support the method getNamespaceURI(), which would help you identify a
> unique namespace. Of course, obtaining the model and looking up the indexed
> region does come with a cost, but the highlighting is done on a second pass.

One thing I think we need to be aware of in regards to Namespaces is that attributes can belong to their own namespace as well.   Perfect example is xml:space and xml:id, both belong to the XML namespace, but are attributes.  Same thing for xsi:type belonging to the XML Schema Instance namespace.   I'll investigate this as I look into it, as with XSLT you can have extensions and each extension is defined in a namespace.   This is particularly important in XSLT 2.0 when creating user defined functions.


> 
> I hope this is the kind of information you wanted. If not, please let me know
> and I'll try to help out some more.

Yeah, this should get me started, I'll have more questions as I try to use it.

Comment 3 Nick Sandonato 2009-02-11 10:57:12 EST

Hi Dave,

I've added a section to the New Help for Old Friends about Semantic Highlighting. If you come across something as you're implementing this that might clarify the section, or make things easier for other adopters, please let me know; I'd love to add it.

http://wiki.eclipse.org/New_Help_for_Old_Friends_IV#Semantic_Highlighting

Comment 4 David Carver 2009-03-06 21:13:47 EST

Nick unfortunately I'm not going to get to this in time for M6.   I'll try and get this done early during 1.1 M1 though after Galileo is out.

Comment 5 David Carver 2009-04-30 14:24:31 EDT

mass update to 3.1 target due to movement from wtp incubator to wtp source editing lost the original milestones.

Comment 6 David Carver 2009-05-11 22:58:56 EDT

migrating prior 3.1 enhancements for future for further triage and planning.

Comment 7 David Carver 2009-07-03 23:54:12 EDT

going to tentatively target this for target 3.2m2.

Comment 8 David Carver 2009-08-24 19:58:42 EDT

Going to target this for the 3.2 time frame.  I'd like to leverage  the semantic highlighting that was done in 3.1.   Nick do you have some code samples on implenting this?

Comment 9 Nick Sandonato 2009-08-26 08:56:18 EDT

Hi Dave,
attachment 118630 [details] from bug 232752 is an example that has two highlighters that highlight namespaces for org.eclipse.core.runtime.xml / org.eclipse.wst.xml.core.xmlsource and org.eclipse.jst.j2ee.webDD.

Hopefully this can get you started. If you'd like more, please let me know.

Comment 10 David Carver 2009-09-02 15:24:37 EDT

Assigning inbox items to triaged since these have all be triaged.

Comment 11 David Carver 2009-11-25 15:15:34 EST

Nick I started to look at this today and here are some things I noticed.

The semantic highlighter sets up a bunch of preference keys for working storing it's values.   However, I have existing keys for XSL that are modeled off the XML syntax highlighter, and this uses the ColorHelper to pack the values for bold, italic, etc, into one key value.   The current way the SemanticHighlighter is setup there isn't an easy way to map this, as it expects to have it's own keys for controling items like Bold, Italic, Strike Through etc.

Also, there is no UI to allow an end user to change the preferences for the semantic highlighting.   My use case is to use the existing XML highlighting and then semantically colore the XSL elements and attributes based on the user preferences.   As it stands now, I'm probably going to have to keep my existing syntax highlighting.

Thoughts.

Comment 12 David Carver 2009-11-25 15:16:34 EST

Created attachment 153113 [details]
Start of Semantic Highlighting for XSL

Comment 13 David Carver 2009-11-25 15:19:22 EST

Created attachment 153114 [details]
Patch for Semantic Highlight for XSL Tags

This is just a sample, but trying to figure out how to map semantic highlighting to existing keystore values so existing users don't loose functionality.

Comment 14 Nick Sandonato 2009-11-30 15:04:55 EST

Hi Dave, thanks for taking a shot at building something. I see the issue at hand. I can't think of any existing method for you to use to exercise the preference strings that you have. An alternate interface might be something that offers:

isUnderline()
isBold()
isItalic()
isStrikethrough()
isEnabled()
getColor() or maybe a getRGB()?

Then, since we track these highlightings, we'd want to know about any preference store changes for that highlighting, so maybe a method that could tell us which attributes were updated:

getAffectedCharacteristics(PropertyChangeEvent) returns something like an int with flags identifying which characteristics changed, that way our array of semantic highlightings can be updated appropriately.

Comment 15 David Carver 2009-11-30 16:26:34 EST

(In reply to comment #14)
> Hi Dave, thanks for taking a shot at building something. I see the issue at
> hand. I can't think of any existing method for you to use to exercise the
> preference strings that you have. An alternate interface might be something
> that offers:
> 
> isUnderline()
> isBold()
> isItalic()
> isStrikethrough()
> isEnabled()
> getColor() or maybe a getRGB()?
> 
> Then, since we track these highlightings, we'd want to know about any
> preference store changes for that highlighting, so maybe a method that could
> tell us which attributes were updated:
> 
> getAffectedCharacteristics(PropertyChangeEvent) returns something like an int
> with flags identifying which characteristics changed, that way our array of
> semantic highlightings can be updated appropriately.

Or if we have something where I can just pass in an existing PreferenceStore, and the Key, then have the semantic highlighter parse the information from the ColorHelper..  This would allow use of existing preference stores to be migrated to semantic highlighting.   As it stands now it won't work for existing syntax highlighting to migrate to symantic..plus there still needs to be a way to put this in the UI via the preference pages.

I see the current system being useful to say programmatically do things, but not from a UI perspective.

Comment 16 Nick Sandonato 2009-12-02 14:19:22 EST

Yup, I could see the snag with existing preference stores that utilize the style strings.

The existing interface already returns an IPreferenceStore using getPreferenceStore(). I'll play with an interface and SemanticHighlightingManager implementation for supplying a style string and parsing that string using a ColorHelper and I'll place a patch up here.

Comment 17 Nick Sandonato 2009-12-03 13:12:13 EST

Hi David, I opened a new bug 296838 to track adding existing syntax highlighting preferences to the semantic highlighting framework. Hope this will help out.

Comment 18 David Carver 2010-01-09 21:37:25 EST

Created attachment 155669 [details]
Patch to add XSL Semantic Highlighting

Comment 19 David Carver 2010-01-09 21:41:16 EST

Nick, I have everything working except for dealing with the XML_TAG_OPEN and XML_TAG_CLOSE regions.   For some reason when I enable the XSLTagDeliminsSemanticHighlighting class in the plugin.xml, it causes a SemanticHighlighting error code of 1. (Yeah really descriptive).

Think you could try the patch I attached, and just enable the XSLTagDelims class to see if you can replicate the issue.  Any ideas on how to fix it would be nice.

Also, is there a way to get the namespace for a IStructuredDocumentRegion or a TextRegion.  I really would prefer keying off the namespace of the node instead of hard coding the "xsl:" prefix.

Comment 20 Nick Sandonato 2010-01-11 13:46:59 EST

(In reply to comment #19)
> Nick, I have everything working except for dealing with the XML_TAG_OPEN and
> XML_TAG_CLOSE regions.   For some reason when I enable the
> XSLTagDeliminsSemanticHighlighting class in the plugin.xml, it causes a
> SemanticHighlighting error code of 1. (Yeah really descriptive).
> 
> Think you could try the patch I attached, and just enable the XSLTagDelims
> class to see if you can replicate the issue.  Any ideas on how to fix it would
> be nice.
> 
> Also, is there a way to get the namespace for a IStructuredDocumentRegion or a
> TextRegion.  I really would prefer keying off the namespace of the node instead
> of hard coding the "xsl:" prefix.

Hi Dave,

I think you might need to check that openPos and closePos are not null before adding them as a List to arrpos, as they are null for the XML declaration.

As far as getting the namespace of the node, I think you would actually need the Element that contains the IStructureDocumentRegion. I'm not aware of any utility that we have to go directly from the region to the namespace.

Comment 21 David Carver 2010-01-11 19:00:11 EST

(In reply to comment #20)
> As far as getting the namespace of the node, I think you would actually need
> the Element that contains the IStructureDocumentRegion. I'm not aware of any
> utility that we have to go directly from the region to the namespace.

Yeah, basically given a TagName or AttrTagName that has a QName combination.

i.e. prefix:local-name

So need to look up the namespace for the prefix and then do semantic highlighting.

Comment 22 David Carver 2010-02-03 18:31:19 EST

(In reply to comment #20)
> (In reply to comment #19)
> > Nick, I have everything working except for dealing with the XML_TAG_OPEN and
> > XML_TAG_CLOSE regions.   For some reason when I enable the
> > XSLTagDeliminsSemanticHighlighting class in the plugin.xml, it causes a
> > SemanticHighlighting error code of 1. (Yeah really descriptive).
> >
> > Think you could try the patch I attached, and just enable the XSLTagDelims
> > class to see if you can replicate the issue.  Any ideas on how to fix it would
> > be nice.
> >
> > Also, is there a way to get the namespace for a IStructuredDocumentRegion or a
> > TextRegion.  I really would prefer keying off the namespace of the node
> instead
> > of hard coding the "xsl:" prefix.
> 
> Hi Dave,
> 
> I think you might need to check that openPos and closePos are not null before
> adding them as a List to arrpos, as they are null for the XML declaration.
> 

Let me see what I can do with checking the the positions for null.  Stupid XML declaration.

Comment 23 David Carver 2010-02-20 20:00:28 EST

Created attachment 159679 [details]
Patch that uses new styleTag attribute

This patch leverages the styleAttribute to provide semantic highlighting for the XSL namespace.

Comment 24 David Carver 2010-02-26 15:52:11 EST

I'll get this in place early in 3.2M7 for final testing.

Comment 25 Nick Sandonato 2010-02-26 15:54:31 EST

(In reply to comment #24)
> I'll get this in place early in 3.2M7 for final testing.

Cool! I look forward to seeing it implemented.

Comment 26 David Carver 2010-03-24 15:34:05 EDT

I've just checked in the necessary changes to make this work with XSL.  There are still some reconcilation and refresh issues, but in general they are minor and I'll open separate bugs against sse.ui for these.