I'm going to do some Bèr's praise here. I'm usually really strict about the DNRY personally. Though I use 3 instances as a clue that I'm going to need to split the code into a function. Continuing that train of thought, how many time have you had to do some sort of INSERT/UPDATE switch in you drupal code? I think Bèr is right on in suggesting we consider something like AR. It's a little more OO than drupal has been in the past do to overhead concerns but I'm not sure that applies here. Big +1 from me. James On 5/12/06, Bèr Kessels <ber@webschuur.com> wrote:
Op vrijdag 12 mei 2006 18:00, schreef Dries Buytaert:
I, for one, find it much easier to read an SQL statement than some (new) Drupal-specific table definition. I don't want to learn or use a such definition language. Such functions make the database scheme less transparent.
The agility! wonderfull ;)
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.
If we go for some DB abstraction layer, we should really, IMnsHO look at Active Record (PHP stuff at http://phplens.com/phpeverywhere/?q=node/view/228), wich does not take SQL away from developers but makes it easier to use. A Big Difference, IMO.
Whether we go for AR itself or some AR library, the central point should IMO be: "make it easier for developers to build sites".
Wich is far from "make a system in such a way that developers are pushed to build technical better system". Drupal, IMO is walking slowly towards the latter the way its going now. A pity, because it does not make things better. Only "technical better".
Bèr