Потому что в ограниченное время и с ограниченным человеческим ресурсом можно поднимать достаточно сложные по структуре и практически неограниченные по функионалу сайты. Ресурсы железа, правда, желательно чтобы тоже были неограниченные :) Но тут еще и от кривизны рук зависит.
Ну а можно за день-два клепать визитки по готовой схеме с неограниченным потенциалом для их дальнейшего развития. Ну и еще есть множество других кейсов.
Также следует отметить, что все это возможно только при условии обладания достаточными знаниями.
Ну а автор просто перечислил те изменения, которые нас ожидают в 8 версии по сравнению с 7, большинство из них не являются революционными ни для друпала (часть была реализована сторонними модулями), ни для некоторых других цмс, где возможно некоторый функционал уже реализован.
Что касается некоторых базовых функций, которые присутствуют в других цмс из коробки, а в друпале реализуются сторонними модулями. Это связано с особенностью разработки самого друпала, с его позиционированием и текущими тенденциями и требованиями к цмс.
Друпал изначально позиционировался как инструмент для гибкой разработки, когда каждый может взять готовое ядро, навесить на него необходимых модулей и настроить все окружение как душе угодно. Это в частности и отталкивает тех, кто привык сразу получать из коробки готовое решение, пусть и намного менее гибкое в плане дальнейшего наращивания функционала.
Каждая версия ядра выходила с некоторым набором стандартных модулей, которые реализовывали некий базовый функционал. Расширение функционала происходит за счет сторонних модулей, причем зачастую существует несколько решений одной задачи. Для следующей версии ядра из этих решений выбирается одно наиболее удачное и включается в ядро. Таким образом, сначала какой-то функционал реализуется сторонними разработчиками, а затем уже обкатанное и наиболее удачное решение допиливается основной командой.
Таким образом, в 8-й версии мы просто видим продолжение этого процесса, когда сторонние для 7 версии модули включаются в ядро. Требования к цмс с каждым разом все более повышаются, систему постепенно превращают из «цмс для разработчиков» в «комбайн для простых пользователей», постоянно наращивая базовый функционал.
Если в 7-й версии, например, речь о включении того же wysiwyg в ядро не шла (каждый разработчик сам выбирал, что ему больше по душе), то проанализировав ситуацию и определив, что подавляющее большинство устанавливает ckeditor, то было решено включить его в ядро.
Исходя из моего опыта, ckeditor (по крайней мере, 3-я версия) — наиболее стабильный, функциональный, производительный и предсказуемый из всех открытых wysiwyg-редакторов. Я прощупал их очень большое количество, долго сидел на tinymce и постоянно плевался, а альтернатив не было (тот же предшественник fck был жутко крив), пока не вышел ckeditor. После минимальной доводки, он работает прекрасно, редактора довольны предсказуемым поведением, мне как разработчику нравится, что можно спокойно добавлять любые стили и классы, и они никуда не пропадут из режима html source, ну и сам он не добавляет никакой отсебятины. Опять же повторюсь — в сравнении с остальными.
Часто приходится программировать модули и тут двоякая ситуация:
1. API самого друпала довольно неплохо документировано (я про официальную документацию на английском, как с русским переводом обстоят дела — не в курсе), у меня с ним проблем не возникало, модули пишутся на ура.
2. Если необходимо написать модуль к чему-нибудь за пределами базового API (например к Views) — то это, соглашусь, жопа: код весьма абстрактный, а документации к нему нет никакой.
Когда у вас появится опыт работы с полноценным кодовым фрэймворком, вы почувствуете, будто на кончиках ваших пальцев сосредоточена суперсила
Вот, например, при работе с RoR, постоянно ловил себя на мысли, что все время приходится велосипедить то, что в друпале уже давно сделано и конфигурится мышкой :) Сейчас у меня есть готовые настроенные установочные профили с нужным набором модулей. Любой фреймворк до такого состояния пилить и пилить.
Друпал подкупает свой возможностью решать сложные кастомные задачи на уровне кликов мышью, оставаясь при этом невероятно гибким для разработки, чего нет у других цмс. Но очень сложно делать деплой и поддерживать большое количество сайтов.
Тоже постоянно смотрю в сторону фреймворков, и постоянно останавливает мысль, что придется писать свой друпал на этом фреймворке :) Недостатков у 7 много, поэтому я с нетерпением смотрю в сторону 8.
Революция — в смене ядра с самописного процедурного, которому уже больше 10 лет, на ООП Симфони. По коду — это практически полностью новая система. Хранение конфигурации в файлах — просто как следствие этого. Для частичной совместимости с предыдущими версиями оставлены прослойки в виде хуков и т. п., поэтому по общему функционалу кажется, что вроде как ничего особо не изменилось. Но главные изменения — под капотом.
Новая версия позволит отбросить многие рудименты и развиваться вперед. А если делать сразу и новое ядро, и революционный функционал — то это уж очень трудозатратно, и мы бы новой версии никогда б не дождались, либо дождались бы новой цмс :)
А также можно сделать profiles/profile-1/modules/module-v1 и profiles/profile-2/modules/module-v2, что позволит использовать нужный набор модулей разным сайтам внутри одного инсталла.
Ах вот что это было! Мне сегодня от одного контакта такие сообщения приходили. Как-то скопом сразу по несколько штук, и судя по самим сообщениям — адресат их получал в нормальном режиме.
1. iPad
2. iPad 2
3. The New iPad
4. The New iPad with Retina display
5. iPad Air
Ну а можно за день-два клепать визитки по готовой схеме с неограниченным потенциалом для их дальнейшего развития. Ну и еще есть множество других кейсов.
Также следует отметить, что все это возможно только при условии обладания достаточными знаниями.
Ну а автор просто перечислил те изменения, которые нас ожидают в 8 версии по сравнению с 7, большинство из них не являются революционными ни для друпала (часть была реализована сторонними модулями), ни для некоторых других цмс, где возможно некоторый функционал уже реализован.
Что касается некоторых базовых функций, которые присутствуют в других цмс из коробки, а в друпале реализуются сторонними модулями. Это связано с особенностью разработки самого друпала, с его позиционированием и текущими тенденциями и требованиями к цмс.
Друпал изначально позиционировался как инструмент для гибкой разработки, когда каждый может взять готовое ядро, навесить на него необходимых модулей и настроить все окружение как душе угодно. Это в частности и отталкивает тех, кто привык сразу получать из коробки готовое решение, пусть и намного менее гибкое в плане дальнейшего наращивания функционала.
Каждая версия ядра выходила с некоторым набором стандартных модулей, которые реализовывали некий базовый функционал. Расширение функционала происходит за счет сторонних модулей, причем зачастую существует несколько решений одной задачи. Для следующей версии ядра из этих решений выбирается одно наиболее удачное и включается в ядро. Таким образом, сначала какой-то функционал реализуется сторонними разработчиками, а затем уже обкатанное и наиболее удачное решение допиливается основной командой.
Таким образом, в 8-й версии мы просто видим продолжение этого процесса, когда сторонние для 7 версии модули включаются в ядро. Требования к цмс с каждым разом все более повышаются, систему постепенно превращают из «цмс для разработчиков» в «комбайн для простых пользователей», постоянно наращивая базовый функционал.
Если в 7-й версии, например, речь о включении того же wysiwyg в ядро не шла (каждый разработчик сам выбирал, что ему больше по душе), то проанализировав ситуацию и определив, что подавляющее большинство устанавливает ckeditor, то было решено включить его в ядро.
Ну а какой редактор на ваш взгляд лучше?
1. API самого друпала довольно неплохо документировано (я про официальную документацию на английском, как с русским переводом обстоят дела — не в курсе), у меня с ним проблем не возникало, модули пишутся на ура.
2. Если необходимо написать модуль к чему-нибудь за пределами базового API (например к Views) — то это, соглашусь, жопа: код весьма абстрактный, а документации к нему нет никакой.
Вот, например, при работе с RoR, постоянно ловил себя на мысли, что все время приходится велосипедить то, что в друпале уже давно сделано и конфигурится мышкой :) Сейчас у меня есть готовые настроенные установочные профили с нужным набором модулей. Любой фреймворк до такого состояния пилить и пилить.
Новая версия позволит отбросить многие рудименты и развиваться вперед. А если делать сразу и новое ядро, и революционный функционал — то это уж очень трудозатратно, и мы бы новой версии никогда б не дождались, либо дождались бы новой цмс :)
доступными в share.yandex.ru?