In a previous post I showed how to use the import namespace feature of Xtext. This feature helps to easily implement java like imports. However, Xtext also supports imports more in a C-like style, i.e. imports where a whole file imported, and its definitions made available to the current file.
Continue ReadingIf you are into EMF modeling, you know that you can define custom operations and fields in EMF models. Xtext allows to make use of this feature in an elegant way. Let us start with the block language with a separate EMF metamodel from a previous tip. The full code for this example can be found here.
Continue ReadingIn a previous tip I showed how to migrate from a generated EMF model to a manually maintained one. Turning something automatic to manual sounds completely counter intuitive. We should automate more, not the contrary. However, there are some good reasons to do this. Let’s explore them: Separation of concerns I see the grammar is a presentation artifact.
Continue ReadingXtext is very good at inferring a metamodel from a grammar but it has its limitations. After reaching a certain complexity, I think it is important to decouple the grammar from the metamodel. This is allows to separate concerns: the metamodel becomes the “business model layer”, and the grammar becomes the “presentation layer”.
Continue ReadingIf you look at Xtext’s documentation here, there is a mention of the possibility of adding import name space support to your DSLs. This allows your DSL to have Java like imports. For example, in our block language, it should be possible to import the name space from another Block and then use in our alias.
Continue Reading