[development] Hello from another developer/Want to add some features

[Sammy Spets]

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
> 
>