Overview
Panaya’s solution is based on many business entities. A Business Entity can be a test module, an impact module, a requirements module etc.
In Panay’s UI – each entity has a General Tab that displays important information about the entity. One of the big challenges we faced, was to make sure all these general tabs have the same look and feel, and act the same, while at the same time, are easy not only to maintain, but also to change for future development.
In this short article, you can read the story of how and why we created the auto generated entity general page by using unified form components with our PEM (Panaya Entities Manager) mechanism.
The challenge
As our platform expanded (due to customer demand), there was an increasing number of new entities, and new fields in each entity. Each field came with its own validation and had its own UX behavior. Gradually, it became hard to keep the same look and feel across different entities.
And, if that wasn’t complicated enough, new entities and fields were consistently being added. We had a find a way to streamline the above processes.
The target
Our target was to create a general tab that would be rendered automatically by the entity fields and related behaviors, using unified components.
What did we want to achieve?
A unified code that could be written once and would behave uniformly for all existing and new entities.
PEM – Entities well defined
To address the challenge described above, we used an existing mechanism that was already developed. This module is called “PEM”
As mentioned before, not only does every entity have many fields, but we also allow users to add their own custom fields.
These entities work in collaboration as part of Panaya’s business logics. For example, a “defect” entity might be related to a “test case” entity or a “requirement” entity etc.
We also realized that we had more than one consumer for the entity data itself:
Export and import of entities to and from various formats, different API’s for other applications that consume or provide entities, and of course, Panaya’s own UI which displays entity details.
Each such consumer had its own code, and upon each change to an entity field – all those consumers had to change. Not very efficient to say the least….
Every field could have interactions with other fields and could have unique validation checks, each field could be visible/hidden according to its unique logic.
Very Complicated….
So – what was the solution?
PEM (Panaya Entities Management) – PEM was created for the sole purpose of having one central repository to define the entity structure and behavior, then any entity consumer in our system can fetch the PEM structure for the desired entity and know how exactly to handle it!
PEM is a JSON object that is created for each entity. This object has all the information any entity consumer needs in order to handle the entity. PEM specifies the field’s properties including type, validation label, field category and much more.
Any entity consumer using PEM can handle and work with the entity in a very easy and transparent way. For example, when adding a new field, we add it to the PEM, we define the desired behavior in PEM, and the Import/Export/API’s code iterates through the PEM fields – so no code change is needed.
AGT (Awesome General Tab) – is all about using the PEM to render the entity details page without the need to change any HTML so it interactively displays new fields as they are added, including validation or desired behavior.
In order to achieve this, we also had to create uniform ui components and some code to produce the details page using the data in the PEM and those ui components.
Unify form components
Although Panaya’s form components are based on 3rd party elements, there are some unique business requirements necessitating extensions to these basic 3rd party components.
We have a large variety of field types; some of them could be customized by the user.
Since the fields are integrated in many screens in the system, we had to create reusable form components that could be used in our new auto generated general tabs as well as in the other screens.
Starting point – when we began implementing the AGT, we already had common ui components. However, they were not really separate ui components but rather a general component wrapper with a huge number of options for different objects and different behaviors.
We used the wrapper to show the relevant element form by using the type and applying the options from the options input object.
Even without AGT in mind – we already faced some severe issues with this approach:
- The options object became too big and complicated, every developer added some functionality to the object to support the different behavior of the fields. The options object became extremely complicated, and it was very hard to maintain.
- The name of the component was the same for all the field types which made it unreadable.
- Every change to one form element could break the other form elements because the logic of all elements was in one central code. That also created the need for mass testing after any form changes
- It was extremely hard to test and deliver single form element.
For AGT – we wanted a simple way to take the field from the PEM description and render a ui component with the needed UX behavior. After trying to use the existing wrapper- we realized its current structure was holding us back!
New UI component implementation – with the concept of Web Components design in mind – we realized that each ui component needs to have its own UX and attributes that control the look and behavior.
We also wanted to break the options object into many specific inputs for the different field types.
Finally, we created a separate form component – that knows how to place different types of ui components on the screen based on the information in the relevant PEM, as provided by its attributes.
So now let us put it all together:
We now have the PEM mechanism that defines each entity structure with all its fields and behaviors.
We also created a form components layer that just gets type and some optional options.
With that, we managed to get all field-related logic and UI behavior without additional configurations.
From that point – It was easy to put it together: get the entity structure from PEM and auto-build the General Tab with the form component layer:
Conclusion
AGT and PEM mechanisms helped us create a unified view of the General Tabs of the entities maintained in one repository. They also helped us with the ability to develop new features in the General Tab faster, with much improved quality.
AGT And PEM also helped us to unify the general tab. The fields in all the different entities now exhibit consistent behaviors, with the same look and feel.