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

[Adrian Rossouw]

On 31 Jan 2006, at 8:20 AM, Sammy Spets wrote:

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

Drupal core uses integers for time fields. This is all that was coded  
for.

> * FormAPI doesn't set error class of any select elements.
That can be construed as a bug, and should be fairly simple to fix.

> * FormAPI doesn't validate dates (i.e 30/Feb/2000 is valid)
Then write a validation function which does validate dates and make
it the default on the date field (in system_elements);

> * 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.
Because we use integers in core. I know that the date/time field
has changed since last I worked on it though, as I think some
of alex' code made it in.


> * 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.
You could create an #after_build that did this for you, but once again
drupal core uses integers.

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

Because Drupal core doesn't use date/time types, the forms api wasn't  
designed
to use them. I personally like using date/time types, and I think  
there's good
enough reason that we should actually move to date/time fields for  
all timestamps
in Drupal, instead of having two different mechanisms. I know that  
postgres can be
... peculiar when it comes to date time fields though, and converting  
to unix timestamps
is very different between them (unix_timestamp(datefield) vs extract 
(epoch from datefield),
so cross platform sql is also not as simple as it might seem.



> 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!
You can very easily maintain this in contrib without needing to put it
into core. and at this stage, I think it's a bit too late to try and  
get it into
core.

Keep in mind. the forms api is about generating forms (ie: output), it's
not about specifying field types. It allows completely optional  
validation
of these inputs, but it has no actual knowledge of 'this is an integer,
or this is a date/time value"

That's one of the first things that's going to change when 4.8 opens, at
which point implementing integer, float and date/time fields is going to
be one of our primary concerns.


>
> What's the point of having an API if it doesn't do everything for
> you automatically? Does core want my patch or what?! :)
Ummm. Because we had to choose an implementable chunk
of the functionality, given the time constraints we had
(and yet still managed to completely overrun our schedule),
it just wasn't possible to implement the second phase of the forms
API (also arguably one of the first phases of CCK too).

Upload your patch and let the code speak for itself.


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

You can use #after_build for that.


--
Adrian Rossouw
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com