[drupal-devel] Rewriting use of forms in Drupal

[Gerhard Killesreiter]

On Fri, 3 Jun 2005, Adrian Rossouw wrote:

> On 03 Jun 2005, at 5:24 PM, Gerhard Killesreiter wrote:
>
> > On Fri, 3 Jun 2005, Adrian Rossouw wrote:
> >>      $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,

That is true. But I think the code looks cleaner the other way around.
It is also not a performance concern as forms would only rendered on
form pages.

> 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'),

I think having a simple interface to form elements would work either
way.

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

Neither am I.

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

The code in common.inc (or wherever it will be, I'll probably make a
form.inc) will be more complex, I agree. But the actual form building
code in the modules will be easier to read if we do not have nested
arrays.

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

Shouldn't we then rather patch the original module?

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

If we can have a non-JS friendly date picker it should be in core, if we
cannot, we shouldn't support it.

> As long as the validation doesn't break, I don't foresee this being a
> problem.

The validation could break, that is why I am not convinced changing
field types is a good idea.

> The pathauto module might decide to remove the path field completely
> in a node form.

Hmm. You can get that with permissions.

I guess if we can figure out how to validate with changing form types,
we could support it since it is according to my "Drupal should be as
flexible as possible" mantra.

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

That would be the same as a form group, no?

> We might also need deeper nesting (not that I would like to see that
> in core)

If we can make usefull use of it, why not?

Cheers,
	Gerhard