In 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 ReadingOne of my favorite features of Xtext is the ability to have context dependant FQNs. One application of the feature is the this keyword, which is used to refer to the current instance in languages like Java. The full code for this example can be found here. The basic block language We are using the same block langague that we used in a previous tip.
Continue ReadingSometimes it happens that you have an Xtext DSL that needs generate code to be consumed by another DSL. We can see an example of the need in the question in the Eclipse Forums. This is especially a problem when you use maven to build your projects. There is a simple solution for that.
Continue Reading