Eclipse Community Forums: TMF (Xtext) » [Xtext2] Extending XbaseCompiler

Home

Home » Modeling » TMF (Xtext) » [Xtext2] Extending XbaseCompiler(How to access ImportManager?)

[Xtext2] Extending XbaseCompiler [message #685769]

Sun, 19 June 2011 14:40

Eclipse User

Hi,

I've added an own literal in the domain model example grammer like this:

XLiteral returns XExpression
	: XClosure
	| XBooleanLiteral
	| XIntLiteral
	| XNullLiteral
	| XStringLiteral
	| XTypeLiteral
	// own literals
	| XDateLiteral

;

XDateLiteral : value = STRING;

Now I want to create some code in the generated entity class and therefore I need to implement the _toJavaExpression method in the DomainmodelComplier, right?
Something similar to this:

	public void _toJavaExpression(XDateLiteral lit, IAppendable b) {
		b.append("new ");
		b.append("java.text.SimpleDateFormat");
		b.append("( \"").append(F_DATE).append("\" ).parse( \"").append(lit.getValue()).append("\" )");
	}

(It is not really correct code as I took out some code to simplify the example)

The question is, how can I add the java.text.SimpleDateFormat to the ImportManager?
The API of IAppendable offers no access to it!

Thank,
Ingo Meyer

Re: [Xtext2] Extending XbaseCompiler [message #685773 is a reply to message #685769]

Sun, 19 June 2011 15:22

Eclipse User

Hi,

i guess you should not add something to the import manager but rather add the ref to the appendable

public void _toJavaExpression(XDateLiteral lit, IAppendable b) {
		b.append("new ");
		b.append(getTypeReferences().getTypeForName(SimpleDateFormat.class, lit));
		b.append("( \"").append(F_DATE).append("\" ).parse( \"").append(lit.getValue()).append("\" )");
	}

but i am not quite sure if this is the correct way to aquire the type.

~Christian

[Updated on: Sun, 19 June 2011 15:29] by Moderator

Re: [Xtext2] Extending XbaseCompiler [message #685793 is a reply to message #685773]

Mon, 20 June 2011 02:40

Eclipse User

Thanks again Christian,

it looks good.
And there even is another method taking a String in case you don't have the class in the classpath.

~Ingo

Re: [Xtext2] Extending XbaseCompiler [message #685805 is a reply to message #685793]

Mon, 20 June 2011 04:49

Eclipse User

Hi,

while playing further, I noticed that the getTypeForName() method loads the given class via the ResourceSet of the given context EObject ("lit" in the example).
This means I can just use classes which are in the ecore model of xbase!?
How can I use a own class then?

	public void _toJavaExpression(
			XDateLiteral lit,
			IAppendable b )
	{
		b.append( "new " );
		b.append( getTypeReferences().getTypeForName( com.mycompany.CalendarHelper.class, lit ) );
		b.append( "( \"" ).append( F_UTC_DATETIME_yMd_HmsSZ ).append( "\" ).parse( \"" ).append( SDF_UTC_DATETIME_yMd_HmsSZ.format( lit.getValue() ) ).append( "\" )" );
	}

Can I somehow add this to the domain model example grammar?

Re: [Xtext2] Extending XbaseCompiler [message #685806 is a reply to message #685805]

Mon, 20 June 2011 04:57

Eclipse User

hmm, now it works...
Sorry, maybe forget about the last post

Re: [Xtext2] Extending XbaseCompiler [message #699860 is a reply to message #685806]

Fri, 22 July 2011 09:53

Eclipse User

While playing further with Xbase I experienced very heavy problems with the getTypeForName() method.
I can just get references to classes that are either in the classpath of the own Xtext project where the generator is started from, or which are associated in the Inferrer. is that right?

That leads to the question how to use other classes, expecially from fqn strings? In my opinion a M2T generator for java classes cannot be build when everything must exist in the classpath. Generally we just want to write strings in text files and in case of java classes and fqns we want them to appear in the import section, thats all.

Also one want to generate more then one java class from one model entity (e.g. interface and impl class). How can that be handled in the inferrer?
With a lot of entities in the model we may have dependencies from entity A and B in both directions. As far as I found out the JdtTypeProvider can just reference already existing java classes in scr-gen folder, cause it wants to load them with the JDT AST parser in the JdtBasedTypeFactory.createType. This is totally strange for me as I just want to generate text files and the generator should not depend on a specific ordering of the generated artifacts!

Isn't it possible that the org.eclipse.xtext.common.types.access.jdt.JdtTypeProvider will not throw a TypeNotFoundException in the findTypeByName method, but create a JvmGenericType on-the-fly then?

Can someone please explain me about the concept and what I am missing?

Many thanks,
Ingo

Re: [Xtext2] Extending XbaseCompiler [message #699889 is a reply to message #699860]

Fri, 22 July 2011 10:30

Eclipse User

Originally posted by:

On 22.07.11 15.53, Ingo Meyer wrote:
>
> Also one want to generate more then one java class from one model entity
> (e.g. interface and impl class). How can that be handled in the inferrer?
> With a lot of entities in the model we may have dependencies from entity
> A and B in both directions. As far as I found out the JdtTypeProvider
> can just reference already existing java classes in scr-gen folder,
> cause it wants to load them with the JDT AST parser in the
> JdtBasedTypeFactory.createType. This is totally strange for me as I just
> want to generate text files and the generator should not depend on a
> specific ordering of the generated artifacts!

My impression, from writing my own inferrer, is that the types will
either come from the classpath, i.e. existing classes indexed by Jdt, or
the set of classes inferred by you. In the latter case, you
create/instantiate the type/class descriptions yourself during the
inference, using an injected typesFactory, and when needed create
TypeReferences to them.

Hallvard

Re: [Xtext2] Extending XbaseCompiler [message #700638 is a reply to message #699889]

Sat, 23 July 2011 16:25

Eclipse User

If you want to use (you don'T need to) the ImportManager, you'll have to use JVMTypeReferences which reference JVMTypes. A JvmType is typically some class or interface on the classpath but can be created arbitrarily since they are in the end just EMF objects. Hallvard mentioned the type inference which is "just" producing JVMType instances from your DSL scripts.

So if you want to reference something which is not on the classpath you'll have to create the EMF objects somehow and make sure it is in the index.
Unfortunately getTypeForName() won't find manually created JVMTypes, since it is not looking at the index but directly at the classpath.

Re: [Xtext2] Extending XbaseCompiler [message #700667 is a reply to message #700638]

Sat, 23 July 2011 17:10

Eclipse User

Originally posted by:

On 23.07.11 22.25, Sven Efftinge wrote:
>
> So if you want to reference something which is not on the classpath
> you'll have to create the EMF objects somehow and make sure it is in the
> index.

I still wonder how to ensure that the manually created JvmTypes are in
the index. You wrote in a previous post that if you put them in the
resource's, at the top level, they would be indexed. What kind of
container should they (the JvmTypes) be collected in? An arbitrary
EObject? Would it also work if I put them in a separate resource in the
resourceSet (a bit cleaner)?

Hallvard

Previous Topic:	Domain model: member access
Next Topic:	Ecore to JvmTypes mapping

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 23 18:32:48 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter