[development] Data-driven database tables and updates

Steven Wittens steven at acko.net
Sat Jun 10 02:42:24 UTC 2006

Op 10-jun-06, om 04:19 heeft Jeremy Epstein het volgende geschreven:

> On 6/10/06, Dries Buytaert <dries.buytaert at gmail.com> wrote:
>> SQL is an abstraction layer, and one that is documented in hundreds
>> of books and articles.   It is my opinion that creating a Drupal-
>> specific abstraction layer on top of an existing, standards compliant
>> abstraction layer used by hundreds of thousands of people creates an
>> additional barrier for developers that are new to Drupal, but that
>> are familiar to SQL.
> The same could be said of forms. HTML forms are also a well-documented
> abstraction layer, for getting data from users of a web app, in a
> standard way. Yet we have a Drupal-specific abstraction layer on top
> of them (i.e. the Forms API).

The situation with HTML forms is quite different...

HTML form tags work on the level of UI widgets. <input  
type="checkbox" /> only describes the checkbox itself. You need to  
add the label around it with extra markup. The same goes for  
textfields: <input type="textfield" /> is the UI widget itself. The  
label, the description and most importantly: the <div class="form- 
item"> that conceptually groups what one would think of as "the form  
item" is all extra markup.

This is why we need form API: to have an abstraction layer that works  
on the level of form items, and not just individual widgets. It even  
goes beyond: thanks to attributes, we can add behaviours such as  
autocomplete and collapsable sections easily. They all involve  
significant extra work in the HTML, which is abstracted away.

Wrapping another layer around SQL on the other hand, is useless  
unless you actually abstract other things as well.

Steven Wittens

More information about the development mailing list