Concepts
Template Structure
How templates are structured
Overview
Templates are the container for defining a unique process. They are the top-level of any process you define within the Stubber ecosystem.
Following the correct naming conventions for your templates is very important and should be named after the process you are implementing.
Templates have various components and follow a tree-like structure. Let's take a look at the table and image below and break it down. It may look complicated, but it's all really simple.
Together the template, branch and context define a unique process in Stubber. This means that one template can perform several different processes
What is a Context?
The best way to think about context is the "mode" of the template. Some examples of contexts are create
, manage
or default
.
Create
context
The The create context (or mode) is where you define what happens when a user first interacts with your template. The create
context is primarily used for generating unique stubs. Remember, stubs are the unique instances of your template. Read here if you need a refresher on the relationship between stubs and templates
Default
context
The The default context (or mode) is where you define the typical or default
flow that should be followed by each stub. This is where you define the process what happens when a customer makes a purchase, or the process of sales enquiry, etc.
Manage
context
The The manage context is used to manage all the stubs in the manage context.
Conceptual Example
This means a stub actually follows the definition contained in the context of the template. So there are flows for each context, or mode, within a single template.
Practical Example
Using the sales enquiry example, that template will have several setups for each context. The use case for each context of the sales enquiry might look something like:
Create:
Specifies what happens when a sales enquiry is created, what information or fields we require, and what actions should be taken to initiate a sales enquiry. We'd likely need some basic customer contact information, what product or service they're interested in, etc. This will be passed over to theDefault
context when the stub is actually created.Default:
The general flow or process that should happen with each sales enquiry that is created. This would be where the process of capturing details, quoting the customer, initiating the sale (or having the sale be rejected) would be defined.Manage:
This context specifies how someone would manage a sales enquiry and contains all the actions involved in that process. This context outlines the actions required to oversee and handle the sales enquiry throughout its lifecycle. This could include actions like updating inquiry details, following up with the customer, or closing the enquiry once resolved.
Flow
Basics
The flow is the interface where you actually do the work to set up your templates. This is where you define the states and actions of the the various contexts.
The flow is built and maintained in the Editor application on the Stubber Platform.
States and Actions
The states and actions are the building blocks of the flow. If you require a refresher on states and actions you can visit this page.
Example
Here is an example of what a template structure would look like to define a "sales enquiry" process.
There are 2 default branches namely draft and live.
The publish action on the editor will copy the draft branch to the live branch.
It is possible to change the program of a stub using the morph stub task.