Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Open Model Element menu item
Open Model Element menu item [message #676764] Mon, 06 June 2011 12:59 Go to next message
Mark Christiaens is currently offline Mark ChristiaensFriend
Messages: 63
Registered: October 2010
Member
I just noticed that there is an "Open Model Element" menu item in the "Navigate" menu. It seems to have been contributed by the plugins/org.eclipse.xtext.ui.shared/plugin.xml. I don't see a good way to disable it in our product since both the handler code (org.eclipse.xtext.ui.search.OpenXtextElementHandler) and the XML configuration resides in the org.eclipse.xtext.ui.shared plugin. I also think that I can't have a working product without this plugin.

Is this intentional or should I file a bug?
---
Mark Christiaens
Discover the Future of VHDL Design
Go to www.sigasi.com
Re: Open Model Element menu item [message #676823 is a reply to message #676764] Mon, 06 June 2011 15:52 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Mark

As a workaround you can configure some UI (platform) Capabilities to
throw away what you don'r like.

Regards

Ed Willink

On 06/06/2011 13:59, Mark Christiaens wrote:
> I just noticed that there is an "Open Model Element" menu item in the
> "Navigate" menu. It seems to have been contributed by the
> plugins/org.eclipse.xtext.ui.shared/plugin.xml. I don't see a good
> way to disable it in our product since both the handler code
> (org.eclipse.xtext.ui.search.OpenXtextElementHandler) and the XML
> configuration resides in the org.eclipse.xtext.ui.shared plugin. I
> also think that I can't have a working product without this plugin.
> Is this intentional or should I file a bug?
> ---
> Mark Christiaens
> Discover the Future of VHDL Design
> Go to http://www.sigasi.com
Re: Open Model Element menu item [message #677005 is a reply to message #676823] Tue, 07 June 2011 09:58 Go to previous messageGo to next message
Mark Christiaens is currently offline Mark ChristiaensFriend
Messages: 63
Registered: October 2010
Member
Thanks for the tip. I took a good look at the capabilities stuff but I'm a bit reluctant to use it. The "Open Model Element" search dialog searches through the entire workspace. So you can be editing a file from a different project (using a different language) and you'll still be able to search for the model elements of our projects.

If I want to avoid that our users to search through the model elements, then I'll have to somehow disable this dialog for the entire workspace. But what if another Xtext plugin is also loaded in eclipse that expects that this functionality is enabled? So, my main problem is that I don't know what the right point is at which to disable this dialog.

This dialog sounds like a useful development tool but something that should not be present in a final product.
Re: Open Model Element menu item [message #677022 is a reply to message #677005] Tue, 07 June 2011 10:24 Go to previous messageGo to next message
Sebastian Zarnekow is currently offline Sebastian ZarnekowFriend
Messages: 3118
Registered: July 2009
Senior Member
Hi Mark,

why do you think that this functionality is not helpful in a final
product. Wouldn't it be useful if a user can lookup architectures by
name and directly jump to their definition?

Even though the name 'Open Model Element' may not be very descriptive
I'd think it's still quite handy to be able to navigate to instances of
your language.

I think you could use perspectives to hide certain ui elements but I'm
not too familiar with this concept.

Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com

Am 07.06.11 11:58, schrieb Mark Christiaens:
> Thanks for the tip. I took a good look at the capabilities stuff but I'm
> a bit reluctant to use it. The "Open Model Element" search dialog
> searches through the entire workspace. So you can be editing a file from
> a different project (using a different language) and you'll still be
> able to search for the model elements of our projects.
> If I want to avoid that our users to search through the model elements,
> then I'll have to somehow disable this dialog for the entire workspace.
> But what if another Xtext plugin is also loaded in eclipse that expects
> that this functionality is enabled? So, my main problem is that I don't
> know what the right point is at which to disable this dialog.
> This dialog sounds like a useful development tool but something that
> should not be present in a final product.
Re: Open Model Element menu item [message #677048 is a reply to message #677022] Tue, 07 June 2011 12:12 Go to previous messageGo to next message
Mark Christiaens is currently offline Mark ChristiaensFriend
Messages: 63
Registered: October 2010
Member
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 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.
  • 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.
  • 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, ...


So I still think that it's a good development feature but needs more before it ends up by default in the product.

Mark
Re: Open Model Element menu item [message #677058 is a reply to message #677048] Tue, 07 June 2011 12:29 Go to previous messageGo to next message
Alexander Nittka is currently offline Alexander NittkaFriend
Messages: 1193
Registered: July 2009
Senior Member
Hi,

you can override bindings in the shared module via an extension point. Of course that has an effect on all deployed Xtext plugins. Something like the following should do the trick

<extension
         point="org.eclipse.xtext.ui.shared.overridingGuiceModule">
      <module
            class="org.xtext.example.mydsl.ui.OverwriteSharedModule">
      </module>
   </extension>

package org.xtext.example.mydsl.ui;

import com.google.inject.Binder;
import com.google.inject.Module;

public class OverwriteSharedModule implements Module {

        public OverwriteSharedModule() {
        }

        public void configure(Binder binder) {
                binder.bind(From.class).to(To.class);

        }

}


Alex


Need training, onsite consulting or any other kind of help for Xtext?
Go visit http://xtext.itemis.com or send a mail to xtext@itemis.de
Re: Open Model Element menu item [message #677062 is a reply to message #677058] Tue, 07 June 2011 12:50 Go to previous message
Mark Christiaens is currently offline Mark ChristiaensFriend
Messages: 63
Registered: October 2010
Member
Excellent. Back door ... here I come Smile

While I'm looking at that extension point, I just notice that there is also a org.eclipse.xtext.ui.searchFilter extension point that seems to allow me to mess with the IXtextSearchFilter. Might be useful too.

Thanks,

Mark
Re: Open Model Element menu item [message #677067 is a reply to message #677048] Tue, 07 June 2011 12:36 Go to previous message
Jan Koehnlein is currently offline Jan KoehnleinFriend
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
Previous Topic:XBaseInterpreter with PureXbase
Next Topic:EClass from Ecore model in xtext runtime editor
Goto Forum:
  


Current Time: Thu Apr 25 12:51:08 GMT 2024

Powered by FUDForum. Page generated in 0.03626 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top