Showing items from Language Engineering

Xtext Tip: How to change the default delimiter of your FQNs

In a previous tip I showed how to add FQN support to your Xtext DSL. In this tip, we are going to customize our FQN to have a different separator. The full code for this example can be found here.

The basic block language

I am using the block language of the previous tip, but this time we are using the characters -> as separator

block Block1 {
	
	field field1
	field field2

	block SubBlock {
		field field2
	}
	alias field3 aliases field2

}
block Block2 {
	alias field1 aliases Block1->SubBlock->field2 // this is an FQN with a -> as separator
}

Customize the FQN separator

First we change the grammar. The new grammar looks like this:

Continue Reading

Xtext Tip: How to use fully qualified names in your language

Xtext allows to easily add support for fully qualified names in your language. The full code for this example can be found here.

The basic block language

To illustrate this feature I will use a simple language to represent blocks. Each block has a name and can contain three members:

  • Fields, which are basically a name,
  • Blocks, which are blocks contained in another block
  • Aliases, which allow to give another name to another member

This is an example of our block language:

Continue Reading

Xtext Tip: Use Java instead of Xtend

Xtend is a wonderful language. It is specially practical when traversing ASTs and it is the best option to generate code. However, it is “is no longer the Java 17 of today”, as Christian Dietrich (one of Xtext maintainers) put it in this thread.

Hence, the recommended best practices for Xtend as of today are:

  • Use Xtend as a thin code generation layer.
  • Use Java for the rest of the logic.
  • Migrate Xtend code to Java whenever possible.
  • Set the code generators in the MWE file to generate Java stubs instead of Xtend (newer versions of Xtext do this by default.)

The configurations in the MWE file are the following:

Continue Reading

Why do companies build custom low-code tools?

In this post I explore some some common reasons that justify the effort of creating a custom low-code tool.

Sell it as a service

There are several low-code startups that are providing app generation services for different niches. There are offers like website generators, mobile app generators, landing pages, generators, internal app generators, and others. In those cases, the custom app generator becomes the service of a company. Since the core of the business is providing the low-code solution, it is developed in-house and tailored to the needs of the clients, which are usually a predefined segment. Examples of this approach range from tools as simple as Leadpages to complex app creation frameworks like Mendix.

Continue Reading

Should a company use a low code solution or an MDE tool?

When researching low-code and MDE software, I realized that the former is marketing itself as a solution; while the latter as as a tool. Solutions are aimed at business people, who have problem to solve. Tools are marketed to engineers/developers who have a solution to build.

The users of a solution, usually do not care about how it works or is implemented, as long as it solves the problem. However, the those of a tool are interested it maintaining the solutions they built using it.

Continue Reading