Building blocks of apps built with structrAnatomy of a Structr App
This chapter answers the following questions:
The building blocks
A Structr app has a data model, a user interface, and processes that implement the business logic of the application. Together with pre-configured building blocks to reduce the need for boilerplate code, this is what makes an application:
- dynamic HTML pages
- data objects with attributes, and relationships between them
- object methods, flows or scripts
The user interface of a Structr App consists of Structr pages that are served by the built-in HTTP server (Jetty) under a specific URL. To access the application, you simply point your browser to the location of your Structr server, which is usually at http://localhost:8082/structr if Structr is running.
How do I build the user interface?
What is a page?
A Structr page is a tree-like structure of nested HTML elements, stored in the graph database, so the representation in the database corresponds exactly to the structure of the HTML output. In the rendering process, a page behaves like a declarative “program” that combines context information, access control and script expressions to create a dynamic HTML document.
The Data Model controls how data is stored in the database, which fields are present in the REST endpoints, how the REST endpoints behave, and much more. The data model contains all information about the data types (or classes), their properties and how the objects are related, as well as their methods.
How does it work?
Like all other application components, the data model is stored in the graph database and can be modified and extended at any time. After the system has been started or when changes have been made, Structr translates the schema entities into Java source code which is then compiled into Java classes that implement the functionality of the application.
What about data validation?
For each data type you can specify simple constraints based on attribute values (e.g. mandatory fields), detailed consistency checks and lifecycle methods that trigger event-driven processes (e.g. send an e-mail when a document is available for review) or automated workflows (BPMN).
Based on the schema details, Structr validates the integrity and structure of the data in the system when data is sent or received through REST endpoints. Structr generates meaningful semantic error messages, e.g. if constraints are violated or the input does not comply to the integrity and structure rules defined for a certain data type.
The third option to implement logic is to use a global schema method, especially when the logic is not bound to a specific type. Global schema methods can be called via REST using a special maintenance endpoint, scheduled for execution with a cron-like syntax or called from any scripting envrionment using the call() or call_privileged() functions.
Structr provides integrated multi-level access control for all parts of the application based on user and group objects. Both the access to the data and the representation of individual areas of the web application can be controlled separately with different security models.
Access to the REST endpoints can even be controlled for each HTTP verb separately.
Accessing the Data
Structr automatically creates REST endpoints from the data model that allow you to read and write data as JSON documents. You can send a JSON document to an endpoint, and Structr automatically creates the corresponding object structure in the database, based on the schema definition in the data model. This works in both directions, so Structr is essentially a document database extension on a graph database.
Various interfaces are available for integrating a Structr application into a company’s IT landscape, ranging from data import tools for RDF, CSV, XML and SQL to interactive technologies such as SSH and FTP to automated processing of mass data via the REST interface. In addition, ActiveDirectory support exists, and it is also possible to connect e-mail mailboxes via SMTP.