Core Concepts
Learn about the App Builder's core concepts. These definitions will guide you throughout this documentation and your building process.
The App Builder provides users with the tools to easily build custom web applications to streamline business operations. Web pages are built using a variety of drag-and-drop elements, each with highly customizable settings, so you can build the most relevant app for your purpose.
An app is an application software that is stored on a remote server and runs in a web browser. They can be designed for a wide variety of use cases and functions.
Pages are just like a webpages of a website. An app is usually composed of several pages. For example, it can contain a sign-in page, home page, and profile page.
- 1.Basic: These are essential elements such as buttons, text, images, and charts.
- 2.Layout: Layout elements provide a formatted layout that you can reuse to organize the elements.
- 3.Form: Form elements can be used to capture user input, such as user-entered text, date pickers, and checkboxes.
Interactions consists of 2 components: an event and an action. When an event occurs, an action is carried out. For example, a click of a button can be an event to trigger an action to navigate to a different page.
An event is a high-level abstraction of something that happens in the app, such as page refresh, button click, or data update.
There are three types of events in the App Builder: inbound event, outbound event, and duplex.
- 1.Inbound event: An inbound event is something that can be listened to. Just like how you can hear people shout out to you on the street, an inbound event will tell the app that something has happened somewhere.
- 2.Outbound event: An outbound event is something that the app can invoke. Opposite to an inbound event, an outbound event is sent by the app to other parties, who can then react to it.
- 3.Duplex: A duplex is a special class of event that behaves differently when being listened to or sent out. Usually, this type of event is predefined by the platform to handle highly specific workloads. It is predominantly used in stateless data operations that involve broadcasting.
An event alone will not be sufficient to define application logic because they merely depict what happened and what to invoke. In order to leverage these highly flexible events, you will need some rules to determine their relationships. We call these rules actions.
An action consists of two candidate events. Simply put, it will send out an outbound event when it senses an inbound event. An action requires a source and a target. Usually, an action is defined on the source, which is an element that listens to the inbound event. For example, you can define an action on a button that sends out a notification when someone clicks this button.
There are 3 major types of data nodes: Acho resource, DB Direct, and Transformation Node.
- 1.Acho resource: Connect your resources and use it for querying against Acho. Your data will be replicated and stored in Acho.
- 2.Database direct: Connect to your database directly and query against your database. Acho will not store a copy of it.
- 3.Transformation node: Query against the previous two types of data nodes.
Data Store is a place where you can create variables to store data and flexibly use it anywhere. These variables can be accessed via accessors. The variables can also receive data via interactions within a specific scope. There are three levels of data in the Data Store:
- 1.App Data: Data is stored at the app level. All the data nodes, elements, or pages in the app can access it or send an interaction to it.
- 2.Page Data: Data is stored at the page level. Only the elements on the same page can access or send an interaction to it.
- 3.Element Data: Data is stored at the element level. It can only be accessed by the element that stores the data. For some elements, such as Lists, their child elements (that is, elements placed within them) can get parent element data directly by declaring specific keys, such as
${$item}.
Last modified 3mo ago