Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 285999

Summary:	[serializer] error in DefaultLinkingService#getLinkText()
Product:	[Modeling] TMF	Reporter:	Knut Wannheden <knut.wannheden>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	CLOSED FIXED	QA Contact:
Severity:	major
Priority:	P3	CC:	moritz.eysholdt, stephane, sven.efftinge
Version:	0.7.1	Flags:	sven.efftinge: helios+
Target Milestone:	M3
Hardware:	All
OS:	All
Whiteboard:

Description Knut Wannheden

2009-08-07 09:55:31 EDT

There is a problem with how DefaultLinkingService#getLinkText() is implemented: The implementation assumes that the "link rule" of the cross reference corresponding to the link to the link is of type String. I.e. an object parsed by a parser rule containing a fragment as follows cannot be serialized: foo=[Foo|INT].

The reason is quite simple: DefaultLinkingService#getLinkText() first determines the "unconverted" link text using the scope provider (it determines the name of the scoped element corresponding to the linked object). Then it tries to apply the value converter's toString() conversion on this. The "unconverted" link text is of course always a string (as it's the scoped element's name) but the value converter may be of any other data type (EInt in the example), so this second step will fail in the described example.

The clean solution is probably to provide some kind of service which handles the conversion between the datatype object and the link text (in a given context) and of course back again.

Alternatively (a simpler approach) DefaultLinkingService#getLinkText() could reverse its strategy: I.e. first try to find the link text in the context object's parse tree (this is the current fallback strategy). As a fallback (if the parse tree is not available) it could throw a runtime exception instructing the developer to override the DefaultLinkingService.

Comment 1 Knut Wannheden

2009-08-26 02:01:07 EDT

There is the same problem in content assist: See AbstractJavaBasedContentProposalProvider.DefaultProposalCreator#apply(IScopedElement).

I think it would be better to allow the definition of a link text <-> parse text conversion than a link text <-> datatype object conversion. Should this conversion be the responsibility of the linking service or a new service?

The alternative simpler approach probably *also* needs to be implemented. At least as getLinkText() is used by the serializer. Otherwise the link text won't be preserved if it isn't the "default" link text (i.e. name of first scoped element in the scope corresponding to the given object).

Any thoughts on this?

Comment 2 Moritz Eysholdt

2009-08-26 03:39:23 EDT

The if LinkingServerice.getLinkText() would return a datatype (instead of text), the serializer could use the ValueConverter to create the textual representation.

In case the cross reference is unresolved, this would shift the responsibility to reconstruct the textual representation from the node model from the LinkingService to the ValueConverter.

Comment 3 Knut Wannheden

2009-08-26 04:07:28 EDT

(In reply to comment #2)
> The if LinkingServerice.getLinkText() would return a datatype (instead of
> text), the serializer could use the ValueConverter to create the textual
> representation.
> 

This would require the LinkingService to apply a link text -> datatype conversion. This is typically not the same as the parse text -> datatype conversion performed by the ValueConverter (e.g. an ID may have a leading caret as parse text, but not as link text).

> In case the cross reference is unresolved, this would shift the responsibility
> to reconstruct the textual representation from the node model from the
> LinkingService to the ValueConverter.
> 

I don't quite see how unresolved cross references are different. If the LinkingService is to return a datatype, as you suggest, it would have to apply ValueConverter#toValue() on the node model (which then must exist).

However, also for resolved cross references I think the LinkingService should first try to extract the link text from the node model, as this result may differ from what the ScopeProvider yields.

Comment 4 Knut Wannheden

2009-08-27 08:30:27 EDT

Reported problem with preservation of "default" link text (see comment #1) as bug #287813.

This bug now only covers the problem with the conversion between parse text and link text.

Comment 5 Sven Efftinge

2009-11-10 00:37:06 EST

In cross references it is no longer allowed to use other than EString returning rules.

Comment 6 Karsten Thoms

2017-09-19 16:16:29 EDT

Closing bug which were set to RESOLVED before Eclipse Neon.0.