I require the following field types in my modules and am in the middle of coding them. The types I plan to add to core are: type MySQLtype PgSQLtype ----------------------------------------- date date date datetime timestamp timestamp time time time Some problems i've found while upgrading my modules. These i've fixed (or am currently fixing) and am willing to submit a patch. * FormAPI doesn't set error class of any select elements. * FormAPI doesn't validate dates (i.e 30/Feb/2000 is valid) * FormAPI doesn't automatically set the default value of a date field to the value from the database. This is annoying because then you have to put repetitive code into _every_ module using date type fields. * FormAPI doesn't automatically bring the date back to ISO 8601 format prior to submit code. This is annoying because then you have to put repetitive code into _every_ module using date type fields. Which types go into core and what to leave out? IMHO core should support all oftused DBMS types. Especially date/time types. I also believe the types i've listed above are the most fundamental of date/time types and others, such as timestamp with timezone, can be added in later. I can see one reason why these should not be added to core. It will make FormAPI changes (and CCK most likely) more time consuming to implement and test. Those wanting to use dates in 4.7, and ensure modules will need minimal changes after that, will rejoice for this much needed addition. If FormAPI maintainers don't want to accept an extra 15 or so lines of code i'll have to go beat 'em up with a date field. ;) C'mon! 15 lines of code aren't that hard to maintain! What's the point of having an API if it doesn't do everything for you automatically? Does core want my patch or what?! :) Actually, while i'm on the soapbox... I wanted to propose another element for the FormAPI, '#decess' or in other words, the opposite of '#process'. First of all, it allows the API to de-process a field. E.g put the three fields (month, day, year) in $form_values back together into an ISO 8601 date string so modules don't have to do it. Additionally, it should allow modules to override the API's decess function to give them flexibility on format of the date string. Whatcha reckon Adrian?! *ducks* -- Sammy Spets Synerger Pty Ltd http://www.synerger.com/ On 29-Jan-06 17:23, Adrian Rossouw wrote:
On 29 Jan 2006, at 3:36 PM, Robert Douglass wrote:
This statement really makes me think that either you're going to benefit greatly from the CCK work, or you're going to make the CCK work completely redundant. Yeah. it's definitely going to embrace the CCK work and get some of it into core. Essentially the input/output/validation layer, but not specifically focusing on the data layer (ie: the actual saving and reading from the database).
The part that makes the forms api so complex right now is the fact that we are representing two different data structures, within a single multi-dimensional array.
1 : field definition, which is essentially what we are validating against, and populating from the request.. 2 : structure, which is essentially fieldsets and tables and things.
The single most complex function in forms api is _form_builder() which essentially recursively steps through the form array, and creates a field definition array from the element definitions.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com