Skip to main content



      Home
Home » Modeling » TMF (Xtext) » Accessing properties... the right way!
Accessing properties... the right way! [message #1722072] Tue, 02 February 2016 10:43 Go to next message
Eclipse UserFriend
Hello Christian,

I had some time to think yesterday about the mismatch between jvm type mapping vs model. I realize I focussed too much on the jvm aspect, especially since I control the whole model.
So I have come up with something that will probably be more to your liking and that will probably allow you to tell me exactly where I should be going.

Here is the relevant part of my new model :

Configurable:
	(abstract?='abstract')? 'configurable' name=ValidID ('extends' superType=JvmTypeReference)?
	'{'
		properties+=Property*
		assignments+=Assignment*   //////// new element
'}';
	
JavaType:
	type=JvmTypeReference
;

ConfigurableType:
	type=[Configurable]
;

Property:
        ///// I'm not even sure this is really needed, but I wanted a way to know if the type refers to a Configurable or a simple jvm type
	type=(JavaType|ConfigurableType) name=ValidID (
		defaultValue=DefaultValue | 
		block=MyXBlockExpression
	)? ;

Assignment returns xbase::XExpression:
	{MyAssignment} 'set' address=DotExpression op=('='|':=') expression=XLiteral
;

DotExpression returns Ref:
    PropertyRef ({DotExpression.ref=current}  "." tail=[Property])*
;

PropertyRef returns Ref:
	{PropertyRef} property=[Property]
;


I'm having some scoping questions.
Firstly, since the rule for assignments starts with 'set' it's clear that what follows is a DotExpression, which much start with a property reference.
OOTB, the properties don't auto complete, when I was expecting them to.

Secondly, I created a scope function like :

def IScope scope_DotExpression_tail(DotExpression exp, EReference ref) {
		val head = exp.ref
		switch(head) {
			PropertyRef: {
				val type = head.property.type
				switch (type) { 
					JavaType: {
						////// can i get the right scope here ? ie treat the property as a Configurable and get it's own properties ?
						IScope::NULLSCOPE 
					} 
				}
			}
			default: IScope::NULLSCOPE
		}
	}


Hope this will make it less obscure and more in line with standard XText scoping.

Thanks
Re: Accessing properties... the right way! [message #1722078 is a reply to message #1722072] Tue, 02 February 2016 11:16 Go to previous messageGo to next message
Eclipse UserFriend
Hi,

the Problem is: property=[Property] respectively tail=[Property]
if you Change this to tail=[ecore::EObject] you could put both properties and JvmFields into the scope (the jvmFields are the members of a JvmType
Re: Accessing properties... the right way! [message #1722079 is a reply to message #1722078] Tue, 02 February 2016 11:23 Go to previous messageGo to next message
Eclipse UserFriend
P.S: how does your scoping rule for PropertyRef look like
something like

scope_PropertyRef_property(Configurable ctx, Ereference r) {
}
Re: Accessing properties... the right way! [message #1722083 is a reply to message #1722078] Tue, 02 February 2016 11:33 Go to previous messageGo to next message
Eclipse UserFriend
I understand what you are saying about putting what I want in the scope. But I still don't know how i go from Property (if it's a Configurable) to its own list of Property.
configurable A  {
     String s1
}

Configurable B {
     A a1
    set  a1.s1 = 'some value'   ////// a1 is a property of type A which is declared to have its own properties 
}


Re: Accessing properties... the right way! [message #1722084 is a reply to message #1722083] Tue, 02 February 2016 11:39 Go to previous messageGo to next message
Eclipse UserFriend
i will see if i have time to look at it in the evening. can you share the complete grammar you use for this example? the MyXBlockExpression and DefaultValue seem missing
Re: Accessing properties... the right way! [message #1722086 is a reply to message #1722084] Tue, 02 February 2016 11:47 Go to previous messageGo to next message
Eclipse UserFriend
Sure. But since I can control the model fully, I am adding an attribute container with Attribute definitions. so then after I can refer by [Attribute] and that is fine with me (thanks to your enlighting discussion).
I just need to have a good example of scoping with which I can work and I'll move from there. So, just consider them done Smile

Danke.
Re: Accessing properties... the right way! [message #1722088 is a reply to message #1722086] Tue, 02 February 2016 11:57 Go to previous messageGo to next message
Eclipse UserFriend
Which xtext version?
Re: Accessing properties... the right way! [message #1722091 is a reply to message #1722088] Tue, 02 February 2016 12:15 Go to previous messageGo to next message
Eclipse UserFriend
2.9
Re: Accessing properties... the right way! [message #1722095 is a reply to message #1722091] Tue, 02 February 2016 13:02 Go to previous messageGo to next message
Eclipse UserFriend
hi,

using xtext 2.9 and or xbase the defaultdeclarativescopeprovider will not be your superclass. thus you have to implement the scope provider differently.
here is my blog example ported to xtext 2.9

class MyDslScopeProvider extends AbstractMyDslScopeProvider {

	override getScope(EObject context, EReference reference) {
		if (reference == MyDslPackage.Literals.DOT_EXPRESSION__TAIL) {
			if (context instanceof DotExpression) {
				val head = context.ref;
				switch (head) {
					EntityRef:
						return Scopes::scopeFor(head.entity.features)
					DotExpression: {
						val tail = head.tail
						switch (tail) {
							Attribute: return IScope::NULLSCOPE
							Reference: return Scopes::scopeFor(tail.type.features)
							default: return IScope::NULLSCOPE
						}
					}
					default:
						return IScope::NULLSCOPE
				}
			}
		}

		return super.getScope(context, reference)
	}

}


what this scope provider will no do
- dispatch method names like scope_Owner_referenceName
- walk up the containment tree of the content object. so if you want to do what you have to do this yourself.
so simply deal with context and reference to find out where you are and how the scope should look like
Re: Accessing properties... the right way! [message #1722097 is a reply to message #1722095] Tue, 02 February 2016 13:06 Go to previous messageGo to next message
Eclipse UserFriend
if you use xbase as well you have to additionally use
the workaround metioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=486420
Re: Accessing properties... the right way! [message #1722098 is a reply to message #1722095] Tue, 02 February 2016 13:06 Go to previous messageGo to next message
Eclipse UserFriend
Thanks for the upgrade to 2.9!
In your post, it's easy for you to get the features, because they are a member directly of the declaration (Entity).
But I cannot yet understand how I am supposed to do it with my Property, which can act as a Configurable or an normal jvm reference.

I want to be able to "cast" the Property into the Configurable to access it's collection of property. Can I do that from the head ref ? or do I need to go with ressources indices and the like ?
Re: Accessing properties... the right way! [message #1722099 is a reply to message #1722098] Tue, 02 February 2016 13:09 Go to previous messageGo to next message
Eclipse UserFriend
as i said:

what you can try: use tail=[ecore::EObject] in your case.
then you can have a look if object is a jvmField or a Property and if

- if a jvmfield follow its type, have a look if it is a declaredtype, inspect its members etc
- if it is a property, find out its jvm type and do the same

i recommand to use the debuger to see how the object actually look like and where you can find the information
Re: Accessing properties... the right way! [message #1722100 is a reply to message #1722099] Tue, 02 February 2016 13:12 Go to previous messageGo to next message
Eclipse UserFriend
I got lost in many levels of type properties with no usable EObjects in sight. I will explore some more.
Thanks for your help.
Re: Accessing properties... the right way! [message #1722102 is a reply to message #1722099] Tue, 02 February 2016 13:21 Go to previous messageGo to next message
Eclipse UserFriend
use this as starting point

Feature:
    JavaAttribute | Attribute | Reference
;

JavaAttribute:
    "jattr" name=ID ":" type=JvmTypeReference
;

DotExpression returns Ref:
    EntityRef ({DotExpression.ref=current}  "." tail=[ecore::EObject])*
;


class MyDslScopeProvider extends AbstractMyDslScopeProvider {

	override getScope(EObject context, EReference reference) {
		if (reference == MyDslPackage.Literals.DOT_EXPRESSION__TAIL) {
			if (context instanceof DotExpression) {
				val head = context.ref;
				switch (head) {
					EntityRef:
						return Scopes::scopeFor(head.entity.features)
					DotExpression: {
						val EObject tail = head.tail
						switch (tail) {
							JavaAttribute: {
								val jtype = tail.type.type
								if (jtype instanceof JvmGenericType) {
									return Scopes.scopeFor(jtype.members.filter(JvmField),[f|QualifiedName.create(f.simpleName)], IScope::NULLSCOPE)
								}
								return IScope::NULLSCOPE
							}
							JvmField: {
								val jtype = tail.type.type
								if (jtype instanceof JvmGenericType) {
									return Scopes.scopeFor(jtype.members.filter(JvmField),[f|QualifiedName.create(f.simpleName)], IScope::NULLSCOPE)
								}
								return IScope::NULLSCOPE
							}
							Attribute: return IScope::NULLSCOPE
							Reference: return Scopes::scopeFor(tail.type.features)
							default: return IScope::NULLSCOPE
						}
					}
					default:
						return IScope::NULLSCOPE
				}
			}
		}

		return super.getScope(context, reference)
	}

}
Re: Accessing properties... the right way! [message #1722104 is a reply to message #1722102] Tue, 02 February 2016 13:26 Go to previous messageGo to next message
Eclipse UserFriend
I was slowly getting there Smile But this example is enough for me to succeed I think, even if the structure is different, as my head will never be an entity reference but always a property.
Thanks Christian!
Re: Accessing properties... the right way! [message #1722105 is a reply to message #1722104] Tue, 02 February 2016 13:33 Go to previous messageGo to next message
Eclipse UserFriend
hey that is easy as well.

override getScope(EObject context, EReference reference) {
if (reference == MyDslPackage.Literals.PROPERTY_REF__REF) {
val Configurable configureable = if (context instanceof Configurable) context else EcoreUtil2.getContaineroftype(context, Configurable)
//return Scopes .... (ask configureable for props)
}
else if (reference == MyDslPackage.Literals.DOT_EXPRESSION__TAIL) {
Re: Accessing properties... the right way! [message #1722106 is a reply to message #1722105] Tue, 02 February 2016 13:40 Go to previous messageGo to next message
Eclipse UserFriend
Haha Smile I love the "easy" part Smile I find solace in the fact I'm competent as you in other areas than XText Very Happy
Re: Accessing properties... the right way! [message #1722108 is a reply to message #1722106] Tue, 02 February 2016 13:54 Go to previous messageGo to next message
Eclipse UserFriend
Yes I admit the scale of easy is very relative but compared to last weeks
stuff were a lot more left on the scale of hardness. Unfortunately there
not tons of scoping sample with the "new" default api
Re: Accessing properties... the right way! [message #1722110 is a reply to message #1722108] Tue, 02 February 2016 13:58 Go to previous messageGo to next message
Eclipse UserFriend
I have quite a bit of experience with "first gen" MDA, using simple text generators.
XText is much much more powerful, but I find that I have to break out of certain patterns I'm coming with.

Re: Accessing properties... the right way! [message #1722112 is a reply to message #1722110] Tue, 02 February 2016 14:15 Go to previous messageGo to next message
Eclipse UserFriend
Since the Property in my PropertyRef is property and not ref, I have this :
	if (reference == ModelDslPackage.Literals.PROPERTY_REF__PROPERTY) {
		val Configurable configurable = if (context instanceof Configurable) context else EcoreUtil2.getContainerOfType(context, Configurable)
		return Scopes::scopeFor(configurable.properties)
	}


I have tried a bunch of variations, being unsure about the scopesFor.
But there is something I must have not done yet, because I can debug and see the configurable.properties being correct with the collection of EObject matching Property objects.

but there is a null pointer exception in the linking


java.lang.NullPointerException
	at org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider$ReferenceProposalCreator.lookupCrossReference(AbstractJavaBasedContentProposalProvider.java:151)
	at org.eclipse.xtext.xbase.ui.contentassist.XbaseReferenceProposalCreator.lookupCrossReference(XbaseReferenceProposalCreator.java:134)
	at org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider$ReferenceProposalCreator.lookupCrossReference(AbstractJavaBasedContentProposalProvider.java:133)
	at org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider.lookupCrossReference(AbstractJavaBasedContentProposalProvider.java:261)
	at org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider.lookupCrossReference(AbstractJavaBasedContentProposalProvider.java:255)
	at org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider.lookupCrossReference(AbstractJavaBasedContentProposalProvider.java:233)
	at org.eclipse.xtext.xbase.ui.contentassist.XbaseProposalProvider.lookupCrossReference(XbaseProposalProvider.java:282)
	at com.netappsid.configurator.ui.contentassist.AbstractModelDslProposalProvider.completePropertyRef_Property(AbstractModelDslProposalProvider.java:104)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)


Ps. for the record, I have bound the scope provider in the runtime module, as per the bugzilla suggestion.

Please enlighten me once more Wink
Re: Accessing properties... the right way! [message #1722113 is a reply to message #1722112] Tue, 02 February 2016 14:19 Go to previous messageGo to next message
Eclipse UserFriend
Hi,

guess i need more from the trace

val Configurable configurable = if (context instanceof Configurable) context else EcoreUtil2.getContainerOfType(context, Configurable)
just was a guess since i dont have a complete grammar
maybe configurable is null
Re: Accessing properties... the right way! [message #1722115 is a reply to message #1722113] Tue, 02 February 2016 14:24 Go to previous messageGo to next message
Eclipse UserFriend
p.s.: do you have any adoptions in the proposal provider?
Re: Accessing properties... the right way! [message #1722117 is a reply to message #1722115] Tue, 02 February 2016 14:29 Go to previous messageGo to next message
Eclipse UserFriend
Configurable is not null, it is the right object and configurable.properties is a list of PropertyImpl EObjects. So it all looks good.
but here is the full grammar!

Model:
	'package' name=QualifiedName // base package
	importSection=XImportSection?
	elements+=PackageMember*;

PackageMember:
	(Configurable | Enum | DynamicEnum | Attributes);

Attributes:
	'attributes' name=ValidID
	'{'
		definitions+=AttributeDefinition*
	'}'
;

AttributeDefinition:
	type=JvmTypeReference name=ValidID
;
	
Configurable:
	(abstract?='abstract')? 'configurable' name=ValidID ('extends' superType=JvmTypeReference)?
	'{'
		properties+=Property*
		assignments+=Assignment*
		(initSection=XBlockExpression) ?
	'}';
	
JavaType:
	type=JvmTypeReference
;

ConfigurableType:
	type=[Configurable]
;

Property:
	type=(JavaType|ConfigurableType) name=ValidID (
		defaultValue=DefaultValue | 
		block=MyXBlockExpression
	)? ;

Assignment returns xbase::XExpression:
	{MyAssignment} 'set' address=DotExpression op=('='|':=') expression=XLiteral
;

DotExpression returns Ref:
    PropertyRef ({DotExpression.ref=current}  "." tail=[ecore::EObject])*
;

PropertyRef returns Ref:
	{PropertyRef} property=[Property]
;

DefaultValue:
	'=' defaultValue=XLiteral (unit=ID | unit=STRING)?;

Re: Accessing properties... the right way! [message #1722118 is a reply to message #1722117] Tue, 02 February 2016 14:30 Go to previous messageGo to next message
Eclipse UserFriend
There are no proposals, it crashes with the null pointer :

33972 [main] WARN org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider - Error in polymorphic dispatcher : null
java.lang.NullPointerException
at org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider$ReferenceProposalCreator.lookupCrossReference(AbstractJavaBasedContentProposalProvider.java:151)
at org.eclipse.xtext.xbase.ui.contentassist.XbaseReferenceProposalCreator.lookupCrossReference(XbaseReferenceProposalCreator.java:134)
at org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider$ReferenceProposalCreator.lookupCrossReference(AbstractJavaBasedContentProposalProvider.java:133)
at org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider.lookupCrossReference(AbstractJavaBasedContentProposalProvider.java:261)
at org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider.lookupCrossReference(AbstractJavaBasedContentProposalProvider.java:255)
at org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider.lookupCrossReference(AbstractJavaBasedContentProposalProvider.java:233)
at org.eclipse.xtext.xbase.ui.contentassist.XbaseProposalProvider.lookupCrossReference(XbaseProposalProvider.java:282)
at com.netappsid.configurator.ui.contentassist.AbstractModelDslProposalProvider.completePropertyRef_Property(AbstractModelDslProposalProvider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.eclipse.xtext.util.PolymorphicDispatcher.invoke(PolymorphicDispatcher.java:296)
at org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider.invokeMethod(AbstractJavaBasedContentProposalProvider.java:300)
at org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider.completeAssignment(AbstractJavaBasedContentProposalProvider.java:205)
at org.eclipse.xtext.ui.editor.contentassist.AbstractContentProposalProvider$DefaultContentAssistProcessorSwitch.caseAssignment(AbstractContentProposalProvider.java:66)
at org.eclipse.xtext.ui.editor.contentassist.AbstractContentProposalProvider$DefaultContentAssistProcessorSwitch.caseAssignment(AbstractContentProposalProvider.java:1)
at org.eclipse.xtext.util.XtextSwitch.doSwitch(XtextSwitch.java:144)
at org.eclipse.emf.ecore.util.Switch.doSwitch(Switch.java:53)
at org.eclipse.emf.ecore.util.Switch.doSwitch(Switch.java:69)
at org.eclipse.xtext.ui.editor.contentassist.AbstractContentProposalProvider$DefaultContentAssistProcessorSwitch.accept(AbstractContentProposalProvider.java:72)
at org.eclipse.xtext.ui.editor.contentassist.AbstractContentProposalProvider.createProposals(AbstractContentProposalProvider.java:110)
at org.eclipse.xtext.ui.editor.contentassist.AbstractJavaBasedContentProposalProvider.createProposals(AbstractJavaBasedContentProposalProvider.java:275)
at org.eclipse.xtext.ui.editor.contentassist.CompletionProposalComputer.exec(CompletionProposalComputer.java:52)
at org.eclipse.xtext.ui.editor.contentassist.CompletionProposalComputer.exec(CompletionProposalComputer.java:1)
at org.eclipse.xtext.resource.OutdatedStateManager.exec(OutdatedStateManager.java:121)
at org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.internalReadOnly(XtextDocument.java:520)
at org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.priorityReadOnly(XtextDocument.java:485)
at org.eclipse.xtext.ui.editor.model.XtextDocument.priorityReadOnly(XtextDocument.java:142)
at org.eclipse.xtext.ui.editor.contentassist.RepeatedContentAssistProcessor.computeCompletionProposals(RepeatedContentAssistProcessor.java:111)
at org.eclipse.xtext.ui.editor.contentassist.RepeatedContentAssistProcessor.computeCompletionProposals(RepeatedContentAssistProcessor.java:80)
at org.eclipse.jface.text.contentassist.ContentAssistant$5.run(ContentAssistant.java:1904)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:1902)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:573)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.access$16(CompletionProposalPopup.java:570)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup$2.run(CompletionProposalPopup.java:505)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:499)
at org.eclipse.jface.text.contentassist.ContentAssistant.showPossibleCompletions(ContentAssistant.java:1720)
at org.eclipse.jface.text.source.SourceViewer.doOperation(SourceViewer.java:967)
at org.eclipse.jface.text.source.projection.ProjectionViewer.doOperation(ProjectionViewer.java:1501)
at org.eclipse.ui.texteditor.ContentAssistAction$1.run(ContentAssistAction.java:82)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.texteditor.ContentAssistAction.run(ContentAssistAction.java:80)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:473)
at org.eclipse.jface.commands.ActionHandler.execute(ActionHandler.java:122)
at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90)
at sun.reflect.GeneratedMethodAccessor74.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56)
at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:252)
at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:234)
at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132)
at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:152)
at org.eclipse.core.commands.Command.executeWithChecks(Command.java:493)
at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:486)
at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.executeCommand(KeyBindingDispatcher.java:286)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.press(KeyBindingDispatcher.java:507)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.processKeyEvent(KeyBindingDispatcher.java:558)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.filterKeySequenceBindings(KeyBindingDispatcher.java:378)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher.access$0(KeyBindingDispatcher.java:324)
at org.eclipse.e4.ui.bindings.keys.KeyBindingDispatcher$KeyDownFilter.handleEvent(KeyBindingDispatcher.java:86)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.filterEvent(Display.java:1550)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1328)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1353)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1338)
at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:1365)
at org.eclipse.swt.widgets.Widget.gtk_key_press_event(Widget.java:763)
at org.eclipse.swt.widgets.Control.gtk_key_press_event(Control.java:3317)
at org.eclipse.swt.widgets.Composite.gtk_key_press_event(Composite.java:785)
at org.eclipse.swt.widgets.Widget.windowProc(Widget.java:1980)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:5590)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:4717)
at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method)
at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:9279)
at org.eclipse.swt.widgets.Display.eventProc(Display.java:1225)
at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method)
at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2425)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3428)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
at org.eclipse.equinox.launcher.Main.main(Main.java:1488)
Re: Accessing properties... the right way! [message #1722119 is a reply to message #1722117] Tue, 02 February 2016 14:32 Go to previous messageGo to next message
Eclipse UserFriend
the question is why is the filter null? can you debug why it is null?
the only thing could be a wired binding or overriding
getFeatureDescriptionPredicate(ContentAssistContext contentAssistContext)
Re: Accessing properties... the right way! [message #1722120 is a reply to message #1722119] Tue, 02 February 2016 14:32 Go to previous messageGo to next message
Eclipse UserFriend
I'm investigating thanks
Re: Accessing properties... the right way! [message #1722121 is a reply to message #1722120] Tue, 02 February 2016 14:36 Go to previous messageGo to next message
Eclipse UserFriend
Found the culprit. Remnants of the AbstractModelDslProposalProvider stuff we did for attributes.

The proposals are correct now. Thanks a lot Very Happy
Re: Accessing properties... the right way! [message #1722140 is a reply to message #1722121] Tue, 02 February 2016 21:31 Go to previous messageGo to next message
Eclipse UserFriend
OK! I've finally managed to do exactly what I thought of first. I am convinced it's the wrong way to do it though! But you will understand right away and you might propose something more direct. (something related to global scopes maybe?)

so first, the updated grammar:

DotExpression returns Ref:
    PropertyRef ({DotExpression.ref=current}  op=("."|"?."|":") tail=[Property])*
;


I don't need to use EObjects there, it's really a Property I want.

The scoper provider has been changed to : (fragment)

PropertyRef: {
						val propertyType = ref.property.type

						if (propertyType instanceof JavaType) {
							val innerType = propertyType.type.type

							val EObject rootElement = EcoreUtil2.getRootContainer(context);
							val configurables = EcoreUtil2.getAllContentsOfType(rootElement, Configurable);
							val configurable = configurables.findFirst [
								fullyQualifiedName.toString == innerType.identifier
							]

							if (configurable != null) {
								return Scopes.scopeFor(configurable.properties)
							}
						}
					}


as you can see, I take my property reference's type to match it to the Configurable object from the root, by qualified name.

Any suggestion how to do it more directly ? some ECore voodoo ? Wink

Thanks!
Re: Accessing properties... the right way! [message #1722143 is a reply to message #1722140] Wed, 03 February 2016 00:26 Go to previous messageGo to next message
Eclipse UserFriend
Maybe you can use ijvmmodelassociations to retrieve the source element a jvmelement was derived from originally. But i cannot say if this works in your case
Re: Accessing properties... the right way! [message #1722245 is a reply to message #1722143] Wed, 03 February 2016 10:25 Go to previous messageGo to next message
Eclipse UserFriend
Since there is a direct mapping between my object and a java class, the IJvmModelAssociations works exactly as it should and makes the code much simpler.

I'm almost done. Two questions arise:

1) What is the best way to scope inheritance? I have a reference to Configurable so I could manually get the Properties from the super classes and add them to the scope I'm creating. Is there a better way to do it ?

2) consider the following fragment:
Assignment returns xbase::XExpression:
	{MyAssignment} 'set' address=DotExpression (':' attribute=[AttributeDefinition])? op=('='|':=') expression=XLiteral
;


and scope provider

		if (reference == ModelDslPackage.Literals.MY_ASSIGNMENT__ATTRIBUTE) { 
			if (context instanceof MyAssignment) {
				// Build scope for all AttributeDefinition
			}
		}


I could go to the root object and get all instance of AttributeDefinition. But isn't this already stored somewhere ? Default global scoping for that kind of object?

Danke noch einmal Christian

Re: Accessing properties... the right way! [message #1722249 is a reply to message #1722245] Wed, 03 February 2016 10:34 Go to previous messageGo to next message
Eclipse UserFriend
delegateGetScope(ctx, reference) gives you access to the global scope.
Re: Accessing properties... the right way! [message #1722250 is a reply to message #1722249] Wed, 03 February 2016 10:35 Go to previous messageGo to next message
Eclipse UserFriend
p.s: what is the name of the attributes in the index (you can use navigate -> open model element dialog to query the index)
Re: Accessing properties... the right way! [message #1722256 is a reply to message #1722250] Wed, 03 February 2016 10:42 Go to previous messageGo to next message
Eclipse UserFriend
whoa! I didn't know about that yet!
The attributes have fully qualified names, with EClass AttributeDefinition

http://picpaste.com/Capture_du_2016-02-03_10-40-39-Vq4as7J6.png
Re: Accessing properties... the right way! [message #1722262 is a reply to message #1722256] Wed, 03 February 2016 11:06 Go to previous messageGo to next message
Eclipse UserFriend
A FQN is not serializable as ID thus you need simple names or
ref=[Thing|FQN]
Re: Accessing properties... the right way! [message #1722264 is a reply to message #1722262] Wed, 03 February 2016 11:20 Go to previous messageGo to next message
Eclipse UserFriend
I just want to get the list of all AttributeDefinition objects to create my scope.

What I could do with :
val EObject rootElement = EcoreUtil2.getRootContainer(context);
val attributes = EcoreUtil2.getAllContentsOfType(rootElement, AttributeDefinition);

Except I realize now that this will "not" give me AttributeDefinition coming from outside my current model.

May you point me in the right direction? Good examples of proper global scoping (cause I think this is what I need now)
Re: Accessing properties... the right way! [message #1722270 is a reply to message #1722264] Wed, 03 February 2016 11:41 Go to previous messageGo to next message
Eclipse UserFriend
Delegategetscope does exactly this
Re: Accessing properties... the right way! [message #1722277 is a reply to message #1722270] Wed, 03 February 2016 12:32 Go to previous messageGo to next message
Eclipse UserFriend
Then it means I have no clue how it works, because

if (reference == ModelDslPackage.Literals.MY_ASSIGNMENT__ATTRIBUTE) {
if (context instanceof MyAssignment) {
return delegateGetScope(context, reference)

doesn't do anything at all.

Can you tell me what the right parameters are to delegateGetScope? How do I specify context / reference meaning "AttributeDefinition" ?

Thanks
Re: Accessing properties... the right way! [message #1722280 is a reply to message #1722277] Wed, 03 February 2016 13:18 Go to previous messageGo to next message
Eclipse UserFriend
How does your changed grammar or name provider look like? Did you verify
the delegate method gets called?
Re: Accessing properties... the right way! [message #1722282 is a reply to message #1722280] Wed, 03 February 2016 13:46 Go to previous messageGo to next message
Eclipse UserFriend
The grammar fragment is in:
https://www.eclipse.org/forums/index.php?t=msg&th=1074397&goto=1722245&#msg_1722245

But, I think it's doing its job properly. The delegate gets called, and returns an ImportScope. Debugging shows an "importFrom" (SelectableBasedScope) inside that has all the actual attributes.

but if I return the delegateGetScope as my IScope, it doesn't propose anything.

maybe the call sequence is not the right one ?

in my DslScopeProvider:

if (reference == ModelDslPackage.Literals.MY_ASSIGNMENT__ATTRIBUTE) { 
	if (context instanceof MyAssignment) {
	 	return delegateGetScope(context, reference)  // context and reference come from the getScope method


The SelectableBasedScope debugger structure
SelectableBasedScope[com.client360.configuration.blinds.horizontal.BonjourAttributes.description, 
com.client360.configuration.blinds.horizontal.BonjourAttributes.visible, 
com.client360.configuration.blinds.horizontal.BonjourAttributes.readOnly, 
com.client360.configuration.blinds.horizontal.BonjourAttributes.position] 
-> SelectableBasedScope[] 
-> SelectableBasedScope[org.eclipse.xtext.builder.builderState.impl.EObjectDescriptionImpl@21bac1a8 (name: com.netappsid.configurator.attrs.MyAttributes.ADDEDATTRIBUTE, fragment: /0/@elements.0/@definitions.0)] -> NULLSCOPE


You can see the "local" ones first and the "ADDEDATTRIBUTE" is also present, but in a different structure.

Thanks
Re: Accessing properties... the right way! [message #1722283 is a reply to message #1722282] Wed, 03 February 2016 13:54 Go to previous messageGo to next message
Eclipse UserFriend
what i try to tell you for the last 10 posts is

(1) i asume the qualified names are com.netappsid.configurator.attrs.MyAttributes.ADDEDATTRIBUTE
(2) this is a qualified name and not a simplete name. thus the qualified name cannot be serialized by the ID lexer rule
(3) someReference=[Sometype] is short for someReference=[Sometype|ID] which means: Reference a SomeType and Parse a ID
(4) since the qualifed cannot be parsed as a id i cannot be serialized by id
=> you have to change either the indexing or adapt the grammar to parse QualifiedNames e.g. by using
someReference=[Sometype|QualifiedName] (asuming xbase defines qualifiedname)
Re: Accessing properties... the right way! [message #1722285 is a reply to message #1722283] Wed, 03 February 2016 13:58 Go to previous messageGo to next message
Eclipse UserFriend
Now it makes sense to me.
I hope you realize that to most of us, messages like :
Quote:
A FQN is not serializable as ID thus you need simple names or
ref=[Thing|FQN]


only make sense AFTER understanding the context.

The docs on the website are pretty thorough, but assume a lot of basic understanding of the internals. The examples are too simple, and the requirements to make something useful are too high.

But I sincerely appreciate your efforts, even when it seems that we are "resisting" your solutions. I venture to guess most of us just don't "get it" yet.

Re: Accessing properties... the right way! [message #1722286 is a reply to message #1722285] Wed, 03 February 2016 14:01 Go to previous messageGo to next message
Eclipse UserFriend
yes the documentation is very referency and not cookbooky. feel free to file enhancement requests. i am not a commit yet but just a power user
Re: Accessing properties... the right way! [message #1722290 is a reply to message #1722286] Wed, 03 February 2016 14:39 Go to previous messageGo to next message
Eclipse UserFriend
OK, I've done my homeworks and I think I understand a bit better.
My Scopes.scopeFor(configurable.properties) for example, is a SimpleScope object with the simple names referring to the properties. Which is what is shown in the proposal popup.
Now, the delegateGetScope returns objects with FQDN which is not presentable to the proposal popup. So you basically say, allow your grammar FQDN, which is not really an option for me, or replace it with a simple name.

That substitution happens somewhere I don't know. I tried creating a new scope using the parent as the source, but it just appends it so it's useless.

Where do I substitute the FDQN for it's simple name ?

Thanks
Re: Accessing properties... the right way! [message #1722292 is a reply to message #1722290] Wed, 03 February 2016 14:49 Go to previous messageGo to next message
Eclipse UserFriend
Xtext uses IQualifiedNameprovider in DefaultResourceDescrptionStrategy to
fill the index with the global scoping entries. So one option would be to
adapt your iqualifiednameprovider and give the attributes simple names
instead of qualified ones
Re: Accessing properties... the right way! [message #1722294 is a reply to message #1722292] Wed, 03 February 2016 15:16 Go to previous message
Eclipse UserFriend
OK, after some guess work on which super class, ie not DefaultDeclarativeQualifiedNameProvider but XbaseQualifiedNameProvider, I can say that it finally work exactly as you were implying.

thanks a lot for your help and patience.
Previous Topic:[solved] xtend helper to escapeHTML(string)
Next Topic:Hover provider for terminal rules
Goto Forum:
  


Current Time: Sun May 04 17:55:11 EDT 2025

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

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

Back to the top