home resources search newsjoinmembers: 6963
PHP Flash Java Ruby Windows Linux
Hiveminds's picture

Hiveminds | Thu, 2006-05-11 20:31  tags: , ,

Web developer

If there is one failing that I have it is a compulsive need to improve on something that I see is not working as simply as it should. This has followed me around from job to job causing me to have to do things like redesign inventory systems and pull the entire wiring harnesses from boats and automobiles. In my mind complicated things should look simple even when the underlying design is so complicated most would not understand it. But if someone decides to peel back the layers then each layer should be as easy to understand as the first. This is the secret. Complication should come in layers of simplicity. This is the only reason I dug into this. I thought that it would be simple. Wrong. Wrong Wrong. No layers here. Just a tangle.

Now, looking at Drupals forms API. After a whole day I would think that I would have some idea of the behaviour of the code. Alas nothing. The only thing I have managed to do is to delete several code rewrites in an effort to get consistent behaviour. It's code like the following that makes me crazy.

<?php

 
// Have to build checkboxes here after checkbox arrays are built
  
foreach ($role_names as $rid => $name) {
    
$form['checkboxes'][$rid] = array('#type' => 'checkboxes''#options' => $options'#default_value' => $status[$rid]);
    
$form['role_names'][$rid] = array('#type' => 'markup''#value' => l($name'admin/access/'$rid), '#tree' => TRUE);
  }
  
$form['submit'] = array('#type' => 'submit''#value' => t('Save permissions'));
  return 
drupal_get_form('user_admin_perm'$form);
}
?>

Looking at the above code one would think that to gain access to the elements of the arrays you would just loop back through them. This is conventional accepted behaviour in all code languages. But it does not work here. the problem here is that drupal_get_form(). This abomination I will not print here because anyone familiar with OOP would go into shock upon seeing it. It is a bit like that medusa head in greek mythology, one look and you turn to stone. Let's just say that the drupal_get_form() function is the reason for the unexpected behaviour and leave it at that.

So now here is the code that releases the checkbox HTML.

<?php

foreach (element_children($form['checkboxes']) as $rid) {
          if (
is_array($form['checkboxes'][$rid])) {
            
$row[] = array('data' => form_render($form['checkboxes'][$rid][$key]), 'align' => 'center''title' => t($key));
          }
        }
?>

But wait. What I want to do is load the form elements into a nice table for presentation. In other words theme the output. This used to be so simple in Drupal 4.6. Just load each element into a cell by matching it to an array element. But in Drupal 4.7 this is no longer true. Now you have to do things seperately and matching them is more so difficult I can't explain it. What produces the outcome is is this code.

<?php

$output 
theme('table'$header$rows, array('id' => 'permissions'));
  
$output .= form_render($form);
  return 
$output;
?>

What that form_render(); is doing I have no idea. How the table melds into the form again I have no clue. It is just one more of those unexplained occurances in Drupals code. These sitings happen a lot in Drupal. Things suddenly appear out of no where. For the end-user it is meaningless but for the PHP developer it is frustrating.

So far I have come to one conclusion in the midst of all this. If the person responsible for this code dies tomorrow then no one else will ever be able to work on it. It would be simpler to reverse engineer Windows.

While an OOP based CMS like Joomla does have shortcomings and complications there is one thing that is evident when you dig through the code. There are consistent layers that are in keeping with known OOP techniques. If you study the code of the techniques then you will understand in a short while. You can find the reason behind a code event if you put enough time into it. But it is still OOP and it takes time.

Drupal has combated OOP by using a procedural technique that has so far proven to be a match for OOP. It is effective in that when you look at the code you are usually only one hop away from the source of the code event. This I think is the reason for the popularity of Drupal. Web devs look at the code and they immediately they can make sense of it and manipulate it to suit themselves. Why Drupal has chosen to move to this old school Perl technique in Form API is beyond me. Especially since even Perl is trying to get away from it.

As mentioned in previous blog the complicated tasks involved with Form API will adversly effect the upgrading of modules. Those module with simple interfaces that hold true to Drupals simple table out put will get upgraded to version 4.7. But developers like myself seeking to improve on the usability and layout of user interfaces will get shut down by the fact that Form API is centered on a single immutable function.

Hiveminds's picture
This article brought to you by the Hiveminds Magazine - Staff. Contact us if you want to post an article or announcement anonymously
a Visitor posted on: Wed, 2007-06-06 22:18.

If you are so damn good, and you think you can make drupal easier for developers and end users, why don't you contribute back to the community?

a Visitor posted on: Wed, 2007-06-06 22:47.

I don't think this is anything to get worked up about. Obviously the reference to 4.7 puts this post as older though the theme doesn't show any date information so I can't tell. Its also obviously venting over having trouble figuring out form.inc which has improved greatly through the 5 and 6 development.

As far as themeing checkboxes go for people that might come across this you're better of taking a look at the form array passed to the form theme function. The devel module has a dpr function which is very handy for this and I think you'll find themeing it into a table fairly straight forward at that point. If that doesn't make sense take a glance at the Drupal documentation of the FAPI for the code flow or ask around the Drupal places and someone can help you get on the right track.

a Visitor posted on: Sat, 2007-08-04 20:32.

This post shows up in the Internet Wayback Machine as far back as March, 2006. Things have changed a lot since then.

Sorry to say that at first glance I'm not terribly impressed with this site. There's no feedback form (I did find a link to hivemindz.com/hm/?q=feedback but there's nothing there). Articles need date information for when they are posted.

Hiveminds posted on: Sun, 2007-08-05 09:19.

Anyone can post feedback by making a comment just as you did. But there is a contact us link under the home link for those that want to make more personal contact.

There are no dates on the articles because they are not really necessary. In cases of anything deemed out of date the readership usually posts that the information contained has been updated in a new version or that improvements have been made. All articles should contain the version and or build of the software involved.

a Visitor posted on: Wed, 2007-08-08 15:04.

Isn't the author contributing by writing this post?

I found the post because I'm ready to freak out after spending countless hours digging through drupal's internals - including such craptastic wonders as the form api.

This is a message that needs to get heard.

 
CMS Comparison Matrix

Newsletter

Get updates on Hiveminds services, articles and downloads by signing up for the newsletter.

Editor's choice

Some of the better articles, stories and tutorials found at Hiveminds.

Find more

Find more of Hiveminds articles, stories, tutorials and user comments by searching.




Picked links

Hand picked websites and articles from around the web that provide quality reading.