It seems like there are many use cases for such a field. Creating a complex custom widget with many interacting field states is extremely difficult right now due to the way rules work in Maestro. For example, an accordion-like effect where only one of many fields can be visible at any given time, or a multi-stage validation that involves both a field-level validation and one performed by a DDS. These could both be accomplished easily by having a "controller" rule existing outside the fields, but instead require unmaintainable workarounds involving additional data fields representing state and manually inserting their values into rules in each field involved.If the above problems are not actually as bad as I've said, please let me know, but we have encountered multiple use cases that seem to support the addition of a business rule field.
A custom component can contain fields with custom rules and data fields per your initial query. You can drop a custom component into any layout on your form and use it multiple times. You can modify the layout within a custom component by editing that component in the Component Editor - then refresh your form and this will effect every instance where the component is used in a form, saving you have to edit in multiple places.
You can even add content to an instance of a custom component in your form design. Where you have used the custom component in your form you can change layout properties within the component by modifying the column spans, visibility rules, styling and other properties.
You cannot change the order of elements within the custom component without editing it in the Component Editor. I'm not clear on why you would want to do this.
Hey Brian, I'd love to hear if the custom component strategy worked for you?
Hi Brian, can you provide a specific use case? We made an accordion yesterday, I could provide you with the form export if that helps?
The use case I ran into yesterday had a couple of issues with regards to when and how often certain scripts are called, in particular validation. However, the main issue I have with relying on only scripts with a one to one mapping to their fields is that I ended up having to copy and paste my code more than once since I had another example of the same complex validation that required a DDS call on another page. This violates the DRY principle and is not scalable. For each additional field that needed the same complex validation I would have to copy and paste that code into both its validation and change scripts and create two additional Data Fields to store the state for those as well. This means with only two examples of the same complex validation, I have two identical validation scripts, two identical change scripts and two more data fields to store state. If somehow I needed to make a change to my validation logic I would have to go to each and every field to make sure its scripts were updated rather than just updating a single business script with a one to many mapping to it's field dependencies. This duplicated approach seem prone to error and takes additional development time.
Blake, when you have a capability that you'd like to reuse over and over you can very easily create a custom component. Have you considered this? You then only need to change the logic in one place.
Ben, I did consider creating a custom component but I'm having difficulty separating the layout of the capability as a component in a block container from what I need from the client. Is there a way to group certain components into a custom component while still using them as if they were individual components so that I am free to place them into any layout required by the client?
Blake, did you resolve your issue?
Hi Ben, I think a custom component should work but I may have to change the layout to put both fields, (currently on two different rows), on the same row since they would have to been in the same block container to make the custom component. Other than that it should work just fine for a reusable component.