Basic Building Blocks
Pages, layouts, and partials
Pages are the most essential components of our platform, that define content displayed at a given path. Each page is represented by a single file with a liquid extension.
Layouts are Liquid views that store code that would normally repeat on a lot of pages and is surrounding page content (e.g. header, footer). Without layouts, pages would share a lot of duplicated code, and changing anything would become a very time consuming and error prone process. You can create as many layouts as you need, and decide which page uses which layout.
Partials (partial templates) allow you to easily organize and reuse your code by extracting pieces of code to their own files. They help you improve code readability and follow the principle of DRY (Don’t Repeat Yourself). You can parameterize partials and use them in various places, e.g. layouts, pages, Authorization Policies, Form Configurations.
Form Configurations are the main tool for rendering forms, persisting data, and sending notifications (email/SMS/API) in a secure and customizable way.
They give you full control when defining:
- which fields for a defined resource can be persisted
- what authorization rules apply to be able to submit the form (i.e. if you want to edit a comment, you might want to specify that only the creator or the administrator is able to do it)
- what should happen when the form is submitted successfully (i.e. without validation errors), e.g. send an email/SMS notifications or API call to a third party system
- where the user should be redirected
On top of that, you can define callbacks (either synchronous or asynchronous) for further modifications to the system using GraphQL mutations. For example, you can define a signup form that creates User records, and if the user input is valid, also creates a few sample products for them, so that they don’t have to start from scratch.
Users, User Profiles
Users are accounts that any of your users can have. Users are identified by their unique email addresses.
User Profiles are roles in the marketplace. Each User Profile can be associated with any number of Properties and Custom Model Types. All users are assigned a User Profile named Default. The difference between User Profile and Custom Model Type is that each user can have maximum one profile of a given name (but can have many different profiles), whereas they can have many custom models with the same name. From a practical perspective, it is very simple to create
upsert operation on UserProfile (i.e. create user profile, or if it exists, update it)
Properties and Custom Models
Custom Model Types have multiple use cases. Think of them as a custom DB table, which allows you to build highly customized features. Use them to group Properties, and allow the user to provide multiple values for each of them.
Properties are fields that you attach to a User Profile, Transactable, Custom Model Type, etc. Think of them as a custom DB columns (though complex types, like files, photos and addresses should be treated as separate DB tables). We also provide some Properties to jumpstart your development.
Authorization Policies allow you to restrict access to forms and pages in a flexible way. Each form or page can have multiple policies attached to it.
Each policy is parsed using Liquid, and the system checks them in order of their appearance in the code. Depending on policy configuration, it redirects the user to a URL provided by the developer if the condition is not met or renders error status, for example 403. You can also add a flash message for the user who failed authorization.
You can use platformOS to build sites in any language, and each site can have multiple language versions. Translations are yml files used for multilingual sites but also used to define date formats, flash messages or system-wide default error messages like "can't be blank".