...
In the article, How-to: Build Bolt API widgets, the data structure for v2 widget reports is explained. For a report to be generated, a widget MUST adhere to the data structures of supported layouts. The point of this is to provide consistency in reporting, where data is easily accessible by a reporting front-end or charting library with little manipulation, allowing for code that is both more maleable and more maintainable.
For each layout there will be only one template in Impac! Angular. The template should consist of both an html template and a coffee script. It is important to keep in mind that these templates should be as dynamic as possible. On One widget can use any number of layouts.
In Impac! Angular, each layout will have its own component nested under components/widgets. It will consist of 3 files, for display, styling, and functionality, a .tmpl.html, .less, and .coffee, respectively.
There are a few things to keep in mind when building a generic component. First of all, one point of creating generic templates is to drastically reduce the amount of code in the project. When there are similar goals being accomplished in many different ways for many different, yet similar components of a project, things become harder to fix, harder to improve, and harder to keep track of. For accounting alone, there are already over 20 widgets available on Impac!. Many of these widgets have similar layouts, e.g. some have almost identical charts but with different data, but every single one of them is their own component. That's 20+ components inside our app, instead of say, 5, one for each different kind of layout. If a widget is always either a chart, a table, or a value, then ideally we should have one component for each of these widget layouts, and reuse these among all 20+ widgets. The idea of creating generic templates is to cut the number of [ accounting ] widget components from [ 22 ] to [ 3 ].
The bolt has provided an opportunity for structuring our data in a consistent way.
The ImpacUtilities service is used to fetch both the css class and template path for each widget. We can use these services to fetch a generic component based on the layouts attributed to a widget at the v2 public widgets endpoint holding data from the bolt. The standard layout data structure of the widget endpoints from v2 will allow for the data to fit the generic template. There are still things to think about in terms of any customization needed for specific widgets. It is possible we will need to change the specified layouts for each widget from an array of strings to an array of hashes where each supported layout points to another object of any custom features the widget will contain. For widgets with multiple layouts, it is still not clear exactly how the generic templates will be used together. This is a work in progress.
...
..
.
WIP