[development] Extend database abstraction layer, to include table creation.

[James Walker]

On 13-May-06, at 5:51 AM, Dries Buytaert wrote:

>
> On 13 May 2006, at 00:17, Bèr Kessels wrote:
>> Serious: What Drupal needs above all, is not some "Higher Language  
>> To Talk To
>> Lower Languages", but a way to make stuff easier.
>>
>> IMveryHO forms api surpassed its goal in this: What is easier:  
>> calling
>> form_weight() or building an object-from-drupal-specific-arrays?  
>> Point is
>> clear.
>
> I agree.  While Drupal becomes more powerful, it also becomes more  
> difficult to develop for.
>
> Drupal 4.7's new forms API is a prime example.  It is obviously  
> great in terms of security and flexibility, but at the same time,  
> it is also _much_ harder to use than the old form API.  What does  
> that mean?  Well, that some people can make really fancy forms but  
> that the majority of the people will find it more difficult to make  
> basic forms.

I kinda disagree here - I find the keyed array's *much* easier to  
read and figure out how that's gonna translate... perhaps you were  
the one guy who could remember the function parameter order of the  
old "API"?

> This is somewhat problematic as we need more people that are good  
> Drupal developers.  There is such a strong demand for good Drupal  
> developers, yet which each new version, we add more barriers as a  
> side effect of making Drupal more powerful.  As a result, we'll get  
> many more users, but relatively fewer developers.  And that's a big  
> problem.

this I agree with.

> For most of us eliminating the various SQL schemas makes perfect  
> sense.  After all, most of us are expert Drupal developers, and as  
> such, an incremental improvement is easy enough to deal with.   
> However, for new Drupal developers, who are not intimate with  
> Drupal's code, this just increases the barrier.
>
> Why did you end up with Drupal to begin with?  Because it had an  
> extremely powerful API for every single problem?  Or because it was  
> clean code, easy to get into and make work?

I thought the project lead was cute.

> The web is built by millions of individuals, many of which are  
> amateurs. They continuously update, tweak and rebuild their  
> websites.  We want Drupal to remain accessible for them.

We do, absolutely. I don't think the proposed extensions are terribly  
complex ... and they *do* make it easier to read. If i can define my  
table /once/ and be reasonably assured that that definition is gonna  
magically work across DB platforms, that sounds much easier to read  
to me. Furthermore, if there is a bug on one of the platforms, it is  
more likely due to an incorrect translation in the DB layer, than my  
just never using system *foo* and not realizing it's SQL syntax  
variance.

> Hence, the challenge is to make Drupal more powerful _AND_ easier  
> to develop for.  This requires that we question certain development  
> directions and look at them through the eyes of amateurs.
>
>   http://buytaert.net/complexity-is-a-disease
>   http://buytaert.net/why-php-and-not-java

yup, which is why we don't do crap like XML definitions for tables...  
but something very simple and straightforward - that, however, gains  
us something very real.

my $0.02 (and i haven't read this whole thread yet... so I may well  
be repeating others).
--
James Walker :: http://walkah.net/ :: xmpp:walkah at walkah.net