Catch up on parts one and two of the series: Getting started with the OutSystems Agile Platform and Learning the basics of the OutSystems Agile Platform.
The Agile Platform is composed of four major pieces: Service Studio, Integration Studio, Service Center, and the Agile Network. I spend nearly all of my time in Service Studio, which is where the application and data modeling occur, as well as application debugging. You can also publish your application to a server from Service Studio. While Service Studio is an IDE, it uses a paradigm that is very different from any IDE that I have ever used. This took some time for me to adjust to, but once I did, it became extraordinarily pleasant to take Rat Catcher from being an idea to a reality.
The three major functions in Service Studio are data modeling, process modeling, and screen design. The data modeling is similar to using a database designer in how it feels and functions. Most of the time, you will not need to use the full data modeling tool, you can just add entities and entity attributes directly in the eSpace tree. But if you need additional control (like rearranging the attributes or perhaps adding an index) a double-click on the entity brings up the full-fledged data modeler. You can attach metadata to an entity or attribute such as the label to use when displaying it on the screen. Service Studio is very smart too about using labels when you add an attribute to be displayed. If you follow the standard naming convention of Pascal case, when it generates a label (like table headers), it will show the different words in the label with a space between them. The best innovation here is that each entity’s identifying attribute becomes a data type all by itself. For example, the User entity’s “Id” attribute can be used by other entities (or variables) as type “UserIdentifier,” and when an attribute in another entity is of type “UserIdentifier,” a relationship is automatically made, and Service Studio enforces the typing quite well.
The Data Modeling Tool working with Rat Catcher’s “JOB_TASK” entity.
For processing modeling, the closest comparison is Visio. You are really just laying out various actions that need to be taken, whether it is to perform a query, update a variable, loop through a set of results, or conditional logic branching, and the relationships between these different actions. Each “workflow” is really an action by itself, and can be combined as needed. As a result, your work is instantly reusable. Indeed, you can easily copy/paste entire portions of the process into another action and, other than local variable and widget (on screen component) usage, it will work fine.
An example of processing modeling in Rat Catcher; this is the process for purchasing an account. As you can see, it is a cinch for someone not familiar with the project or even the tools to understand what is happening, which makes maintenance and debugging smooth and simple. (Click the image to enlarge.)
Designing screens is similar to other WYSIWYG tools. Unlike Eclipse or Visual Studio, you do not have access to the underlying HTML. That said, I have had little desire to get to the HTML, once I felt confident that the widgets were doing their jobs well. All of the design is controlled by CSS. The biggest weakness is actually the lack of a “master page” system (to use Visual Studio terminology) where pages can derive from a common template, and updates to the template cascade to the pages that use it. Using the screen editor is really a drag/drop operation. If you are inside a widget that is bound to a data source, you can just drag entity attributes from the eSpace tree into the widget, and the appropriate display will be created based on the attribute’s data type and the query. One of my favorite aspects of this is that pulling in an entity with a one-to-many relationship automatically creates a drop-down box, which is exactly what you want most of the time. This is where Service Studio’s data modeling really shines, because it drives so much of this ease of use.
Designing the Rat Catcher Account Purchase screen. (Click the image to enlarge.)
The biggest stumbling block for me was getting used to the idea that Service Studio simply does not involve writing code. The closest you get to code writing is laying out conditional statements. In the same vein, your entire data passing is done through data binding. For example, in Visual Studio, I might write code to set the Text property of a Label object to be the value retrieved from a form field component. In Service Studio, I would assign a local variable to bind to the form field, and then bind an Expression widget to that variable. As the form field changes, the variable automatically updates and so does the Expression widget’s value. Once I got used to this paradigm, it was very powerful for me.
One common pattern that I discovered with the data binding is to not bind widgets directly to query results and bind the widgets to a local variable instead. You use an Assign component in the process modeling to set the variable to the result of the query. This is a common and useful pattern because you can then easily repopulate the variable with data without rerunning the action that contained the initial query again. For screens that just populate a widget once, this is not needed. But if you want to use the AJAX functionality, particularly the “late load” component, AJAX table paging/sorting, or the popup editors, this is a mandatory pattern.
Within Service Studio, you can verify that your application will compile correctly. In addition, the TrueChange system lets you know in real-time when there will be a problem. TrueChange is also very smart about cascading changes throughout your application. For example, if you change a variable’s name, all references to it will automatically change as well. If a type changes, TrueChange will let you know if this has introduced errors. It also makes helpful optimization suggestions for you. When you are ready to deploy your application, it is a simple, one-click process. Debugging is just a matter of starting the debugger and setting a breakpoint; the debugger keystroke commands are the same as Visual Studio, which makes the experience intuitive for those coming from Visual Studio.
Overall, the Service Studio is a very simple tool to use. There is not a lot of clutter to it, other than a few of the less important parts of the toolbar. Once I got past the conceptual challenge of the pervasive data binding, I found its approach to application development to be just what I needed. For more advanced work, there is the Integration Studio, which will I look at in another article.
Disclosure of Justin’s industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.
Get weekly development tips in your inbox
Keep your developer skills sharp by signing up for TechRepublic’s free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!