Eclipse Community Forums: TMF (Xtext) » [Xtext] Linking & implied imports

Home » Modeling » TMF (Xtext) » [Xtext] Linking & implied imports

[Xtext] Linking & implied imports [message #62889]

Wed, 22 July 2009 15:58

Eclipse User

My grammar allows references to imported constructs in a manner similar to
Java's implied import of all class names that reside in the same package.
Sven's article on integrating with the EMF index
< http://blog.efftinge.de/2009/07/xtext-scopes-and-emf-index-i n-action.html>
may be the right way to go ultimately. However, I don't need the parser
to actually load all the models until the syntax tree is interpreted. (At
present, the main goal is to analyze the model and the actual content of
imported models is extraneous.)

Since all the referenced models aren't required to be available at the
time of parsing, it seems that I could implement a LinkingService that
would produce an instance of the proper type whenever it's requested. What
I'm missing is the right way for my code to create a new EObject to
connect into the model.

Here is the method that I'm trying to implement:
public List<EObject> getLinkedObjects(EObject context, EReference ref,
AbstractNode node) throws IllegalNodeException {
List<EObject> result = super.getLinkedObjects(context, ref, node);
// If the default implementation resolved the link, return it
if (null != result && !result.isEmpty())
return result;
// Is this a reference to be stubbed?
if (getFileNameClass().isSuperTypeOf(ref.getEReferenceType()))
{
// Create the model element instance using the factory
PhysicalFileName stub =
getPackage().getPdlFactory().createPhysicalFileName();
// Get the stub's name from the text of the parse tree node.
stub.setName(getCrossRefNodeAsString(node));
result = Collections.singletonList((EObject)stub);
}
return result;
}

The problem is that any linking that resolves to my stub is flagged as an
error "contains a dangling reference
'ch.viveo.pdl.impl.PhysicalFileNameImpl...'
I hope someone can give me an idea how to tuck my stub into the model so
it no longer dangles.

Thanks!
John

Re: [Xtext] Linking & implied imports [message #62891 is a reply to message #62889]

Wed, 22 July 2009 16:03

Eclipse User

Hi John,

please ensure that your created EObjects are actually contained in
another object or directly in a resource. EMF Objects may not exist
without an owner or they have to be a root element in a resource.

Btw: I like the approach :-)

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

Am 22.07.2009 21:58 Uhr, schrieb John Bito:
> My grammar allows references to imported constructs in a manner similar
> to Java's implied import of all class names that reside in the same
> package. Sven's article on integrating with the EMF index
> < http://blog.efftinge.de/2009/07/xtext-scopes-and-emf-index-i n-action.html>
> may be the right way to go ultimately. However, I don't need the parser
> to actually load all the models until the syntax tree is interpreted.
> (At present, the main goal is to analyze the model and the actual
> content of imported models is extraneous.)
>
> Since all the referenced models aren't required to be available at the
> time of parsing, it seems that I could implement a LinkingService that
> would produce an instance of the proper type whenever it's requested.
> What I'm missing is the right way for my code to create a new EObject to
> connect into the model.
> Here is the method that I'm trying to implement:
> public List<EObject> getLinkedObjects(EObject context, EReference ref,
> AbstractNode node) throws IllegalNodeException {
> List<EObject> result = super.getLinkedObjects(context, ref, node);
> // If the default implementation resolved the link, return it
> if (null != result && !result.isEmpty())
> return result;
> // Is this a reference to be stubbed?
> if (getFileNameClass().isSuperTypeOf(ref.getEReferenceType()))
> {
> // Create the model element instance using the factory PhysicalFileName
> stub = getPackage().getPdlFactory().createPhysicalFileName();
> // Get the stub's name from the text of the parse tree node.
> stub.setName(getCrossRefNodeAsString(node));
> result = Collections.singletonList((EObject)stub);
> }
> return result;
> }
>
> The problem is that any linking that resolves to my stub is flagged as
> an error "contains a dangling reference
> 'ch.viveo.pdl.impl.PhysicalFileNameImpl...'
> I hope someone can give me an idea how to tuck my stub into the model so
> it no longer dangles.
>
> Thanks!
> John
>
>

Re: [Xtext] Linking & implied imports [message #62895 is a reply to message #62891]

Wed, 22 July 2009 20:10

Eclipse User

I was hoping for some ideas about how to set the newly created object's
container. In the Xtext excerpt below, Join and View are SyntaxNodes;
FileName and SimpleFileName are reference classes (e.g. ref=[FileName]).
I'm trying to use PhysicalFileName as the type for my stub EObject.

//Abstract type for resolving links from Joins to views
FileName:
Join | SimpleFileName ;

SimpleFileName:
View | PhysicalFileName ;

PhysicalFileName:
name=ID ;

There's really no token to be parsed for PhysicalFileName - it just seemed
the easiest way to get it to compile. I've tried to set the created
EObject as the value of an EReference feature, but there's still the
'dangling reference' error.

It turns out that if getLinkedObjects returns null instead of the empty
List, there is no problem reported by the editor. You can see the
LinkingService implementation on my blog
< http://jwbito.ballardview.com/2009/07/xtext-linking-one-step -at-time.html>.

I'd be grateful for pointers on how the idea originally proposed in this
thread might be made to work.

Re: [Xtext] Linking & implied imports [message #62901 is a reply to message #62895]

Thu, 23 July 2009 04:23

Eclipse User

Hi John,

please try something like this:

public List<EObject> getLinkedObjects(EObject context, EReference ref,
AbstractNode node) throws IllegalNodeException {
List<EObject> result = super.getLinkedObjects(context, ref, node);
// If the default implementation resolved the link, return it
if (null != result && !result.isEmpty())
return result;
// Is this a reference to be stubbed?
if (getFileNameClass().isSuperTypeOf(ref.getEReferenceType()))
{
// Create the model element instance using the factory
PhysicalFileName stub =
getPackage().getPdlFactory().createPhysicalFileName();
// Get the stub's name from the text of the parse tree node.
stub.setName(getCrossRefNodeAsString(node));

// prevent dangling object error
// 'stub' will be automatically visible by subsequent
// calls to the scope provider
context.eResource().getContents().add(stub);

result = Collections.singletonList((EObject)stub);
}
return result;
}

Nice blog entry :-)
Btw: It is save to use PdlPackage.eINSTANCE to retrieve the package. The
eClass can be obtained via PdlPackage.Literals.FILE_NAME (or similar).

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

Am 23.07.2009 2:10 Uhr, schrieb John Bito:
> I was hoping for some ideas about how to set the newly created object's
> container. In the Xtext excerpt below, Join and View are SyntaxNodes;
> FileName and SimpleFileName are reference classes (e.g. ref=[FileName]).
> I'm trying to use PhysicalFileName as the type for my stub EObject.
>
> //Abstract type for resolving links from Joins to views
> FileName:
> Join | SimpleFileName ;
>
> SimpleFileName:
> View | PhysicalFileName ;
>
> PhysicalFileName:
> name=ID ;
>
> There's really no token to be parsed for PhysicalFileName - it just
> seemed the easiest way to get it to compile. I've tried to set the
> created EObject as the value of an EReference feature, but there's still
> the 'dangling reference' error.
>
> It turns out that if getLinkedObjects returns null instead of the empty
> List, there is no problem reported by the editor. You can see the
> LinkingService implementation on my blog
> < http://jwbito.ballardview.com/2009/07/xtext-linking-one-step -at-time.html>.
>
>
> I'd be grateful for pointers on how the idea originally proposed in this
> thread might be made to work.
>

Re: [Xtext] Linking & implied imports [message #62905 is a reply to message #62895]

Thu, 23 July 2009 04:32

Eclipse User

Hi John,

I get the impression that the Xtext LazyLinker already does most of what
you want. I.e. after parsing and linking all cross references link to
proxy objects (of the correct type). It is not until later, when for
instance the editor or validator navigates these references, the proxies
get resolved (i.e. replaced with the "real" objects returned by the
linking service). So if you load and analyze your model programatically
you would never have to resolve these proxies and everything should work
out of the box.

If you still want your linking service to return stub objects you will
have to attach them somewhere. You could simply add them as top-level
objects to the same resource as the context object. E.g.

PhysicalFileName stub =
getPackage().getPdlFactory().createPhysicalFileName();
stub.setName(getCrossRefNodeAsString(node));
context.eResource().getContents().add(stub);
result = Collections.singletonList((EObject)stub);

You should probably add some code to check if a corresponding stub
already exists in the resource. Further I think it would make more sense
to add all the stubs to a separate resource. E.g.

URI stubsUri = URI.createURI("file:/tmp/dummy-stubs.xmi");
Resource stubsResource =
context.eResource().getResourceSet().getResource(stubsUri, false);
if (stubsResource == null) {
stubsResource =
context.eResource().getResourceSet().createResource(stubsUri );
}
PhysicalFileName stub =
getPackage().getPdlFactory().createPhysicalFileName();
stub.setName(getCrossRefNodeAsString(node));
stubsResource.getContents().add(stub);
result = Collections.singletonList((EObject)stub);

Hope that helps,

--knut

John Bito wrote:
> I was hoping for some ideas about how to set the newly created object's
> container. In the Xtext excerpt below, Join and View are SyntaxNodes;
> FileName and SimpleFileName are reference classes (e.g.
> ref=[FileName]). I'm trying to use PhysicalFileName as the type for my
> stub EObject.
>
> //Abstract type for resolving links from Joins to views
> FileName:
> Join | SimpleFileName ;
>
> SimpleFileName:
> View | PhysicalFileName ;
>
> PhysicalFileName:
> name=ID ;
>
> There's really no token to be parsed for PhysicalFileName - it just
> seemed the easiest way to get it to compile. I've tried to set the
> created EObject as the value of an EReference feature, but there's still
> the 'dangling reference' error.
>
> It turns out that if getLinkedObjects returns null instead of the empty
> List, there is no problem reported by the editor. You can see the
> LinkingService implementation on my blog
> < http://jwbito.ballardview.com/2009/07/xtext-linking-one-step -at-time.html>.
>
>
> I'd be grateful for pointers on how the idea originally proposed in this
> thread might be made to work.
>

Re: [Xtext] Linking & implied imports [message #62936 is a reply to message #62905]

Thu, 23 July 2009 11:28

Eclipse User

Thanks Sebastian and Knut for the instructive responses!

I'll update my code and blog post to reflect your suggestions, though I'll
have to think about whether there's a good place to create an alternate
resource to hold my stubs. I'm inclined to think of the stubs as a
temporary aspect of the resource containing the references.

Knut's observation about LazyLinker not being part of a standalone app is
relevant. The analysis includes warnings about antipatterns (raised by my
Xtext validators) and it's quite helpful to use the Eclipse editor and
annotations to refactor the code; hence the motivation to remove the
errors for unresolved references. That's one of the reasons Xtext is a
really great toolset for this project!

Thanks again!
John

Re: [Xtext] Linking & implied imports [message #62938 is a reply to message #62936]

Thu, 23 July 2009 12:12

Eclipse User

John Bito wrote:

Now I learn why attaching the stub EObject to the resource being parsed
isn't a good idea: the DefaultXtextResourceChecker is iterating over the
resource eContents and a ConcurrentModificationException is thrown.

Thanks to Knut for the pointer on creating a new resource!

Previous Topic:	[XText] Importing Ecore - EOF Error
Next Topic:	[Xtext] static initializer size problem in generated parser code

Goto Forum:

-=] Back to Top [=-

Current Time: Fri May 09 01:54:15 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter