OutSystems Language VS OutSystems Model
This is the first post of a series about OutSystems Model.
But…
What is the OutSystem Model?
Abstraction Layers equals Speed
Looking at programming languages, we’ve been adding abstraction layers to speed the delivery of new products for a few decades now. Assembly and even raw C have become more rare and chosen for specific use cases where resources are limited, performance is key or critical systems. Abstraction layers bring, amongst other benefits (like ease of maintenance), speed. Speed to deliver. By abstracting developers from things like memory management, it allows them to focus on solving the real problem.
Even if you look at other areas, abstraction layers are everywhere (like cloud to abstract all the infrastructure hurdles).
The OutSystems Language — A visual abstraction layer
OutSystems adds a visual abstraction layer on top of text based programming languages, namely C#. The example below illustrates this with a very basic example. When using an “if” element in OutSystems, it will get translated into an “if” in C#, which will then be compiled to Intermediate Language and so on.
The above happens when you publish your application — OutSystems generates C# code that then gets compiled. But what happens when you Save? How do we store what you are actually doing in ODC Studio?
Materializing the language — The Model
The Model is the concrete representation for the OutSystems Language. It is this representation that is manipulated by the OutSystems platform components, like ODC Studio. Our Models have an in-memory representation (as C# class instances) and an xml-based persistent representation. Lets look at how that action gets stored in this xml-based representation.
You can see that there’s lots of information. The name of the Server Action, the modification dates, a hash, the parameters it expects. This is just a small piece that gets stored in the OML (OutSystems Model Language).
The OML is a compressed file composed of several fragments. The above section is part of a fragment called UserActions.xml. There are dozens of fragments for different purposes.
All these fragments contain the OutSystems Model.
Caveats
You might be asking why xml. Mainly because xml is very descriptive and we need that for such a complex/expressive model. The other reason is that when we built this 20 years ago, there were not that many good options.
Another question that has appeared a couple of times in OutSystems Forums (Examples like this and this to integrate with CI/CD — Code analysis) is: why can’t we manipulate the model directly? Why can we only use the Language itself in IDEs and not manipulate the Model directly?
The main reason is that it would be very hard to manipulate this XML directly. Even with validators, XLSTs or similar, it would not be a good experience. Why not a Model as a Service? Well, that’s the topic for the next episode. Stay tuned.
