|
|
|
|
|
|
|
Re: Open Model Element menu item [message #677067 is a reply to message #677048] |
Tue, 07 June 2011 12:36 |
Jan Koehnlein Messages: 760 Registered: July 2009 Location: Hamburg |
Senior Member |
|
|
Answers inline.
Am 07.06.11 14:12, schrieb Mark Christiaens:
> I don't think it should be in a final product by default because:
>
> It shows an internal implementation detail of the product. I think that
> there are many use cases where the user is never dealing with the EMF
> model directly so he'll be mostly puzzled about what this functionality
> is for.
I disagree here. It is a navigation facility that does not require a
specific context, similar to "Open Resource" which is also always
present. Users will appreciate that feature, as they can avoid doing
text search in favor of something that is aware of the semantics.
> I would leave it up to the developer of the product to decide if
> this should be shown. It crosses project boundaries. It seems to search
> in all resources in the entire workspace. I don't think that makes sense
> when you have multiple, unrelated Xtext-based languages in the same IDE.
The "Open Model Element" action is based on Xtext's index which covers
the whole workspace and all languages. That's why we made it a global
action. It does not by itself search the workspace. And the idea *is* to
enable cross-language functionality.
> It's enabled for projects that have nothing to do with Xtext at all. I
> created a new Java project with one class. "Open Model Element" is
> present in the Navigation menu.
As mentioned, you can hide it using the capabilities API or by defining
your own perspective.
> It seems to rigid: The entire implementation sits inside the
> org.eclipse.xtext.ui.shared plugin. The Eclipse command is defined in
> that plugin, the handler is defined in that plugin and the binding to a
> menu item is in that plugin. Don't seem able to inject my own version of
> the IXtextEObjectSearch interface. I guess it is bound before the
> language specific injection can intervene. I'd like to be able to give
> it a better name, a different filtering behavior, ...
Filtering for your language can be configured using the extension point
org.eclipse.xtext.ui.searchFilter.
If you want to bind another implementation of IXtextEObjectSearch, you
could do that via the extension point
org.eclipse.xtext.ui.shared.overridingGuiceModule.
> So I still think that it's a good development feature but needs more
> before it ends up by default in the product.
>
> Mark
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
---
Get professional support from the Xtext committers at www.typefox.io
|
|
|
Powered by
FUDForum. Page generated in 0.03626 seconds