[drupal-devel] [task] New drupal forms api.

[nevets]

Issue status update for 
http://drupal.org/node/29465
Post a follow up: 
http://drupal.org/project/comments/add/29465

 Project:      Drupal
 Version:      cvs
 Component:    base system
 Category:     tasks
 Priority:     critical
 Assigned to:  adrian
 Reported by:  adrian
 Updated by:   nevets
 Status:       patch (code needs work)

Minor point on #5 and #6, when accessing an associated array like
$form[class][] = 'someclass';
if the key is a string it should be enclosed in quotes, i.e.
$form['class'][] = 'someclass';
(This is from the PHP documentation.)




nevets



Previous comments:
------------------------------------------------------------------------

Tue, 23 Aug 2005 11:34:00 +0000 : adrian

Attachment: http://drupal.org/files/issues/form.inc (20.53 KB)

This is the first check in of the new forms api code.


The system has been designed to co-exist with the current forms api,
and is contained in a new
include file (includes/form.inc).


Forms are now defined in their component arrays, similar to how menu
items are defined.


example :

<?php
 $form['body'] = array(type => 'textarea', default_value =>
$node->body, cols => 60, rows => 60);
?>


Elements can also be nested, and the $edit follows this definition. For
instance :

<?php
 $form['author'] = array(type => 'fieldset', title => t('Authoring
information'), collapsible => TRUE, collapsed => TRUE, weight => -1);
 $form['author']['name'] = array(type => 'textfield', title =>
t('Authored by'), maxlength => 60,
                                 autocomplete_path
=> 'user/autocomplete', default_value => $node->name, weight => -1);
?>




All the properties used are defined as constants, and are documented
for each of the elements, and individually.




------------------------------------------------------------------------

Tue, 23 Aug 2005 11:46:19 +0000 : adrian

A patch for node.module, blog.module and taxonomy.module that changes
them to use the new form format. This patch is very far from complete,
but I wanted to get the code out so that i'm not working alone anymore.




------------------------------------------------------------------------

Tue, 23 Aug 2005 12:08:01 +0000 : adrian

Attachment: http://drupal.org/files/issues/forms.patch (9.98 KB)

The actual patch =) 


I forgot to mention, this adds a new hook .. namely hook_elements,
which allows us to define the defaults for the elements (ie : cols and
rows for textareas) meaning they don't have to be defined for each of
the elements.




------------------------------------------------------------------------

Tue, 23 Aug 2005 12:09:11 +0000 : chx

A few notes from my conversation with adrian. valid => array('integer',
'uid') for this to work you need function valid_integer($element) and
valid_uid($element). $extra for form_select is legacy and really
needed.




------------------------------------------------------------------------

Tue, 23 Aug 2005 12:39:13 +0000 : fago

i really like this approach.


further i'd like to see the possibility to define an additional class
to a form element, which is currently not working. so we 'd have to
bring _form_get_class() and drupal_attributes() together.




------------------------------------------------------------------------

Tue, 23 Aug 2005 12:56:31 +0000 : adrian

that works already.



<?php
  $form[attributes]['class'] = 'someclass';
?>




Although I am considering just adding a class property ...


ie:

<?php
  $form[class][] = 'someclass';
?>




The fact that this is done via arrays, it means that the developer can
add classes as he or she sees fit.




------------------------------------------------------------------------

Tue, 23 Aug 2005 13:29:10 +0000 : fago

really?
i don't think so.


e.g.
 $checkbox = '<input type="checkbox" class="'.
_form_get_class('form-checkbox', $element[required],
_form_get_error($element[name])) .'" name="'. $element[name] .'" id="'.
$element[id].'" value="'. $element[return_value] .'"'. ($element[value]
? ' checked="checked"' : '') . drupal_attributes($element[attributes])
.' />'


so we will end up with two class attributes, which won't work and isn't
standard compliance.
your css property idea would be ideal imho.