| a question about linking [message #716963] |
Thu, 18 August 2011 21:34  |
 Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
Hi,
for various reasons I am doing my own linking in my puppet DSL
(Geppetto), and it works well except in one use case, and I have not yet
figured out how I can correct this.
Without going into any detail let's just say the code is something like:
define a
// and then refer to something that does not exist
exists ba
When I change ba to a in the editor it works, but if I correct the
problem by changing a to ba, the problem is not fixed until I save, or
perform some other edit that triggers linking.
When trying the same using two different files (in the same container),
it works the first time, but not if both files are in dirty state.
My code works as follows:
I record all "imported names" in a Resource adapter (i.e. everything
that is being referred to and everything that affected the decision to
pick a particular exported element). The adapter with imported names
gets updated each time the linker is invoked (and it iterates and links
everything). My linker is invoked from derived impl of
LazyLinker#afterModelLinked.
My override of ResourceDescription creates an aggregate Iterator over
the imported names (and those produced by the super class
DefaultResourceDescription) and return this as result of
#getImportedNames().
I have a QualifiedNamedProvider that provides names for the types of
elements that are exported.
I am a bit lost trying to figure out what is wrong and what I have
missed to provide.
So, concrete question: Where can I find the logic that deals with the
normal linking that takes place (in the case described above - i.e. a
text changed in editor event) had I used the build in support for
references?
Regards
- henrik
|
|
|
| Re: a question about linking [message #717406 is a reply to message #716963] |
Sat, 20 August 2011 12:16  |
Sebastian Zarnekow
Messages: 3118
Registered: July 2009 |
Senior Member |
|
|
Just for the sake of completeness: The described behavior was probably
caused by an outdated IResourceDescription instance that sneaked into
the custom linking logic.
Regards,
Sebastian
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
On 18.08.11 23:34, Henrik Lindberg wrote:
> Hi,
> for various reasons I am doing my own linking in my puppet DSL
> (Geppetto), and it works well except in one use case, and I have not yet
> figured out how I can correct this.
>
> Without going into any detail let's just say the code is something like:
>
> define a
> // and then refer to something that does not exist
> exists ba
>
> When I change ba to a in the editor it works, but if I correct the
> problem by changing a to ba, the problem is not fixed until I save, or
> perform some other edit that triggers linking.
>
> When trying the same using two different files (in the same container),
> it works the first time, but not if both files are in dirty state.
>
> My code works as follows:
>
> I record all "imported names" in a Resource adapter (i.e. everything
> that is being referred to and everything that affected the decision to
> pick a particular exported element). The adapter with imported names
> gets updated each time the linker is invoked (and it iterates and links
> everything). My linker is invoked from derived impl of
> LazyLinker#afterModelLinked.
>
> My override of ResourceDescription creates an aggregate Iterator over
> the imported names (and those produced by the super class
> DefaultResourceDescription) and return this as result of
> #getImportedNames().
>
> I have a QualifiedNamedProvider that provides names for the types of
> elements that are exported.
>
> I am a bit lost trying to figure out what is wrong and what I have
> missed to provide.
>
> So, concrete question: Where can I find the logic that deals with the
> normal linking that takes place (in the case described above - i.e. a
> text changed in editor event) had I used the build in support for
> references?
>
> Regards
> - henrik
>
>
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.36004 seconds
] 
Search
Help
Register
Login
Home
