"Kur" wrote:

Что это: несоответствие процедурного "старичка" современному времени или что то другое?

Я бы не сказал, что Друпал процедурный: http://drupal.org/node/547518 С-ма именования ф-ий/переменных неудобная, это да.

"Crea" wrote:

Повторяю, конфигурация на продакшн сайте не должна изменяться минуя тестовые окружения.

Приведите пример хоть одного динамического сайта, где нет нужды конфигурировать сайт в процессе работы Сайты-визитки, которые один раз сделали и забыли, в расчет не берем.

Crea, я с вами согласен, что на этапе разработки могут возникнуть такие сложности (кто изменил конфигурацию, как откатиться к такой-то версии и т.д.). Т.е. если бы конфигурация хранилась в файлах, можно было бы задействовать с-му контроля версий.

Но давайте не будем смешивать разработку и работу готового сайта. На продакшене хранить конфигурацию в файлах - имхо, бред хотя бы из-за проблем с совместным использованием данных, для решения которых, собственно, и придуманы СУБД.

Crea, не совсем понимаю, в чем принципиальное отличие, где хранить конфигурацию - в коде или в БД? При развертывании и в том, и в другом случае нужно нечто скопировать на хост - только в одном случае это файлы, в другом - часть БД. Правда, я не понимаю, в чем принципиальная разница??

"Crea" wrote:

Вы хотите подвергнуть сомнению факт, что управлять конфигурацией из кода гораздо удобнее, чем плодить тонны говнокода в hook_update_N() и велосипеды с квадратными колесами (например, деплоймент с помощью диффа БД, который используется в некоторых проектах)?

Что вы имеете в виду под "конфигурацией из кода" и "деплойментом с помощью диффа БД"? И в каких проектах используется такой деплоймент?

Друпал вместо классических фреймворков используют по той же причине, что и Си вместо ассемблера В CMS нужно допиливать готовое + писать свое, с фреймворком - в основном писать свое. Зачем писать, если то, что уже накодировано в виде CMS - в основном устраивает? Другое дело, если CMS придется слишком много допиливать - тогда логичнее взять фреймворк.