0004956: Allow form_templates API to not always wrap a row - Composr CMS feature tracker

ID	Project	Category	View Status	Date Submitted	Last Update

0004956	Composr	core	public	2022-09-28 17:51	2022-10-02 00:18

Reporter	Chris Graham	Assigned To	Patrick Schmalstig
Severity	Feature-request
Status	resolved	Resolution	fixed
Product Version
Fixed in Version

Summary	0004956: 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

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	non-assigned => assigned
2022-09-28 17:51	Chris Graham	Assigned To	=> Patrick Schmalstig
2022-09-28 17:51	Chris Graham	Tag Attached: Roadmap: v11
2022-10-02 00:18	Patrick Schmalstig	Status	assigned => resolved
2022-10-02 00:18	Patrick Schmalstig	Resolution	open => fixed