[drupal-devel] Rewriting use of forms in Drupal

[Adrian Rossouw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 03 Jun 2005, at 5:24 PM, Gerhard Killesreiter wrote:

>
>
> On Fri, 3 Jun 2005, Adrian Rossouw wrote:
>
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Here's what I am envisioning :
>>
>>
>> /* This is the entire form definition */
>> function somemodule_formname($obj) {
>>      $elements['title'] = array('type'=>'textfield', 'title'=> t
>> ('Title'), $value= $_POST['edit']['title'], 'default' => $obj->title,
>> 'weight' => 0);
>>      $elements['group1'] = array('weight' => 1, 'title' => t('some
>> title here'));
>>
>
> I'd rewrite the last part to
>
>  $elements['group1'] = array('type' => 'group', 'weight' => 1,  
> 'title' =>
> t('some title here'));

>
>
>>      $elements['group1']['element1'] =  array('type'=>'textfield',
>> 'title'=> t('element 1'), $value= $_POST['edit']['group1']
>> ['element1'], 'default' => $obj->element1, 'weight' => 0);
>>      $elements['group1']['element1'] =  array('type'=>'textfield',
>> 'title'=> t('element 1'), $value= $_POST['edit']['group1']
>> ['element1'], 'default' => $obj->element2, 'weight' => 1);
>>
>
> And then for elements:
>       $elements['element1'] =  array('type'=>'textfield',
>  'title'=> t('element 1'), 'value' => $_POST['edit']['element1'],
>   'default' => $obj->element1, 'weight' => 1, 'group' => 'group1');
>
> This avoids nested arrays which is a good thing.
I thought of the same, but what I like about my approach, is that
there is less sorting required, and because there is only one
form_ function that the themer needs to know, it will always work.

He can print the entire group by just going form_element($element 
['group1']),
and just an element out of the group using form_element($element 
['group1']['element1']);

I suppose it could work using form_element($elements,'group1') or  
form_element($elements, 'element1'),
but it would require more sorting inside the code.. ie: stepping  
through each element to find all the elements
that need to be grouped together.

It's 6 of one, and half a dozen of the other.. and I'm not  
particularly stuck on either approach.

>> /* this goes in common.inc */
>>
>> function form($name, $elements) {
>>    if ($form = theme('somemodule_formname', $elements)) {
>>      return $form;
>>    }
>> else {
>>      return form_default_renderer($elements);
>>    }
>> }
>>
>
> Looks good.
>
>
>>
>> function form_element($element) {
>>      if (/*test for group here*/) {
>>          $form = form_group(form_default_renderer($element), $element
>> ['title']);
>>          $form = form_group($group, $element['title']);
>>      }
>>      else {
>>          $form = ${'form_' . $element->type}($element); // Redirects
>> to the type specific element could also be a switch inside  
>> form_element
>>     }
>>     return $form;
>> }
>>
>
> My change above makes this code simpler too.
As I explained, I think it might make the code more complex.


>> This could of course be overridden.
>> Say you didn't want to display the title , you could do a
>>
>> function mytheme_modulename_formname($elements) {
>>     $elements['title']['type'] => 'hidden';
>>     return form_default_renderer($elements);
>> }
>>
>
> I am not sure we should allow modules to change form types.
This could be really useful.

Imagine if you install an extra module which changes a field to  
autocomplete, and
adds a callback.

Or perhaps a module that adds a javascript date picker that replaces  
the form_date
with a form_javascript_date.

As long as the validation doesn't break, I don't foresee this being a  
problem. The
pathauto module might decide to remove the path field completely in a  
node form.

Another point is, the nodeapi in this case turns into a single call  
'form' which allows
you to add elements to the form array, as well as changing items as  
described.

> I think I solved this problem, too.

What if we have a TYPE='container' , as per Ber's recent patch.
We might also need deeper nesting (not that I would like to see that  
in core)


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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCoHl9gegMqdGlkasRAldCAKDUDFJLBqqysTzzdo2UwsXbeQsXBgCfZKhz
X1L7g+BKa/mWF6Vctb+AXuo=
=ZECx
-----END PGP SIGNATURE-----