[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