Hello,
Recently I have changing how I do my UI components within Perspective. Before hard coded bindings often directly to a tag path, or I would have a custom fields at the page level and have unique property binding paths. Now within a higher level container I have a sub container with a generic name(so that binding paths do not change) and put all the custom fields there,
Component example,
Custom Field examples,
All my bindings and events are driven off of these(On click scripts, expression bindings, etc). The drive behind this change was to create easy to reuse copy and paste UI components. Changes are made all in one place, no digging through and editing the several bindings a UI component has. Not only to save me time, but also make it easier for another user to use my components.
My questions,
- Is this good practice?
- Are there performance downsides compared to direct tag binding?
- Are there any downsides to setting it up like this?
Best,
Alex
Take it one step further, turn that sub container into a separate view and use that view as a template/embedded view. Add parameters to the template to pass enough info to build the needed tag paths, or pass the tag path(s) directly to the template to indirectly bind to. Then, embed as many instances of the template on the main page(s) as needed.
This is the generally accepted standard for single point of edit reusable templates/components. Combine that with consistently structured tag folders/UDTs and you can have a full faceplate template that only requires a single tag path parameter.
This has the additional benefit of any time you need to modify those components ( add an additional label, or add new state text, etc), you can modify the single template and the changes will take effect across all instances.
Additionally, set all your custom properties to private, to cut down on the amount of data being sent to the session. (right click property -> Access -> Private) Top level of object and list types is enough, you don't have to click through every child item.
