Allow QueryBrowser on Xtext resource?

[Joost van Pinxten]

I see the behavior that the QueryBrowser only detects opened EMF Editors for possible model linking. However, I believe that I read somewhere that any EMF model instance could be used. As Xtext provides such an instance, would it be possible to detect the models in an Xtext editor too? This would mean that I don't have to open the same resource in two different editors :-)

Would certainly be 'nice to have'! Shall I create a Feature Request on the Bugzilla?

[István Ráth]

Hi,

theoretically, attaching to any EMF instance model is possible. We are currently migrating our issues from GitHub over to Eclipse, but if you feel like it, feel free to create a feature request to support targeting EMF instance models through a, say, Plugin Spy-like generic interface.

Xtext, however, is unfortunately problematic due to two reasons: 

-  the EMF instance model built by Xtext is rebuilt almost from scratch each time you save, so using IncQuery on it does not have much benefit in terms of performance

- if you build your Xtext DSL on top of Xbase (as we do), then the resulting EMF instance model will not behave in an API-correct way w.r.t. to sending change notifications and materialize a *lot* of external resources from the Java classpath. We have experimented with this before and found that this scenario is basically not supported at the moment.

regards

Istvan

[Joost van Pinxten]

Hi

Op dinsdag 22 januari 2013 11:17:54 UTC+1 schreef István Ráth het volgende:

Hi,

theoretically, attaching to any EMF instance model is possible. We are currently migrating our issues from GitHub over to Eclipse, but if you feel like it, feel free to create a feature request to support targeting EMF instance models through a, say, Plugin Spy-like generic interface.

Created:  398715

Xtext, however, is unfortunately problematic due to two reasons: 

-  the EMF instance model built by Xtext is rebuilt almost from scratch each time you save, so using IncQuery on it does not have much benefit in terms of performance

- if you build your Xtext DSL on top of Xbase (as we do), then the resulting EMF instance model will not behave in an API-correct way w.r.t. to sending change notifications and materialize a *lot* of external resources from the Java classpath. We have experimented with this before and found that this scenario is basically not supported at the moment.

Yes, I realize that, but for early pattern prototyping, this would certainly still be interesting. The DSL I'm using is not extending Xbase, but your point about Xtext rebuilding the model is true. However, I believe this only holds for the resource being edited; as I've split my model into different resources, where a main entry defines the parameters and cross-references the actual model (which does not change). It might turn out to be less of a problem for me.