What I’m trying to do:
Gather design requirements for an idea. Specifically, what are the ground rules for building a non-visual component?
Why would anyone want a new non-visual component? Here’s one idea…
- A coordinator for a list of related Radio Buttons (or other widgets), where the values (in the listed components) must be mutually exclusive. Serves as a clearinghouse for changes in all the components, ensuring that mutual exclusion is maintained. Keeps a central list/set/bitmap of the in-use values; a single source of truth shared by every widget in the list.
- Concrete example: list of (scheduled) dates in a calendar.
- The dates are pre-determined, by the schedule, so you can’t pick off-schedule dates.
- You shouldn’t be able to pick duplicate dates, either. If a date appears elsewhere in the list, it’s off-limits.
- Concrete example: list of (scheduled) dates in a calendar.
Now, if the widgets are all kept in a single panel, then the panel can do double duty: as the visual container, and the coordinator. No special considerations here. The panel can be an ordinary visual components.
But our widgets don’t always go into a single panel. They may be scattered across multiple rows of a Data Grid.
If the Grid has multiple pages, then we don’t even have a 1:1 relationship between listed values and listed widgets. The widgets that exist at any one time are tied to just a subset of the values. The logic, in this case, is decidedly non-trivial, and deserves to be centralized.
Now, such a coordinator has no visual counterpart at run-time, but it may certainly have design-time parameters. In that case, a non-visual component may make sense.
)?