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