By dman on

This can probably be done by extending the form builder functions and inserting table structure where currently we have fieldset structure.

Table layouts are not all bad.
Sometimes, when dealing with actual data, a table is the right thing.
Could phpadmin work without tables?
Anyway, my data structure needs tables. And form elements inside them.

... Read the full story. Drupal.org doesn't want to host my post :(

I've done it

... at least to the point that I need to, and in a totally forms-API compliant way.

Source code, and a theory lesson provided.
Anyone with further insight into the forms API is welcome to contribute!

.dan.

⋅ Categories: Drupal 4.7.x

Comments

marknewlyn’s picture

marknewlyn commented

Thats something I also really wanted to do but never got round to doing it. I really needed tables to condense my layout a lot.

Thanks for banging through with it, I certainly appreciate the example and explanation. Where is the actual code though? I couldn't see a link to the attachment.

Cheers,

Mark

boris mann’s picture

boris mann commented

Is this a patch that is needed (which might make sense for 4.7, since it is FormAPI related), or more like a recipe that people can follow when they are mixing FormAPI and tabular data?

If it's a recipe, copy/pasting your HTML to a handbook page (e.g. the Forms API Tips & Tricks section) would be much appreciated. You may have to attach the HTML as a file to a documentation issue since regular users get lots of HTML filtered out.

Thanks!

heine’s picture

heine commented

There's already a page in the Forms API Tips & Tricks section about Writing forms in tables. Frankly, I find the FAQ method and the examples in node_admin_nodes & theme_admin_nodes much 'cleaner'.

edited to add: but let's wait for the attachment
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.

dman’s picture

dman commented

Didn't see that there.
In fact, I'm not sure I'd even seen form_render() !

This was just my second step in 4.7 conversion, and I was interested in the possibilities given by hook_elements().

IF you think that forms are all about data but not about layout.
IF you think tables are unrelated to data and all about rendering,
THEN I agree splitting the table off into the theme as the FAQ suggests is right.

HOWEVER
Despite the trivial example in my demo,
I'm not using a table just because I want a certain layout, I'm using it because my data is tabular and sits in rows and columns.
Therefore I'm constructing the rows and columns at the same time as defining their data fields.

The fact that my field sits in a cell in a row is important to the very definition of the field, more important than it is to most formgroup members. Thus, I place that information in my $form data structure.

.dan.

http://www.coders.co.nz/

.dan. is the New Zealand Drupal Developer working on Government Web Standards

chx’s picture

chx commented

i wanted to look into the source but was unable to find. please help me out so I can help you with some advice. some form_table idea was raised earlier, and I think drumm was working on it.
--
My developer blog. | The news is Now Public | Ask not what Drupal can do for you -- ask what you can do for Drupal.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

dman’s picture

dman commented

Sorry about that.
.htaccess was denying access to any file with 'module' in the name.

All clear now.

I've made this demo a little module, just so it's easy to distribute, but I do imagine it a core patch.

basically all it is is the functions:

/**
 * Build an HTML tag. 
 * Very generic.
 * Uses #type, #attributes, #children and #value
 */
function theme_element($element){
  return '<'.$element['#type'] . drupal_attributes($element['#attributes']) .' >' . $element['#children'] . $element['#value'] . '</'.$element['#type'].">\n";
}

function theme_formtable($element){
  return '<table' . drupal_attributes($element['#attributes']) .' ><tbody>' . $element['#children'] . $element['#value'] . "</tbody></table>\n";
}
function theme_tr($element){
  return theme_element($element);
}
function theme_td($element){
  return theme_element($element);
}

There's also some processes for my lazy structure but these 3 element renderers are all that are needed.

http://www.coders.co.nz/

.dan. is the New Zealand Drupal Developer working on Government Web Standards

adrian’s picture

adrian commented

the problem was tables are primarily output, and it was decided that the forms api should tackle forms only.

In reality very little of forms api is form related, it's more of a 'render api'

I didn't make a form table set of functions, because they would conflict with the current theme_table.

