Skip to main content



      Home
Home » Modeling » TMF (Xtext) » Java-like Scoping
Java-like Scoping [message #736088] Thu, 13 October 2011 10:49 Go to next message
Eclipse UserFriend
Hello everyone,

since I have a DSL with nested elements, I thought it would be nice to let the user import external model files and call elements defined in those files.

Example:

file1.mydsl

package pack_extern {
     entity ent_extern {
          
     }
}


file2.mydsl

package pack1 {
     import "platform:/resource/testProject/file1.mydsl"
     entity ent1 {
          attribute1 : int64
          attribute2 : pack_extern.ent_extern
                                 ^^^
     }
}


When importing an external resource, the elements defined in that resource become visible in the actual file.

In the example I marked the line

pack_extern.ent_extern
          ^^^


because I'm interested how such a mechanism should be implemented - only the root element should be visible and the user should "navigate" through the AST of that model and choose the element he wants (exactly like the import package mechanism of Java).

I read this discussion, but it did not work for me.

Here's what I have at the moment:

- the import mechanism works fine and the elements from extern model files are visible, but NOT like elementA.elementB

The workflow:

fragment = scoping.ImportURIScopingFragment {}
fragment = exporting.QualifiedNamesFragment {}


The overridden class:

public class MyDslNameProvider extends DefaultDeclarativeQualifiedNameProvider {

     public String qualifiedName(EObject obj) {
          return NodeModelUtils.getNode(obj).getParent().getText() + "." + NodeModelUtils.getNode(obj).getText();
     }
}


If I try to write

pack_extern.


and want to trigger the autocomplete, nothing happens. But before that, I get the following exception (not in my code):

org.eclipse.emf.common.util.WrappedException: java.lang.ClassCastException: java.lang.String cannot be cast to org.eclipse.xtext.naming.QualifiedName
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.getEObject(LazyLinkingResource.java:205)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.resolveLazyCrossReference(LazyLinkingResource.java:141)
	at org.eclipse.xtext.linking.lazy.LazyLinkingResource.resolveLazyCrossReferences(LazyLinkingResource.java:102)
	at org.eclipse.xtext.EcoreUtil2.resolveLazyCrossReferences(EcoreUtil2.java:485)
	at org.eclipse.xtext.validation.ResourceValidatorImpl.resolveProxies(ResourceValidatorImpl.java:127)
	at org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:62)
	at org.eclipse.xtext.ui.validation.DefaultResourceUIValidatorExtension.addMarkers(DefaultResourceUIValidatorExtension.java:65)
	at org.eclipse.xtext.ui.validation.DefaultResourceUIValidatorExtension.updateValidationMarkers(DefaultResourceUIValidatorExtension.java:44)
	at org.eclipse.xtext.builder.builderState.MarkerUpdaterImpl.updateMarker(MarkerUpdaterImpl.java:56)
	at org.eclipse.xtext.builder.builderState.AbstractBuilderState.updateMarkers(AbstractBuilderState.java:76)
	at org.eclipse.xtext.builder.clustering.ClusteringBuilderState.doUpdate(ClusteringBuilderState.java:199)
	at org.eclipse.xtext.builder.builderState.AbstractBuilderState.update(AbstractBuilderState.java:107)
	at org.eclipse.xtext.builder.impl.XtextBuilder.doBuild(XtextBuilder.java:158)
	at org.eclipse.xtext.builder.impl.XtextBuilder.incrementalBuild(XtextBuilder.java:141)
	at org.eclipse.xtext.builder.impl.XtextBuilder.build(XtextBuilder.java:91)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)


I also tried implementing the IQualifiedNameProvider, but I did not succeed. Some examples would be great, unfortunately I didn't find any.

Suggestions/remarks? Any help is kindly appreciated.

EDIT: if I use

fragment = exporting.QualifiedNamesFragment {}


in the workflow, the auto-generated class AbstractDslUiModule has an error at the following lines:

// contributed by org.eclipse.xtext.generator.exporting.SimpleNamesFragment
public Class<? extends org.eclipse.xtext.ui.refactoring.IDependentElementsCalculator> bindIDependentElementsCalculator() {
     return org.eclipse.xtext.ui.refactoring.IDependentElementsCalculator.Null.class;
}


reads "org.eclipse.xtext.ui.refactoring.IDependentElementsCalculator.Null cannot be resolved to a type" Confused

I also tried getting rid of the exception by implementing the method like this:

public QualifiedName qualifiedName(EObject obj) { 
     if(! (obj.eContainer() instanceof EObject))
          return null;
     else
          return QualifiedName.create(NodeModelUtils.getNode(obj).getParent().getText(), NodeModelUtils.getNode(obj).getText());
}


The exception is no longer being thrown, but nothing happens, the feature I want to implement does not work.

[Updated on: Thu, 13 October 2011 11:03] by Moderator

Re: Java-like Scoping [message #736108 is a reply to message #736088] Thu, 13 October 2011 11:40 Go to previous messageGo to next message
Eclipse UserFriend
HI,

dont understand you problem. this works out of the box if your package and entity have an attribute name
and you have a rule like type[Entity|FQN] .... FQN: ID ("." ID)*;
out of the box

~Christian
Re: Java-like Scoping [message #736117 is a reply to message #736108] Thu, 13 October 2011 11:52 Go to previous messageGo to next message
Eclipse UserFriend
Hi Christian,

it does work, indeed! Thank you very much for the tip! The only thing that remains to be done is to make the autocompleter show only the elements on the "first level" and to show the children of the elements only when needed (i.e. when typing the dot). Otherwise the user sees a very long list, populated with elements like

elem1.child1
elem1.child2
elem5.child0
elem7
elem18.child3
elem99

which is not very user friendly. But the base functionality is here.

Thanks again!
Re: Java-like Scoping [message #736244 is a reply to message #736117] Thu, 13 October 2011 17:09 Go to previous message
Eclipse UserFriend
Hi,

you could filter the proposals
or do it another way:

Model:
	packages+=Package+;
	
Package:
	"package" name=ID "{"
		entities+=Entity*
	"}"
;

Entity:
	"entity" name=ID "{"
		attributes+=Attribute*
	"}"
;

Attribute:
	name=ID ":" type=Type
;

Type:
	SimpleType | Reference
;

SimpleType:
	type=ID
;

Reference:
	package=[Package] "." entity=[Entity]
;


public class MyDslScopeProvider extends AbstractDeclarativeScopeProvider {

	IScope scope_Reference_entity(Reference r, EReference ref) {
		return Scopes.scopeFor(r.getPackage().getEntities());
	}
	
}


~Christian
Previous Topic:Exception loading xtext-files on commandline
Next Topic:create document for xtext grammar
Goto Forum:
  


Current Time: Wed Oct 29 13:01:22 EDT 2025

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

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

Back to the top