Bug #4710

Date callbacks should not be called on non-date elements

Details

Submitted	2005-06-29 20:41 UTC
From	ate2 at cornell dot edu
Assigned	justinpatrin
Status	Closed
Package	DB_DataObject_FormBuilder
PHP Version	Irrelevant
OS	Irrelevant
Roadmaps	(Not assigned)

Comments

[2005-06-29 20:41 UTC] ate2 at cornell dot edu

Description:
------------
Currently, formbuilder uses a callback function to convert between the array used by html_quickform_date and the string used by db_dataobject. This is problematic in situations where I predefine a plain input for date (for dates over long ranges of time, for dates that cannot be expressed as a UNIX timestamp, etc.) because it seems to be impossible to neatly avoid applying this callback for specific cells. To fixes that I see for this are:
1. _date2array() and _array2date() were incorporated into a special date element (say "date_db"). This would extend the existing date element but provided the added functionality of transparently accepting ISO string or quickform array dates and always returning a string array date for the getValue or exportValue.
2. _date2array() and _array2date() were incorporated into the quickform driver so that these callbacks are applied only when a date element is generated. Thus they would not cause trouble with a preDefElement.
3. My current workaround: Set the default value of the custom date field to the raw value from the dataobject after generating the form. Extend formbuilder and override _array2date() to simply return an unfiltered string when the exported submission is not an array.

[2005-06-30 11:39 UTC] ate2 at cornell dot edu

These could be enough, except that the callback isn't validated ahead of time and the null or empty string argument is passed to call_user_func(). Substituting a harmless filtering function such as "trim" does work though.