Description Eric Wittmann 2008-04-15 09:18:10 EDT

Scenario:

Need to implement a "Find References" feature for web service constructs (WSDL messages, port types, operations, schema Elements, types, etc...).  We have an XML index that lets us efficiently search within all resources in the workspace. The problem is that the index does not contain line and column information.  What we *can* easily produce from the XML index is an xpath to the element or attribute.

To implement this search feature, I would like to create custom Eclipse search markers (have my own marker subtype) that contains the xpath *instead* of line and column information.  I would then want to resolve the xpath into a line number when the user double-clicks on the maker in the Search view.  This way, the expensive part of the search for us (resolving xpaths to locations within a file) can be deferred.  The search will be fast, and the time to resolve the line information (which requires a Sax parse of the file) will be deferred until the double-click.  This also (likely ) effectively reduces the total amount of work done, unless the user double-clicks on every single result in the search.

Suggested implementation(s):

It seems to me that the IGotoMarker interface could be contributed via an extension point.  I could associate an IGotoMarker implementation with my custom search marker type.  The IDE.gotoMarker() method would first lookup any contributed implementations before checking the editor.

Alternatively, some new interface could be introduced which could serve as a marker pre-processor.  This would give me the opportunity to augment the marker meta data with line and column number information.  For my use case, it would be something like IMarkerLocationResolver.

It seems like other projects may have similar issues.  Isn't there an EMF index project out there that allows searching across EMF models?  I imagine they will face a similar issue once they start doing this sort of "find" searching unless the EMF index contains line and column information.

Current Work Around:

For search hits that fall within a BPEL file (for which we have our own editor) I simply add the xpath to the marker and the BPEL editor's IGotoMarker implementation knows how to navigate to the right place.  For all other search hits, I do the Sax parse to resolve the line information during the search.  This slows down the search, but it's still better than not having the index at all.  Still, we spend far more time parsing XML than searching for the right results in the index.