Eclipse Community Forums: TMF (Xtext) » trouble defining cross-references in grammar

Home » Modeling » TMF (Xtext) » trouble defining cross-references in grammar(grammar like "type=[MyType | ID]" in problems)

trouble defining cross-references in grammar [message #706941]

Sun, 31 July 2011 23:39

Eclipse User

this part of grammar is taken from the domain model example.

Entity 
   entity name=ID

Attribute
   name=ID : type=[Entity|ID]

dsl attribute looks like:

// works ok.
   myAttribute=MyType // note: MyType is declared as an entity earlier.

   secondAttribute=plaintext // not a type but a value of type ID.

according to the grammar, "secondAttribute" seems right but the editor still shows an error marker saying: "Type plaintext not found." Anybody can help me with this please ?

+ Chetan

Re: trouble defining cross-references in grammar [message #706978 is a reply to message #706941]

Mon, 01 August 2011 00:52

Eclipse User

Hi, if you have a Cross Reference there has to be a target (entity) for that id: so you have to create an entity plaintext ~Christian

Re: trouble defining cross-references in grammar [message #706997 is a reply to message #706978]

Mon, 01 August 2011 01:31

Eclipse User

Maybe you are disturbed by the ¦id but this means not "or id" but "therefore parse an id" ~Christian

Re: trouble defining cross-references in grammar [message #707305 is a reply to message #706997]

Mon, 01 August 2011 09:30

Eclipse User

I think I mis-read '|' as 'OR'.

In my case, the reference can either be a defined entity or string (it is not defined). something like so:

// my-type attribute
first-attribute=my-type // valid

second-attribute=integer // integer is not a defined entity. just a primitive type

Error marker appears for 'second-attribute.' However, such an attribute is just like any java variable - primitive or some java type. So, i don't want the editor to have error marker but allow such primitive types.

is this best taken care in the grammar ? if not, is there any hook to curb such an error marker ?

+ Chetan

Re: trouble defining cross-references in grammar [message #707313 is a reply to message #707305]

Mon, 01 August 2011 09:39

Eclipse User

Hi,

in your case I would suggest the library approach. That is, provide a model file with the primitive types. In your grammar you then only have "Attribute name=ID : type=[Entity|ID]" and the library file might look like the following:

entity PrimitiveType1; entity PrimitiveType2;...

The advantage is that you don't hard-code the types in the grammar, i.e. you can change them without changing the grammar. You don't have unnecessary keywords and the meta model is cleaner.

If you want to solve the problem on the grammar level, I'd suggest an enum rule for primitive types.

Alex

Re: trouble defining cross-references in grammar [message #707325 is a reply to message #707313]

Mon, 01 August 2011 09:59

Eclipse User

Thanks Alexander!
I used domain model example to explain the problem easily. My grammar for this cross reference is something like:
Type:
'@type' type=[Typedef|ID];

Typedef:
name=ID
type=Typedef;

Even if I define a library file with primitive types, i'd still get an error marker for 'type' of library file.

+ Chetan

Re: trouble defining cross-references in grammar [message #707330 is a reply to message #707325]

Mon, 01 August 2011 10:15

Eclipse User

Hi,

your Typedef rule looks very strange. Have you checked that the library-file-types are in the index (Shift-Ctrl-F3) and that the file is on the class path of the project containing the referencing model file (i.e. that the primitive types are visible at all)?

Alex

Re: trouble defining cross-references in grammar [message #707599 is a reply to message #707330]

Mon, 01 August 2011 17:17

Eclipse User

Hi Alex,

thanks for the response.
Typedef allows you to define recursively. (an alias named as the element itself - stupid as it sounds, but that's one requirement)

I am able to see elements defined in library file on the index.

My problem now is with hyperlinking elements defined in one dsl file with their reference in another file. There is no import statement as such. I am trying to override IScopeProvider to search and return proper scope instance.

Going through documentation and some older posts, i defined this method:
scope_Type_type(final Type type, EReference typeRef) // type.getType returns a typedef

cross-references in same dsl file are resolved fine, but across files are not. Since I do not have explicit import statement (or URI) I want to find out the target type from the index and return a scope. I can see target type instance in the index, just don't know how to use the index in this code. Is it a good idea to do so ?

+ Chetan

Re: trouble defining cross-references in grammar [message #708123 is a reply to message #707599]

Tue, 02 August 2011 09:39

Eclipse User

Hi,

before you touch the scope provider (which may not be necessary in your case):
Do you use the simple or the qualified name fragment?
Do you use the import uri or the import namespace fragment (use the latter one)?
In the "index" what do the names of the Typedefs look like?
Where are the files containing the elements you want to reference located (in the same folder, in another project?

The Typedef rule looks strange, as it seems to be a recursion that does not end. Each Typedef must contain another Typedef...

Alex

Re: trouble defining cross-references in grammar [message #708325 is a reply to message #708123]

Tue, 02 August 2011 13:35

Eclipse User

RuntimeModule class uses "DefaultDeclarativeQualifiedNameProvider." I guess that's qualified name fragment.
In the index, names of typedefs look like: 'root.parent1.parent2.my-typedef'
Files can be in different folders but under same project.

Sorry about the earlier shown Typedef grammar, i missed out []
so its:

Typedef:
  name=ID
  type=[Typedef|ID];

Re: trouble defining cross-references in grammar [message #708328 is a reply to message #708325]

Tue, 02 August 2011 13:43

Eclipse User

Hi,

this means that (without changes) you cannot reference types via their simple name in general. The simplest thing would be to change "attribute=[Entity|ID]" to "attribute=[Entity|Fqn]" and introduce the datatype rule
Fqn: ID('.'ID)*;

The qualified name fragment determines the name of an object based on its name attribute and the names found within the containment hierarchy.

Alex

Re: trouble defining cross-references in grammar [message #708346 is a reply to message #708328]

Tue, 02 August 2011 14:12

Eclipse User

so, that means if i have to refer to 'typedef1' which is present in a different file (say under "parent" object) then in my dsl I should specify as:

  @type  parent.typedef1

Re: trouble defining cross-references in grammar [message #708358 is a reply to message #708346]

Tue, 02 August 2011 14:26

Eclipse User

Hi,

you "could". You could also adapt the name provider, to return only the "simple" name for a TypeDef (but what if the user wanted to use the TypeDef with the same name which is currently is *not* linked, as the other one was put into the scope later). You could also ...
The question is, what is the best solution for your use case. And I can't answer that. Generally, qualified names and name space imports are quite a good idea. Implicit imports of name spaces are possible (analogous to java.lang.*) and could be quite easily be implemented for your default types model file, the hook being the ImportNormalizers in the ImportedNamespaceAwareLocalScopeProvider.

Alex

Re: trouble defining cross-references in grammar [message #708402 is a reply to message #708358]

Tue, 02 August 2011 15:24

Eclipse User

Thank you very much Alex! I really appreciate the quick replies.

In my case, the dsl cannot be altered. dsl is right (or wrong) in its own way. I m just trying to slide an editor implementation for it.

If the editor understands that a typedef is defined in some other file and tries to find it out among all available files (in a project) and links it - that'd be great. Dsl would not have qualified name of the typedef specified where ever it is used.

With all data just one dsl file, i have everything out of the box. But with stuff split across files, linking them is a problem with just names used (and not fully qualified names). Will take a look at ImportNormalizers.

thanks,
Chetan

Re: trouble defining cross-references in grammar [message #709022 is a reply to message #708402]

Wed, 03 August 2011 08:09

Eclipse User

Hi,

have you tried binding your own IQualifiedNameProvider (extending the DefaultDeclarative-one for example). For TypeDefs you could return the simple name, rather than the qualified one.

Alex

Re: trouble defining cross-references in grammar [message #709405 is a reply to message #709022]

Wed, 03 August 2011 18:16

Eclipse User

That worked like a charm. Thanks Alexander!
As a consequence i think typedef names have to be unique across files under a project right ?

+ Chetan

Re: trouble defining cross-references in grammar [message #709677 is a reply to message #709405]

Thu, 04 August 2011 03:10

Eclipse User

Hi,

uniqueness is indeed the problem. It may not even be sufficient if the names are unique within the project. Cross referencing based on namespace imports (as is the default with Xtext) uses an index of referrable elements. As a very rough first approximation, think of the index of a flat structue holding a name to object mapping (with some additional type information). The same name might be used multiple times, even over different projects.
As a consequence, an object you might not expect might be linked. Overriding the qualified name method is only a first brute force workaround for linking something (when not being allowed to use qualified names and explicit importing of a namespace). Actually, one would have to investigate which component(s) to customise in order to get the linking working correctly for you. But this is somewhat beyond the scope of this forum.

Alex

Previous Topic:	(no subject)
Next Topic:	Scopes - Get assignment of parent element.

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 19 22:10:50 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter