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

[moshe weitzman]

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:   moshe weitzman
 Status:       patch (code needs work)

Does this API affect form validation also? Thats the vague impression I
had in my head, but I don't see any validation changed in node or
taxonomy modules. perhaps that part is coming next.


There are reasons to love this patch. But one thing I don't like is the
movement toward arrays and away from functions. Modern editors and IDE's
offer function tips and function completion. These are huge time and
brain savers. They are great for newbies and for experts. It is so
helpful to just type 'form_sel', press tab, and have
form_select('title', 'name', 'value', 'options') printed for you, with
all the arguments. When you define forms in an array instead of
functions, as proposed in this patch, you lose a lot of developer
productivity and friendliness for newbies. Developers are also more
prone to mistakes this way since the editor can't guide them along.


This is the sort of advantage that means nothing to the many people who
just use a plain editor, and means everything to IDE users. Maybe
someone can think of a way to keep the flexibility without losing IDE
productivity.




moshe weitzman



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.




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

Tue, 23 Aug 2005 13:40:12 +0000 : nevets

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