Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Content assist behavior in embedded xtext ocl editor
Content assist behavior in embedded xtext ocl editor [message #1032748] Wed, 03 April 2013 11:42 Go to next message
Guillaume Hillairet is currently offline Guillaume HillairetFriend
Messages: 83
Registered: July 2009
Member
Hi,

I am currently trying to implement an embedded ocl editor to be
included in the GMF tooling project to support edition of OCL
constraints.

I have been looking at a solution based on the essential ocl xtext
editor available in the console example. The behavior during content
assist seems odd, as it seems the context is not changing while typing.

For example in the xtext console example, if I start with as context an
EClass and write:

self.eAllAttributes->collect(e | e.) <- context lost

At this point the content assist seems to think e is an EClass as it
proposes solutions for it and not for an EAttribute.

If I start to write eType for example, the content assist start to
propose it to me, but then when I reach the dot, the context is lost
again.

self.eAllAttributes->collect(e | e.eType. ) <- context lost

Is it a current limitation or am I doing something wrong?

BRs,
Guillaume
Re: Content assist behavior in embedded xtext ocl editor [message #1032771 is a reply to message #1032748] Wed, 03 April 2013 12:15 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4151
Registered: July 2009
Senior Member
Hi

You might want to look at
org.eclipse.papyrus.uml.textedit.constraintwithessentialocl.xtext for an
example of the re-use.

Poor context assist following navigation operator seems to be an Xtext
feature. I asked a question on the TMF newsgroup and Sebastian seems to
suggest that I need to write some tacky code to correct the considered
options. Not high on my priority list at present. I don't like writing
code that will probably go wrong within 12 months.

I don't understand your example since you seem it is not clear where the
cursor is. It is helpful to use "@" in such examples.

Regards

Ed Willink


On 03/04/2013 12:42, Guillaume Hillairet wrote:
> Hi,
>
> I am currently trying to implement an embedded ocl editor to be
> included in the GMF tooling project to support edition of OCL
> constraints.
>
> I have been looking at a solution based on the essential ocl xtext
> editor available in the console example. The behavior during content
> assist seems odd, as it seems the context is not changing while typing.
>
> For example in the xtext console example, if I start with as context
> an EClass and write:
>
> self.eAllAttributes->collect(e | e.) <- context lost
>
> At this point the content assist seems to think e is an EClass as it
> proposes solutions for it and not for an EAttribute.
>
> If I start to write eType for example, the content assist start to
> propose it to me, but then when I reach the dot, the context is lost
> again.
>
> self.eAllAttributes->collect(e | e.eType. ) <- context lost
>
> Is it a current limitation or am I doing something wrong?
>
> BRs,
> Guillaume
>
Re: Content assist behavior in embedded xtext ocl editor [message #1032790 is a reply to message #1032771] Wed, 03 April 2013 12:35 Go to previous message
Guillaume Hillairet is currently offline Guillaume HillairetFriend
Messages: 83
Registered: July 2009
Member
Ed,

Thanks for the answer, I will take a look at the papyrus implementation.

> I don't understand your example since you seem it is not clear where
> the cursor is. It is helpful to use "@" in such examples.

Sorry for that, the cursors are supposed to be at the last dot.

>> self.eAllAttributes->collect(e | e.@)
>> self.eAllAttributes->collect(e | e.eType.@ )

BRs,
Guillaume

On 2013-04-03 14:15:00 +0200, Ed Willink said:

> Hi
>
> You might want to look at
> org.eclipse.papyrus.uml.textedit.constraintwithessentialocl.xtext for
> an example of the re-use.
>
> Poor context assist following navigation operator seems to be an Xtext
> feature. I asked a question on the TMF newsgroup and Sebastian seems to
> suggest that I need to write some tacky code to correct the considered
> options. Not high on my priority list at present. I don't like writing
> code that will probably go wrong within 12 months.
>
> I don't understand your example since you seem it is not clear where
> the cursor is. It is helpful to use "@" in such examples.
>
> Regards
>
> Ed Willink
>
>
> On 03/04/2013 12:42, Guillaume Hillairet wrote:
>> Hi,
>>
>> I am currently trying to implement an embedded ocl editor to be
>> included in the GMF tooling project to support edition of OCL
>> constraints.
>>
>> I have been looking at a solution based on the essential ocl xtext
>> editor available in the console example. The behavior during content
>> assist seems odd, as it seems the context is not changing while typing.
>>
>> For example in the xtext console example, if I start with as context an
>> EClass and write:
>>
>> self.eAllAttributes->collect(e | e.) <- context lost
>>
>> At this point the content assist seems to think e is an EClass as it
>> proposes solutions for it and not for an EAttribute.
>>
>> If I start to write eType for example, the content assist start to
>> propose it to me, but then when I reach the dot, the context is lost
>> again.
>>
>> self.eAllAttributes->collect(e | e.eType. ) <- context lost
>>
>> Is it a current limitation or am I doing something wrong?
>>
>> BRs,
>> Guillaume
Previous Topic:[OCLinEcore] Generating OCLinEcoreEObjectValidator supertype for the validator
Next Topic:[EMF/OCL/CDO] Accessing EClass with embedded OCL - problems under certain circumstances
Goto Forum:
  


Current Time: Mon Nov 24 01:24:41 GMT 2014

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

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