View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 4956 | Composr | core | public | 2022-09-28 17:51 | 2022-10-02 00:18 |
| Reporter | Chris Graham | Assigned To | PDStig | ||
| Priority | normal | Severity | feature | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 4956: Allow form_templates API to not always wrap a row | ||||
| Description | We are trying to solve the "What if we want a form input widget, without it being in the regular table row format" problem Here are some potential solutions... 1) Bypass form_input_* functions entirely, just call their templates as includes from other templates Positive: No breakage to existing function use Negative: We have to move JS and CSS includes into templates from the form_input_* functions Negative: Ugly way of having to do it, and unharmonious with how this was designed to be done originally Conclusion: Okay idea 2) Add a new parameter to each form_input_* function as a bypass to it returning the table row Positive: No breakage to existing function use Negative: We already have lots of parameters in many cases, and having to add a new special-use one to dozens of functions is nasty Negative: If something is required *everywhere* across an API, it invites degredation and lack of symmetry over time as new functions and parameters are added Negative: A parameter that fundamentally changes what a function returns is a bit 'magical' (i.e. not a clean API) Conclusion: Somewhat-bad idea 3) Use a push/pop state changer function for the same instead of a new function parameter (the _form_input function would peek the setting of the state changer function) Positive: No breakage to existing function use Positive: Simple low-footprint change to the code Negative: Also a bit 'magical' Conclusion: Okay idea 4) Split the form_input_* functions in two, with one function returning the widget and another function (same name as current one) returning the widget wrapped in a table row Positive: No breakage to existing function use Positive: A nice clean division of responsibilities Negative: Way too many functions Negative: Copy and pasting of long argument lists across multiple places Conclusion: Somewhat-bad idea 5) Make none of the form_input_* functions use a table row, and make it the responsibility of calling code to wrap each field in a row Positive: Divide responsibilities Negative: A lot of change to existing code Negative: It is actually not clean to just wrap around a table row, many parameters are required to do so - it would be very ugly Conclusion: Terrible idea 6) Make none of the form_input_* functions use a table row, and make it the responsibility of the FORM* templates to wrap each field in a row (As for 5) 7) Completely redesign the form_templates API into classes, a class for each input type, deriving from a basic helper class, and lots of Setters to set different parameters Positive: Clean API Negative: An enormous amount of work Negative: All calling code would need changing Negative: Extra memory overhead Negative: Extra code usage overhead Conclusion: Terrible idea '3' is the winner. It would look something like the following... We'd define these constants: FIELD_ENCAPSULATION_RAW FIELD_ENCAPSULATION_ROWS Calling code would use this before fields were called: push_field_encapsulation(FIELD_ENCAPSULATION_RAW); And cleanup with: pop_field_encapsulation(); _form_input would use: peek_field_encapsulation(); | ||||
| Tags | Roadmap: v11 | ||||
| Attach Tags | |||||
| Time estimation (hours) | 1.5 | ||||
| Sponsorship open | |||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-09-28 17:51 | Chris Graham | New Issue | |
| 2022-09-28 17:51 | Chris Graham | Status | Not Assigned => Assigned |
| 2022-09-28 17:51 | Chris Graham | Assigned To | => user4172 |
| 2022-09-28 17:51 | Chris Graham | Tag Attached: Roadmap: v11 | |
| 2022-10-02 00:18 | PDStig | Status | Assigned => Resolved |
| 2022-10-02 00:18 | PDStig | Resolution | open => fixed |
