| Expanded IGotoMarker [message #327236] |
Mon, 14 April 2008 13:15  |
Eclipse User |
|
|
|
Originally posted by: eric.wittmann.active-endpoints.com
I would like to suggest an expansion to the marker navigation facilities
in Eclipse.
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, of course, the EMF index contains the 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.
Thoughts?
|
|
|
| Re: Expanded IGotoMarker [message #327301 is a reply to message #327236] |
Tue, 15 April 2008 12:09  |
 Dani Megert
Messages: 3802
Registered: July 2009 |
Senior Member |
|
|
Eric Wittmann wrote:
> I would like to suggest an expansion to the marker navigation
> facilities in Eclipse.
>
> 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, of course, the EMF index contains
> the 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.
>
> Thoughts?
Sounds fair to file a request. You could also add a workaround for your
markers: add a part listener and when an editor is opened you check
whether your markers are affected and then updated them. This will
trigger a resource delta and let your markers appear.
Dani
|
|
|
Powered by
FUDForum. Page generated in 0.03871 seconds
] 
Search
Help
Register
Login
Home
