Developing an Application

Now that we have planned our app in the conceptual stage, we can bring it to life! 🚀 While the conceptual stage moved from general to specific, writing the package takes the opposite approach. It begins with defining the smallest units and builds up to the complete application.

There are two common approaches to writing a package. The table below outlines the differences between both methods, helping you choose the best workflow for your needs:

Approach A: Build from the Basics	Approach B: Focus on Object Types One by One
1. Start with a Blank Package 2. Define Smallest Units: Attributes 3. Define Smallest Units: Relations and User Relations 4. Define Smallest Units: Components 5. Create Object Types 6. Define Relations Between Objects 7. Define the Application	1. Start with a Blank Package and Define Basic Application Details 2. Create Object Types*: Define the following for each: Define Smallest Units: Attributes, Define Smallest Units: Relations and User Relations, Define Smallest Units: Components3. Define Relations Between Objects 4. Define the Application
*Step 2 in Approach B:

Create object types one at a time, defining their attributes and components as part of the process. For each object type, decide what attributes it will need (e.g., text fields, checkboxes) and which components will display its data (e.g., tables, diagrams). Once finished, move on to the next object type and repeat the process.

Approach A: Start with the Basics and Build Up

This method focuses on defining foundational elements first, then they will be used to create object types and the application.

Steps:

1. Define foundational properties, such as components and attributes.
2. Define object types and build their pages using the predefined components and attributes.
3. Specify relations between object types. Define any special relations in their own asset.
4. Define custom assets (e.g., workflow states, workflows).
5. Assemble the application using all created assets, components, and attributes.

Advantages	Disadvantages
Ensures consistency in the app structure and functionality.	Requires detailed upfront planning, which can feel overwhelming.
Works well if the app structure is already clearly mapped out.	May be less intuitive for users who prefer to focus on one object type at a time.
Depending on your style, this method could be suitable for larger, more complex apps with many shared elements.

Approach B: Build Object Types One by One

This method involves defining each object type individually, creating its components and attributes as you go.

Steps:

1. Provide general application information.
2. Define object types one at a time, creating their components, attributes, and relations as needed.
3. Specify relations between object types. Define any special relations in their own asset.
4. Define custom assets (e.g., workflow states, workflows).
5. Finalize the application using all defined elements.

Advantages	Disadvantages
Easier to focus on one object type at a time, especially for smaller apps.	Can lead to inconsistencies if similar components or attributes are redefined multiple times
Provides flexibility to think through the needs of each object type during creation.
Suitable for users who prefer an iterative, exploratory approach.
Works well for unique apps with object types that don’t share many components or attributes.

Summary

To help you decide which method suits your needs, here’s a side-by-side comparison of Approach A and Approach B.

Aspect	Approach A: Basics First	Approach B: Object Types First
Workflow Style	Structured, step-by-step.	Iterative, exploratory.
Planning Requirement	Requires detailed upfront planning.	Encourages flexibility and adjustments during creation.
Reusability	Allows for flexibility and adjustments during creation.	May result in redundant definitions of similar assets.
Best for App Size	Larger, complex apps with shared elements.	Smaller, unique apps with distinct object types.