I would like to see us move towards defining all tables this way in the future, but unfortunately the time is not right for it =(

--
The future is so Bryght, I have to wear shades.

dman’s picture

dman commented

And I've worked with them before.
They are clever, and extensible, and pluggable always valid and all that, but sometimes they are just too damn verbose.
Taking 6 lines (and 4 function calls) to produce one standard html element starts to look pretty silly sometimes.

BUT if that's what it takes to take advantage of the rest of the goodness that the forms API gives us, I guess I'll live with it.

Anyway, the current form renderer is not a hell of a lot different from this already. It just needs to be told to ignore (or otherwise use) the #tags it may come across, to look for a renderer if its cell contents are not a string, and it's probably good to go.

http://www.coders.co.nz/

.dan. is the New Zealand Drupal Developer working on Government Web Standards

dman’s picture

dman commented

I've had much goodness happening with my attempts so far, relationships.module is mostly 4.7, but needs a lot of testing to make sure it's still hanging together in places.

I still want to squeeze more out of Forms however.
As seen in my (4.6) Add Term Form
I added a convenience function to populate the identifier and the description field with some boilerplate derived from the 'label'.
(enter something in the first field, then click the second & third.)

Well the code translated to this in 4.7:

  $form[PREDICATE_NAME] = array(
    '#type' => 'textfield',
    '#title' => t('Predicate name'),
    '#default_value' => $edit[PREDICATE_NAME],
    '#attributes' => array(
      'onclick' => "if(!this.value){this.value = this.form.elements['edit-label'].value.replace(' ','',)"
    ),
  );

...but all attributes get check_plain() run over them, so it munges my code.

I appreciate the guidelines that recommend placing all code in external libraries and attaching them with event handlers etc, but that's a lot of messy work for this trivial function

Could we possibly just get drupal_attributes() to not destroy attributes starting with 'on' ?

... I'l xpost this as a feature request for discussion I guess. The patch is trivial.

.dan.

http://www.coders.co.nz/

.dan. is the New Zealand Drupal Developer working on Government Web Standards

heine’s picture

heine commented 
'#attributes' => array('onChange' => "top.location.href=document.getElementById('edit-category').options[document.getElementById('edit-category').selectedIndex].value"),

which resulted in:

o nChange="top.location.href=document.getElementById(&#039;edit-category&#039;).options[document.getElementById(&#039;edit-category&#039;).selectedIndex].value" id="edit-category" ><option value="0">Jump To Company</option><option value="http://www.example.com/taxonomy/term/">

The strange thing: it works... though I would certainly like a feature that allows for unscathed code.
--
Tips for posting to the forums.
When your problem is solved, please post a follow-up to the thread you started.

shanghaiguide’s picture

shanghaiguide commented

Thanks for the tip of using attribute, and throwing it into an array for avoiding the munging of data.

I've been trying to do a taxonomy dropdown in 4.7, and also had the same issue of but I just want to do a simple change event, not add some new .js modules for something simple grrr. :)

My (now working!) code for a taxonomy dropdown using the new forms api.

$vocabulary = db_query("SELECT term_data.name, term_data.tid FROM term_data WHERE term_data.vid=1 ORDER BY name");
$options[] = t('List by Country...'); // Initialise the country array
//Populate array with url / name
while ($term = db_fetch_object($vocabulary)) {
  $options['taxonomy/term/'.$term->tid] = $term->name;
}
//Build dropdown select
$form['category'] = array(
  '#type' => 'select',
  '#name' => 'country',
  '#id' => 'country',
  '#title' => '',
  '#default_value' => '',
  '#options' => $options,
  '#description' => '',
  '#multiple' => $multiple = FALSE,
  '#required' => $required = FALSE,
  '#attributes' => array('onChange' => "top.location.href=document.getElementById('country').options[document.getElementById('country').selectedIndex].value"),
);
//Output the form
 print_r(form_render($form[category]));

-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://www.shanghaiguide.com