Every object type in Dawiso represents a data category with its own set of characteristics, attributes, and behaviors. Object types serve as the foundation for structuring your data, defining the rules for how entities are created, stored, and interacted with in the system.
Key Characteristics of Object Types
- Metadata Variability: Each object type can store different kinds of metadata, reflecting its unique purpose. This is why object pages are defined individually to accommodate their specific attributes and features.
- Relations: Object types can be related to one another, and their relations define how they interact.
- Hierarchy: Hierarchical structures:
- Establish parent-child relationships and influence the left-side navigation of your application.
- Determine the object paths (shown as breadcrumbs at the top of object pages and in search), providing additional context to your data.
In this step, we will decide:
- What object types to include in your package.
- What relations should exist between them.
- How the hierarchy should be structured, which determines how the objects are displayed and navigated in the application.
Object Types and Their Hierarchy
First, we need to map out the object types for our app and establish their hierarchy. This helps ensure the data structure is organized and intuitive, supporting clear navigation.
- Cuisine(e.g., Italian)
- └── Recipe (e.g., Pasta Carbonara)
- Ingredient Category(e.g., Ingredients)
- └── Ingredient Category(e.g., Dairy)
- └── Ingredient (e.g., Parmesan Cheese)
- └── Ingredient Category(e.g., Dairy)
Our hierarchy is established through parent-child relations between the object types. A parent object type contains or organizes related child object types. For example:
- A Cuisine serves as a parent for Recipes, organizing them into categories like “Italian” or “Mexican.”
- Similarly, an Ingredient Category acts as a parent for nested Ingredient Categories (e.g., “Dairy”) and individual Ingredients (e.g., “Parmesan Cheese”).
Hierarchies add valuable context to your data. For example, imagine each family member has their own version of lasagna in their space. A search for “Lasagna” might return multiple results, but the hierarchy shown in the breadcrumb path makes it easy to tell them apart:
- Anna/Recipe Manager/Italian Cuisine/Lasagna
- Max/Recipe Manager/Italian Cuisine/Lasagna This way, even with shared recipe names, you don’t have to open all of object types to check the details.
Our example is very simple, but the more complex your data is, the more useful the object hierarchy is.
Object Relations Schema
Now that we have our object types and established their hierarchy, the next step is to determine whether there will be relations between them and, if so, define the types of relations that best reflect their interactions.
The schema below provides a visual representation of these relations for the example Recipe Manager application.
From the schema, we can identify three main sets of relations:
- Parent of / Child of
- Contains / Is used in
- Recommends
The parent-child relation is predefined in the core package, while the other relation types are custom and will need to be explicitly defined in the package.
User Relations
User relations are a special type of relation that allow you to assign users to objects. Core user relations, such as Data Owner and Data Steward, are already predefined and ready to be used.
For our example application, we will create two custom user relations for recipes:
- Recipe Owner: Assigned automatically to the user who creates the recipe.
- Best Cook: Assigned manually to highlight the most skilled creator for the recipe.
Example Application Summary: Object Types Overview
The table below summarizes the object types, their relations, and their role in the application, based on the recipe management app example:
| Object Type | Relations | Use in the Example |
|---|---|---|
Cuisine | Parent of Recipe | Cuisine types such as Italian or Mexican. |
Ingredient Category | Parent of Ingredient Can be a parent of another Ingredient Category | Can be a type of ingredients or a section for all ingredients. |
Recipe | Child of a Cuisine Type, “Contains” an Ingredient, “Recommends” another Recipe | Individual recipes. |
Ingredient | Child of Ingredient Category, “Is used in” a Recipe | Individual ingredients used in recipes. |
Special Technical Object: Space Application Overview
Apart from your object types, there is one more technical object type to define: the space application overview. This object serves as your application’s homepage and provides an overview of its contents within the space. It will need to be set up later, so it is advised to keep it in mind as you plan your package.
The space application overview typically includes:
- A description of the application.
- A table listing all objects inside the application that belong to the space.
Next Step: Specifying Object Details
With the object types and their relations mapped out, the next step is to decide what information each object will store and how it will be presented on the page. This involves defining attributes (the data) and components (the features and visuals) for each object type.
<— Back to: Define the Application Purpose Next: Decide on Attributes and Components —>