In this workshop, you will learn how to use Xtext to build a language server for your domain-specific language (DSL). The workshop will start with a brief introduction to the most important core principals of Xtext. After the baseline is set, attendees will learn about the language server protocol and how to deploy and use your Xtext languages as a language server. We will offer different platforms to run your developed language server, like VSCode, Eclipse LSP4E or the new Theia project. Additional advanced topics like extending the protocol will be covered as well.
These days implementing code generators has become quite easy.
However, building professional tools supporting you in
- navigating back and forth between the sources and the generated text,
- running and debugging the source models instead of the generated artifacts, and
- transferring changes in the text back to the sources
is a much more challenging task, but also an interesting one.
In Xtext's grammar language syntax and structure of models are defined at a single location in a very concise way. The nesting structure and the references between objects are expressed which goes beyond plain abstract syntax trees. By just pointing to a type of an object, we describe the shape of a syntax graph. But the grammar alone has no meaning to describe the visibility rules inside of a resource or across resource boundaries. Therefore Xtext has a concept of scopes that are modeled as a chain of responsibility.
Financial markets run on complex algorithms. The industry uses several protocols to describe how their systems are expected to communicate with others - effectively, describing their APIs. One such protocol is FIX (Financial Information eXchange) - widely used for quite some time. Financial services firms (e.g. exchanges, hedge funds and investment banks) share such specifications with their counterparts to allow them to connect to their systems. The protocol specification is relatively vague and informal - at AI, we’re changing this.
A model can be represented graphically and textually. While text is able to carry more detailed information, a diagram highlights the relationship between elements much better. In the end, a good tool should combine both, and use each notation where it suits best.
Embedding support for expressions into Xtext based languages has become easy when Xbase is chosen as base language. However, deriving a language from Xbase implies the usage of a Java based type system with dependencies on JDT. For language implementations that need to be independent from Java or that should have a different type system it is required to embed an own expression language.
EMF Parsley is a GUI renderer built on top of EMF that allows developers to quickly develop User Interfaces. The main goal of the Project is to provide an easy way to build complex applications, hiding some boring details, with simple and powerful APIs. EMF Parsley in fact provides some built-in components like Trees, Tables and Forms that can be easily mashed up and customized.
Domain-specific languages implemented with Xtext have proven to be powerful in many areas ranging from requirements specifications to programming languages. One key factor to success is the textual representation of the model which eases creation, maintainance and especially merging. Nevertheless, at some point a graphical representation simplifies the communication by giving a broader overview of the modeled elements.
The formatter is one of the favourite IDE features of many developers. Always having a consistent code style, never having to worry about tabs, spaces, indentation or alignment is a tremendous help. But have you ever wondered how a formatter works?
With release 2.9, Xtext introduced the world to their new formatter2 API. It allows a formatter to access the text and the node model, as well as the AST. This allows the formatter to have a better understanding of the context, which in turn enables complicated conditional and pattern-aware code formatting.