Empowered with trellispark,
your time to build an application is measured in minutes
The process of building an application in trellispark begins with understanding the requirements, and designing a data model. This is usually done during a whiteboarding session where the upper level concepts are defined and their relationships to each other can be clearly understood. The example below shows a few high level concepts and their connections (usually one-to-many) with the smaller concepts that make up supplemental details.
Some ideas will not need to be their own concepts at all; a piece of information that may be frequently changed, but will not need a historical record or multiple versions, can often be simplified out into a field on a larger concept. Most often, ideas will need to become their own concept if there will be multiple versions of them within a larger concept. This breakdown can go into as much or as little detail as necessary, though we will always strive for the most simplified version of a product.
With the data model determined, creating the new application in trellispark is as simple as filling in the blanks. First, a new functionality will be created to contain the new application, allowing it to have its own unique roles to grant access permissions to a user.
The functionality serves largely as a data repository, containing the forms and applications but not directly accessible to the users of the system. The application itself will need to be created as a form within the functionality, and can link to the forms from other functionalities as needed with very little difficulty. Before the application can be made accessible to users, though, it will need to have the key concepts defined. Without these, data could not be captured and stored and the application would do very little.
Concepts are added from the second tab in a functionality as a type of form, of which there are several. The most common types of forms are concepts, though applications are a separate type of form with different requirements. The form will also need to determine what page the form will be displayed on, be it a regular workspace page, a subform page, or a product page. Workspace pages are the standard unit, while subforms exist where there will be multiple distinct types of information that needs to be collected based on the nature of the concept. Product pages have a few other fundamental differences from workspaces and subform pages, but are rarely necessary.
When creating the form, it is important to create a set of form permissions, because without these no instances of a concept can be created or saved. It will determine if there are any specific actions to be taken on save, delete, or cancel commands based on the workflow.
The main form page will also accept details like how many tabs there should be, what the tabs will be called, generic actions, and updates to the message queue. These are all optional fields, but each form will also need to have at least one allowed state, which will be set as the default state to allow the field to be displayed.
With the bare bones of a concept created, it will need some fields to collect data and perform actions on it. This is done on the second tab, labeled fields.
For the majority of simple concepts, only these two tabs will be necessary as they contain all the information that is necessary to collect and store data. Commands are only required to reinforce workflow, allowing complex interactions and interactions to be triggered within the concept. Depreciated items are being phased out, but still necessary in some older concepts.
Translations and Documents are straightforward enough, allowing custom documents to be made and for the form to be translated into as many languages as you decide to input translations for. It is important to note that you must get the translations done externally; machine learning is not yet up to perfect translations just by selecting two languages, as anyone who has experimented with Google Translate will know.
Once a form has a series of fields, those fields can be used to create an Instance Name Generator; this is a formula that will use data from within a form to give the form a human readable name to display in any child lists or places where the form will be referenced. Multiple data fields can be combined by understanding the order you need them to be in, and what prefixes or suffixes should separate different elements to make the list accessible.
Field generation follows a similar format to form generation, beginning with positioning the field in the form itself. There are seven possible configurations within a row in a trellispark form; the row can be full, split in half into left and right, or both left and right halves can each be split in half again. This produces a left left, left right, right left, and right right field.
Just like forms, fields are broken out into a variety of types. The first creation page accepts a set of fields that every field will need to have defined, but because the field concept is a subform, selecting which type of field you wish to display will allow trellispark to display a complete list of the information that might possibly be needed to manage data in that particular type of field.
Every subform form will need to have a field which determine what type of subform and which fields that the subform will have to display. It is similar to a regular GUID field, which is a drop down list, but the element name must be Subform in order to display the required fields. This differentiates it from a regular drop down list, a directs attention towards the Subform Type field, which only needs to exist on the type field. Because the list of types will always be the same, it is a List Concepts list, allowing the user to set the types a subform covers in one place, and then call them in any instance of the subform concept.
And where will these subform types be created? Because they exist in the same way that a regular page can be nested within a master page, the different types of subforms are determined at the functionality level, with the same hierarchy distance that regular forms have.
Adding a new subform type can be as simple as copying the data from the Subform Type inside the field into a Name on the type list, but it is essential that these two linked fields be identical to the letter – if there is even a single character discrepancy, the system will not be able to match the subform types and draw out the correct list.
This list will then be used to build out the actual subform templates. The list of types must be built first because the creation of a subform template requires a type to tie it to a particular form before it can be created. Subforms cannot just exist independently; the order of creation matters in ensuring that your subform forms and templates are able to link up and allow the page to load without crashing.
Subform template creation is essentially a drastically simplified version of form creation; it is not necessary to create things like a default state, access permissions, or instance name builders, as all of these will have been created at the form level. Instead, subform creation focuses primarily on data being displayed. Tabs and data extracts are available to personalize the subform, along with document templates to specify if this subform will need to be reported in a format different from any other subforms on the main form. However, most subforms will not have enough fields to require independent tabbing, and will be able to be presented in the standard way. They will only need their own fields specified.
Field creation on a subform is identical to field creation in a regular form, as the code builder will create them in the same way it creates any other field. This kind of consistency enables a more intuitive user experience and security in the knowledge that any subform being created will behave predictably, adding only functionality, not complexity or more testing.
Because the trellispark model of form and field generation is being tested every time a new form or field is created, and the display model is used in every call from every page, anywhere in this website, that specific code has been testing thousands of times every single day, without the need to schedule additional testing. This leaves development teams free to focus only on personalizing their workflow, rather than checking that fields and relationships will show up correctly on the web page.