Affects Version/s: None
Fix Version/s: Not Scheduled
KULRICE-113 Simplify how the Lookup, Inquiry, and Maintenance tags get access to the DD KULRICE-5238 build agenda tree UI components KULRICE-10878 Simplify ObjectPropertyUtils KULRICE-5331 UIF Framework - Add support for disabled on input controls KULRICE-5689 KRAD AttributeField currently is not properly inheriting control property from AttributeDefinition KULRICE-861 Add support for a pluggable ActivationStrategy to RequestActivationNodes KULRICE-1452 pluggable exception handling / incident reporting KULRICE-7081 Document the UI Framework - New field group control that encapsulates controls with their associated input field, adding the required legend/fieldset semantics KULRICE-5994 ComparisonOperator does not deal with multiple types well, and isn't pluggable KULRICE-7022 Cleanup, simplify, and unify Rice deployment environments
Controls could be the answer to acquiring more flexibility in the frameworks. We have used them previously (ex. kuali user control) to render more than a simple html control. I have a task now to tie up workgroup lookups on maintenance/lookup screens, and will need to create a new control for this. So they give us the ability to specify a custom lookup, add extra fields (hidden, or rendered) and other flexibility towards layout. My concern is with the overhead of creating a new control:
a) Create a java class to represent the control
b) Add specification to data dictionary DTD
c) Give rules to digester
d) Add export code
e) Add logic to build up the Field object
f) Add rendering html to UI, or rowDisplay.tag
It would be good if we had a lighter weight approach to adding new controls, both for efficiency and to eliminate changes to the core. I suggest some kind of control configuration file, where you specify the attributes of your control, and a view (html for rendering).
Originally recommended by Jerry Neal.