Introduction to important terms in Awesome Enterprises
In this note, we are going to cover the important terms that we use while working with Awesome enterprise.
Awesome Enterprise: Awesome enterprise is a shortcode based low code framework for WordPress. It works best with Monomyth theme.
Awesome Core: It is where we keep modules that are core to the execution of awesome and monomyth theme. These modules are cached and after making any changes to them you will need to clear the cache. Check the article understanding awesome core for more details.
Module: It is the most basic piece of code that is written within Awesome Enterprise. It may also consist of templates.
Template: It is equivalent to functions within a module, they are wrappers around code to make them reusable within the module.
Awesome App (app): They are logical wrappers for workflows, apps are used to manage specific workflows. Every module within it is private to the app. If any workflow needs to be created, we create them in App, eg. Plot, this guide, etc. They are accessed by their slug, they allow to override the global header and footer for a page and even the whole layout in case of modules. They consist of three parts config, modules & pages. For details read how to create an app and understanding app config.
Root App: This is the app that is active when you access a WordPress page, allowing you to use modules from the root app in pages as you can do in other awesome apps.
Site Skin App: This is the App where we keep the site-wide CSS as well as moodboard for the site. In config settings, you define the various colors, fonts, and sizes, while in modules we write css for the whole website.
Awesome JS App: As the site skin app, this is where we keep our global JavaScript modules. Awesome JS app is used to include all our commonly used JS libraries and combine them into a single request.
Awesome Services (service): Services are used for the reusable code, something that needs to be shared across apps and projects. They are equivalent to libraries in other frameworks. We have few standard services like DB, UI, Form Controls, etc., that we use across projects. If you are wondering if a piece of code should be written in service, if you have to use it more than once in the module or app, it is better to write it as a service.
Content-Type: They are equivalent to objects and consists, of queries, view and other workflows wrapped in a service like structure. Content-type makes it easier to make an object’s behavior reusable. It is primarily used to create represent a logical entity within the project and is very specific to the project.
Meta Table: In most cases, we use the following table structure to keep our data and our DB services understand and work’s with it.
| Column | Type | Comment |
|---|---|---|
| ID | bigint(20) unsigned Auto Increment | |
| stamp | datetime [current_timestamp()] | |
| updated_by | varchar(50) | |
| object_id | varchar(50) | |
| coll_id | varchar(50) | |
| coll_type | varchar(50) | |
| meta_key | varchar(255) | |
| meta_value | longtext NULL |
This is our preferred way of storing data.