Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 110
Я уже читал этот перевод на хабре. Только вот никак не найду ссылку.
Может за этот перевод и отхабрили того кто попросил меня это опубликовать? :)
чтобы использовать полный рабочий день разработчиков
makes me sad
Замечу, что вместо Yii можно вписать codeigniter или свой MVC велосипед (если он достаточно качественен).
ZF, Kohana, CakePHP :) Классный фреймворков то хватает и большинство из них достаточно шустрые.
Да зачем. Свой велосипед будет самым велосипедным из всех велосипедов. Я думаю каждый разработчик проходит этот этап, который потом вспоминает с ухмылкой ) Ну кроме разработчиков ZF, Kohana, CakePHP и т.д. )
Это самое «и т.д.» тянется на сотни фреймворков, выросших из велосипедов.
superdit.com/2009/07/22/big-list-of-php-framework/
Да и на гитхабе в ТОП проектов есть несколько админок на RoR, тоже в своём роде велосипеды.
superdit.com/2009/07/22/big-list-of-php-framework/
Да и на гитхабе в ТОП проектов есть несколько админок на RoR, тоже в своём роде велосипеды.
Насчёт велосипеда крайне не согласен. У Yii очень хорошо продуманная OOP модель пронизанная Lazy Load механизмом — большинство фреймворков по продуманности и качеству реализации до Yii недотягивают — исключение это Symphony 2 р, но у неё немного другая ниша нежели у Yii. Zend тоже качественный, но он является конструктором и там напортачить крайне легко — это уже швейцарский нож — но как показывает практика мало кто им умеет действительно хорошо пользоваться.
Сodeigniter дает только скелет, и то, на костылях. Yii дает множество примочек из коробки, дающих быстро начать новый проект, но при этом не сковывающих при дальнейшей разработке:
1. ORM простой и хорошо интегрированный со многими компонентами
2. CRUD с возможностью кастомизации шаблонов
3. виджеты, покрывающие большую часть стандартных компонентов сайта
1. ORM простой и хорошо интегрированный со многими компонентами
2. CRUD с возможностью кастомизации шаблонов
3. виджеты, покрывающие большую часть стандартных компонентов сайта
Сравнивать CMS и фреймворк это мощно.
Ждём статью — почему я использую Windows вместо C++?
Ждём статью — почему я использую Windows вместо C++?
смею заметить что Drupal это CMF
Можно пруф?
вам нужна расшифровка термина CMF?
Сам Друпал так себя позиционирует — Content Management Framework.
Одно другому не мешает, друпал и CMS тоже.
Мне нравится Yii, часто пишу на нем различные интересные штуки.
Но для типовых сайтов (порталы, каталоги, etc) предпочитаю Drupal, несмотря на его код и проблемы с производительностью. Все потому, что эти типовые сайты обычно имеют небольшую посещаемость, а использование Drupal позволяет существенно ускорить их создание.
В общем, инструмент нужно выбирать под конкретную задачу, имхо.
Но для типовых сайтов (порталы, каталоги, etc) предпочитаю Drupal, несмотря на его код и проблемы с производительностью. Все потому, что эти типовые сайты обычно имеют небольшую посещаемость, а использование Drupal позволяет существенно ускорить их создание.
В общем, инструмент нужно выбирать под конкретную задачу, имхо.
Совершенно верно. Если нужно быстро — можно использовать Друпал, если нужно гибче — Yii, Kohana, CI, или любой другой фреймворк. Для каждой задачи есть свой инструмент.
Как руководитель команды которая специализируется на Yii, могу сказать, что с опытом и наработками разработка на Yii становится быстрее. Заготовленная сборка с админкой, нужными компонентами, управление контентом делает все очень быстрым (начиная от времени верстки шаблона)
В Drupal многое сделано для удобного управления через админку.
Если в фреймворке вы реализуете только то, что вам нужно, то это понятно будет работать быстрее. Если бы вы в том же фреймворе реализовали возможность управления через админку, то получилось бы точно также как в Drupal. Вот тогда можно было бы и сравнивать производительность.
Если в фреймворке вы реализуете только то, что вам нужно, то это понятно будет работать быстрее. Если бы вы в том же фреймворе реализовали возможность управления через админку, то получилось бы точно также как в Drupal. Вот тогда можно было бы и сравнивать производительность.
Управление чем в фреймворке вы хотите через админку?
Есть кодогенераторы(модели, контроллеры, формы), для yii есть модули, которые на основе модели реализуют админ-интерфейс, но в конечном итоге почти каждая админка пишется в зависимости от нужд заказчика/требований системы.
Есть кодогенераторы(модели, контроллеры, формы), для yii есть модули, которые на основе модели реализуют админ-интерфейс, но в конечном итоге почти каждая админка пишется в зависимости от нужд заказчика/требований системы.
Хороший кодогенератор в веб-интерфейсе, из шаблонов, может потянуть на админку.
Например, создание модуля «Новости». Создать таблицу — раз, создать админку — два, создвать шаблон из заготовки Заголовок&текст — три, создать контроллер и роутинг — четыре. Модель иногда не нужна, но если нужна — пять.
Оговорка — модель не нужна, когда мы кроме списка новостей и текста ничего не получаем и наша модель — просто экземпляр модели предоставлемой фреймфорком (как в RoR), и может быть создана автолоадером.
Например, создание модуля «Новости». Создать таблицу — раз, создать админку — два, создвать шаблон из заготовки Заголовок&текст — три, создать контроллер и роутинг — четыре. Модель иногда не нужна, но если нужна — пять.
Оговорка — модель не нужна, когда мы кроме списка новостей и текста ничего не получаем и наша модель — просто экземпляр модели предоставлемой фреймфорком (как в RoR), и может быть создана автолоадером.
Кстати, автор статьи в этом плане очень повеселил тем, что ругается на наличие ImageCache UI. Как будто кто-то ему мешает его отключить после окончания настройки/разработки сайта…
Не убедил.
Аргумент по поводу фичемании в Imagecache — это скорее анти-аргумент.
Вот что-что а генерация изображений и Друпала сделана просто отлично. Кроме того Необходимо всего 3 модуля: ImageAPI, ImageAPI ImageMagic (или GD) и ImageCache. ImageCache UI применяется только на начальном этапе, для задания необходимых типов изображений.
В целом Друпал похож на Линукс в плане модулей (зависимости и т.п.).
Вот что-что а генерация изображений и Друпала сделана просто отлично. Кроме того Необходимо всего 3 модуля: ImageAPI, ImageAPI ImageMagic (или GD) и ImageCache. ImageCache UI применяется только на начальном этапе, для задания необходимых типов изображений.
В целом Друпал похож на Линукс в плане модулей (зависимости и т.п.).
6. API полей/(CCK) в Drupal сведет вас с ума, и это часть ядра Drupal 7
Горизонтальные таблицы конечно быстрее, но вот с гибкостью проблемы возникнут с большой вероятностью.
Сравнивать $node->ip и $node->field_ip[0][‘value’] вообще нельзя, как хранить несколько значений? Да и $node->field_ip[0]['country'] например сделать нельзя.
Горизонтальные таблицы конечно быстрее, но вот с гибкостью проблемы возникнут с большой вероятностью.
Сравнивать $node->ip и $node->field_ip[0][‘value’] вообще нельзя, как хранить несколько значений? Да и $node->field_ip[0]['country'] например сделать нельзя.
только покакал в топике «За что я люблю Drupal», что он не «рыба не мясо», так тут вижу этот пост на глагне, мистика не иначе)))
Процитирую своего друга, технического директора немецкого бизнес фонда:
1. Программисту всегда интереснее (а потом уже проще и удобнее), написать свой велосипед нежели изучать документацию чужого (хоть и распространенного) продукта.
2. Для бизнеса важна скорость разворачивания решения и поддерживаемость. А если проект написан одним человеком (не важно с применением какого средства: будь то язык программирования или библиотека), бизнес становится заложником такого работника. В некоторых случаях имеются риски неоправданного увеличения фонда заработной платы из за того что бизнес может остановится если данный человек уйдёт здесь и сейчас (зарплатный шантаж).
3. Если ваша команда до сих пор использует Apache, а не nginx в высоко-нагруженных проектах и не знает как разгрузить сервера с помошью кэширования используя технологии memcached и varnish, то от таких работников стоит немедленно избавляться. Так как не зная основ они в большинстве случаев умеют только много говорить не читав не одной специализированной книги.
От себя добавлю, Drupal 5 отличается от Drupal 7 как гужевая повозка от Lamborghini Diablo. Но к моему великому сожалению все желающие высказаться на тему Drupal ссылаются на Drupal 5 и при этом не один ни разу не открывал «книгу знаний Druapl»: Pro Drupal Development (в данный момент Pro Drupal Development 7). А спорить о знаниях, не познав их (не прочитав «книгу знаний Druapl») значит просто разводить флуд.
P.S.: Стоимость поддержки drupal доходит до 200$ в час, если бы эффективно было использовать другую технологию, то цены не доходили бы до таких высот.
1. Программисту всегда интереснее (а потом уже проще и удобнее), написать свой велосипед нежели изучать документацию чужого (хоть и распространенного) продукта.
2. Для бизнеса важна скорость разворачивания решения и поддерживаемость. А если проект написан одним человеком (не важно с применением какого средства: будь то язык программирования или библиотека), бизнес становится заложником такого работника. В некоторых случаях имеются риски неоправданного увеличения фонда заработной платы из за того что бизнес может остановится если данный человек уйдёт здесь и сейчас (зарплатный шантаж).
3. Если ваша команда до сих пор использует Apache, а не nginx в высоко-нагруженных проектах и не знает как разгрузить сервера с помошью кэширования используя технологии memcached и varnish, то от таких работников стоит немедленно избавляться. Так как не зная основ они в большинстве случаев умеют только много говорить не читав не одной специализированной книги.
От себя добавлю, Drupal 5 отличается от Drupal 7 как гужевая повозка от Lamborghini Diablo. Но к моему великому сожалению все желающие высказаться на тему Drupal ссылаются на Drupal 5 и при этом не один ни разу не открывал «книгу знаний Druapl»: Pro Drupal Development (в данный момент Pro Drupal Development 7). А спорить о знаниях, не познав их (не прочитав «книгу знаний Druapl») значит просто разводить флуд.
P.S.: Стоимость поддержки drupal доходит до 200$ в час, если бы эффективно было использовать другую технологию, то цены не доходили бы до таких высот.
P.S.: Стоимость поддержки drupal доходит до 200$ в час, если бы эффективно было использовать другую технологию, то цены не доходили бы до таких высот.
уж не потому ли, что бизнес стал заложником друпала? ))
Программисту всегда интереснее (а потом уже проще и удобнее), написать свой велосипед нежели изучать документацию чужого (хоть и распространенного) продукта.
Дело в том, что всё нетривиальное на друпале — это как раз и есть написание велосипеда, причём в извращённой форме (в виде «подпорок»-хуков).
Ну вот такая методология/философия друпала — «Я делаю так. Не нравится? Напиши хук!». Она имеет право быть, пока таких подпорок не слишком много. А потом это уже действительно становится «карточным домиком» подпёртым хуками/настройками/модулями со всех сторон, и требующим поддержки всего этого за 200$ в час.
Кстати, для меня, пример идеального сайта на друпале — sportbox.ru
Посещалка в несколько раз больше, чем у сайта про который в статье.
Дело в том, что всё нетривиальное на друпале — это как раз и есть написание велосипеда, причём в извращённой форме (в виде «подпорок»-хуков). — Аминь! — на эту тему как раз и писал в топике о друпалофильстве.
С Yii что-то никак не получается познакомиться поближе — все хвалят, но свой велосипед пока устраивает (увы, Yii пока прийдется подождать)
С Yii что-то никак не получается познакомиться поближе — все хвалят, но свой велосипед пока устраивает (увы, Yii пока прийдется подождать)
К сожалению не все PHP программисты понимают принцип действия хуков и откуда это пришло (библиотеки *.dll и *.so работают на основе тех же принципов, в drupal библиотеки — модули).
У меня на одном проекте вообще обсчёт производится на видеокарте ч использованием pascal, а drupal служит для визуализации данных. Потому что при оценке стоимости затрат человеко часов это было наиболее удачное соотношение цены и качества. В разных ситуациях нужны разные решения.
У меня на одном проекте вообще обсчёт производится на видеокарте ч использованием pascal, а drupal служит для визуализации данных. Потому что при оценке стоимости затрат человеко часов это было наиболее удачное соотношение цены и качества. В разных ситуациях нужны разные решения.
Вы дважды упомянули хуки в странном контексте подпорок. Хуки в Drupal это обработчики сообщений event-driven архитектуры. Может вы просто не представляете себе насколько это эффективное решение, что делаете столь странные заключения. Могу лишь посоветовать познакомиться с понятиями перед тем, как их критиковать.
Думаю имеются в виду случаи частого использования хуков для мелких изменений поведения разных частей системы, чтобы достичь нужного эффекта. Нужно скрыть в форме поле — пиши form_alter, нужно на какой-то странице поменять заголовок — изгаляйся с nodeapi или form_alter или template.php, нужно увеличить maxlength у title в формах — form_alter и т. д.
Понятно, вы просто не понимаете концепции. То есть вы хотите сказать, что формы вы привыкли править в источнике? Патчить ядро, если это форма ядра? Изменить форму в модуле это для вас нелепость или кощунство? У Drupal такая архитектура, что хуками в модулях обозначаются перехваты определенных операций. В сравнении с механизмом, к которому вы привыкли это «та же жопа только в профиль».
Поменять заголовок можно не только хуком, но и соответствующим node--type.tpl.php, который никакого отношения к хукам не имеет. Да и вообще ваше отношение к хукам выглядит каким-то суеверным ужасом, хотя выше вы показали, что знаете что требуется для регистрации модуля в движке, но напрочь отрицаете событийную архитектуру.
Ей богу, вы самый странный программист из встреченных мною за долгую профессиональную жизнь.
Поменять заголовок можно не только хуком, но и соответствующим node--type.tpl.php, который никакого отношения к хукам не имеет. Да и вообще ваше отношение к хукам выглядит каким-то суеверным ужасом, хотя выше вы показали, что знаете что требуется для регистрации модуля в движке, но напрочь отрицаете событийную архитектуру.
Ей богу, вы самый странный программист из встреченных мною за долгую профессиональную жизнь.
Мне часто, чтобы достичь нужного эффекта приходится писать модули-«хаки» в котором хуки с кучей мелких фиксов. А кто не умеет писать модули, те ищут готовые модули для каждого чиха. В последнее время я даю название таким модулям имя_tweaks. И получается в одном модуле куча разной функциональности не связанной никакой логикой. Можно конечно разбивать на кучу модулей, но получится куча мелких «однострочных» модулей.
Не путайте свои недостатки с чужими достоинствами. Тем более что вы просто не поняли что то, что подразумевается под хуками в Drupal, не имеет никакого отношения к вашим костылям.
Я написал десятки модулей разной сложности для десятков сайтов. Бывают модули с чёткой и понятной функциональностью, а бывают и вот такие:
<?php
function XXX_form_alter($form_id, &$form) {
// в базе программ ДПО скрываем у фильтра «подразделение» пункт «пусто»
if ($form_id == 'views_filters' && $form['#view_name'] == 'dpo') {
unset($form['filter1']['#options'][0]);
}
}
?>
Это весь модуль. Прячет у представления (view) в фильтре пункт «пусто», который через админку не скрывается. Вроде бы и хорошо, что есть возможность это сделать без изменения ядра и достаточно просто, но что-то здесь не так имхо, хотя я и привык.
Для этой же view в template.php +15 строчек, чтобы просто добавить class к table. И еще много строчек, чтобы URL сделать ссылкой в таблице (не ставя для этого модуль на сотни строк кода). Тоже уже привык к такому.
<?php
function XXX_form_alter($form_id, &$form) {
// в базе программ ДПО скрываем у фильтра «подразделение» пункт «пусто»
if ($form_id == 'views_filters' && $form['#view_name'] == 'dpo') {
unset($form['filter1']['#options'][0]);
}
}
?>
Это весь модуль. Прячет у представления (view) в фильтре пункт «пусто», который через админку не скрывается. Вроде бы и хорошо, что есть возможность это сделать без изменения ядра и достаточно просто, но что-то здесь не так имхо, хотя я и привык.
Для этой же view в template.php +15 строчек, чтобы просто добавить class к table. И еще много строчек, чтобы URL сделать ссылкой в таблице (не ставя для этого модуль на сотни строк кода). Тоже уже привык к такому.
Я написал десятки модулей разной сложности для десятков сайтов. Бывают модули с чёткой и понятной функциональностью, а бывают и вот такие:
…
Это весь модуль.
А я весь этот набор мелких правок под конкретный сайт, которые больше нигде не пригодятся объединяю в один модуль, который обычно и называл именем сайта. В последнее время для большей гибкости этот модуль имеет машинное название «zzz», чтобы было проще рефакторить. Ничего предосудительного в таком подходе не нахожу.
Для этой же view в template.php +15 строчек, чтобы просто добавить class к table.
Правильнее в рамках идеологии Drupal скопировать из модуля views в свою тему файлик views-view-table.tpl.php и вписать туда все свои хотелки прямо в html часть.
И еще много строчек, чтобы URL сделать ссылкой в таблице (не ставя для этого модуль на сотни строк кода).
Бедняжечка. Вот что с людьми лень делает. Ну прочти же ты доку по themeing один раз. тот же файлик темы views-view-table.tpl.php с включением простого ветвления даст тебе это сделать просто и элегантно. И, кстати, более производительно.
Иногда дешевле платить за час 200$ чем держать своего работника
Допустим, гипотетическая ситуация.
А если:
1. и 2. У велосипеда есть документация. Хорошая.
Новые работники обучаются работе с наскока, т.к. используются подходы из других MVC фреймфорков и простое API. Есть ряд случаев, когда другие работники дорабатывали систему.
3. Работник читал специализированные книги и его велосипед побыстрее чем ZF и CakePHP, да и nginx используется в компании.
Тогда использование велосипедов, если следовать вышеуказанным причинам, становится не таким уж плохим решением.
В качестве плюса — под боком человек, который разбирается в системе чуть более чем полностью. Это как для разработки проекта на RoR нанять DHH
А если:
1. и 2. У велосипеда есть документация. Хорошая.
Новые работники обучаются работе с наскока, т.к. используются подходы из других MVC фреймфорков и простое API. Есть ряд случаев, когда другие работники дорабатывали систему.
3. Работник читал специализированные книги и его велосипед побыстрее чем ZF и CakePHP, да и nginx используется в компании.
Тогда использование велосипедов, если следовать вышеуказанным причинам, становится не таким уж плохим решением.
В качестве плюса — под боком человек, который разбирается в системе чуть более чем полностью. Это как для разработки проекта на RoR нанять DHH
> Новые работники обучаются работе с наскока
В этом проблема. Что объективно оценить и найти специалиста под что то известное понятное проще, чем искать кого то кто чего там где то умеет. Это жесть.
> У велосипеда есть документация. Хорошая.
Но в некоторых случаях когда решения нестандартное, то
В этом проблема. Что объективно оценить и найти специалиста под что то известное понятное проще, чем искать кого то кто чего там где то умеет. Это жесть.
> У велосипеда есть документация. Хорошая.
Но в некоторых случаях когда решения нестандартное, то
Пардон запостил рано.
> У велосипеда есть документация. Хорошая.
Тогда мы выходим на уровень библиотек, Вы же свой PHP и Linux не пишите. Тут всё зависит от задач. Тот же Yii можно запаковать в модуль и вынести логику в него, используя Drupal как визуализатор.
Тогда мы выходим на уровень библиотек, Вы же свой PHP и Linux не пишите. Тут всё зависит от задач. Тот же Yii можно запаковать в модуль и вынести логику в него, используя Drupal как визуализатор.
это уже извращение, простите
Товарищ тогда ненужно использовать всё вокруг, в горы добывать медь строить свой компьютер писать для него ОС и свою реализацию PHP и свой Yii, а то вдруг там что то идеологически неправильно :))))
На самом деле всё зависит от задачи и возможностей её решения при максимально эффективном соотношении цена / качество.
На самом деле всё зависит от задачи и возможностей её решения при максимально эффективном соотношении цена / качество.
Огромный минус велосипедов — отсутствие сообщества.
Документация-документацией, а жизнь никто не отменял.
Документация-документацией, а жизнь никто не отменял.
Перечислили все проблемы менеджмента и ни одной drupal или yii.
А вообще, несмотря на мои комментарии, я друпал люблю.
Если надо что-то сделать, и я понимаю что для того чтоб это сделать достаточно включить в друпале Views, CCK и Path, то я это сделаю на друпале (особенно если на сайте не предвидится сложных форм, расширения функционала и т.п.).
Темизация только головная боль… Каждый раз обнаруживаю в ней очередной подводный камень для себя.
Если надо что-то сделать, и я понимаю что для того чтоб это сделать достаточно включить в друпале Views, CCK и Path, то я это сделаю на друпале (особенно если на сайте не предвидится сложных форм, расширения функционала и т.п.).
Темизация только головная боль… Каждый раз обнаруживаю в ней очередной подводный камень для себя.
Друпал — это былдокод. В нем полно велосипедлв и кода, написанного людьми, которые никогда не слышали слова вроде ORM, MVC и пытаются вместо этого изобрести собственные велосипеды. Я в общем-то ничего не имею против велосипедов (ведь не факт, что авторы других фреймворков умнее вас и пишут лучший код), но только когда они адекватные, а не уровня студента, который пишет первый в своей жизни проект.
В Друпале нет нормальной организации кода. Разработчики не способны даже разбить его на статические классы, все сделано функциями, раскиданным по файлам. Автолоадинг в такой ситуации, как вы понимаете, не работает, потому надо как-то самому догадываться, где поставить require. Авторам Друпала видимо это надоело, и они тупо свалили основный функции в файл с говорящим названием common.inc и весом под 300 Кб. Когда я открываю этот файл в редакторе кода, бегунок полосы прокрутки становится таким маленьким, что в него не попасть мышью. Посмотрите список функций (225 штук) в нем — в кучу свалены абсолютно никак не связанные друг с другом вещи.
Чего стоит именование файлов и папок: какие-то странные расширения inc (wtf?), буссмысленные названия папок типа includes (а, что, из других папок файлы инклюдить нельзя?). В лучших традициях криво-CMS типа амиро или битрикс — все свалено в кучу без всякой логики. Если разработчики не могут организовать свой код и систему файлов, что уж говорить об остальном.
Архитектура использует так называемые хуки. Надеюсь, мне не надо пояснять, что это самый неграмотный способ из всех, которые только можно представить. Чего стоит только хук, позволяющий переписывать SQL-запросы перед их выполнением (!). Расскажите мне кто-нибудь, как вообще это можно использовать? Сколько кода надо написать, что бы полноценно анализировать Sql-запросы и тем более править их на лету? И сколько ошибок потом у вас окажется в таком коде? Ну и туда же идут такие же кривые хуки типа form_alter (парни, в нормальном фреймворке вы либо расширяете объект с формой, либо если речь о внешнем виде, то наследуете/переписываете шаблон этой формы, а не ковыряетесь в пяти мерном массиве). Что касается хуков типа js_alter/css_alter — опять же, умные ребята просто делают систему шаблонов/виджетов и про сборке страницы автоматически учитывают все зависимости. Ну или хотя бы берут уже готовый XSLT — через него можно шаблоны хоть наизнанку выворачивать.
Разработчики Друпала не слышали про ООП. Они, судя по коду, не знают, что такое ORM, repositiry и прочие умные слова из Java-мира. Они не могут организовать систему сущностей и связей и разделить код на слои. Они вместо этого пишут SQL-запросы прямо в функциях (опять же в лучших традициях систем типа Битрикс) и строят какие-то свои запутанные велосипеды, типа их системы нод. И какие-то странные системы маппинга в базу данных, где все раскидано по разным таблицам и колонкам, так что надо выбирать несколькими запросами.
API Друпала — отдельная кривая вещь. Хотите получить ноду по id? В руководстве АПИ прямо написано, что для этого лучше использовать прямые запросы, так как метод АПИ выбирает много данных и медленно работает.
Не редкость запросы типа
SELECT s.lid, t.translation, s.version FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.source = :source AND s.context = :context AND s.textgroup = 'default'
(запрос из locale.module, видимо для перевода строк). Для незнакомых с MySQL объясняю — при переводе строки мало того, что Друпал делает запрос в БД (да еще и с джойном, чтобы не отпимизировался), так еще и с поиском по текстовому (до 65536 символов) полю source. Любой человек, кто прочел хотя бы полглавы мануала по MySQL будет за такое бить монитором по голове. Gettext герои-друпаловцы решили побрезговать, что нам стоит каждую строчку из БД выдергивать.
Я уж молчу, что в нем нет ни моделек, ни ORM, ни валидаторов, ни нормальной работы с формами, ни системы views/widgets, ни наследуемых шаблонов, ни контроллеров, ни MVC, вообще ничего, чем все прогрессивное человечество пользуется в последние 10 лет.
Но может быть, код не очень, но зато у него удобный и юзабельный интефейс? Ха, даже опытный разработчик не сразу разберется в дебрях админки (шаблон у нее сделали симпатичный, а вот навигация по прежнему запутанная).
В общем, с точки зрения разработчика, лучшее, что можно сделать с Друпалом — отправить на свалку истории. Искренне не понимаю, что побуждает людей его использовать.
В Друпале нет нормальной организации кода. Разработчики не способны даже разбить его на статические классы, все сделано функциями, раскиданным по файлам. Автолоадинг в такой ситуации, как вы понимаете, не работает, потому надо как-то самому догадываться, где поставить require. Авторам Друпала видимо это надоело, и они тупо свалили основный функции в файл с говорящим названием common.inc и весом под 300 Кб. Когда я открываю этот файл в редакторе кода, бегунок полосы прокрутки становится таким маленьким, что в него не попасть мышью. Посмотрите список функций (225 штук) в нем — в кучу свалены абсолютно никак не связанные друг с другом вещи.
Чего стоит именование файлов и папок: какие-то странные расширения inc (wtf?), буссмысленные названия папок типа includes (а, что, из других папок файлы инклюдить нельзя?). В лучших традициях криво-CMS типа амиро или битрикс — все свалено в кучу без всякой логики. Если разработчики не могут организовать свой код и систему файлов, что уж говорить об остальном.
Архитектура использует так называемые хуки. Надеюсь, мне не надо пояснять, что это самый неграмотный способ из всех, которые только можно представить. Чего стоит только хук, позволяющий переписывать SQL-запросы перед их выполнением (!). Расскажите мне кто-нибудь, как вообще это можно использовать? Сколько кода надо написать, что бы полноценно анализировать Sql-запросы и тем более править их на лету? И сколько ошибок потом у вас окажется в таком коде? Ну и туда же идут такие же кривые хуки типа form_alter (парни, в нормальном фреймворке вы либо расширяете объект с формой, либо если речь о внешнем виде, то наследуете/переписываете шаблон этой формы, а не ковыряетесь в пяти мерном массиве). Что касается хуков типа js_alter/css_alter — опять же, умные ребята просто делают систему шаблонов/виджетов и про сборке страницы автоматически учитывают все зависимости. Ну или хотя бы берут уже готовый XSLT — через него можно шаблоны хоть наизнанку выворачивать.
Разработчики Друпала не слышали про ООП. Они, судя по коду, не знают, что такое ORM, repositiry и прочие умные слова из Java-мира. Они не могут организовать систему сущностей и связей и разделить код на слои. Они вместо этого пишут SQL-запросы прямо в функциях (опять же в лучших традициях систем типа Битрикс) и строят какие-то свои запутанные велосипеды, типа их системы нод. И какие-то странные системы маппинга в базу данных, где все раскидано по разным таблицам и колонкам, так что надо выбирать несколькими запросами.
API Друпала — отдельная кривая вещь. Хотите получить ноду по id? В руководстве АПИ прямо написано, что для этого лучше использовать прямые запросы, так как метод АПИ выбирает много данных и медленно работает.
Не редкость запросы типа
SELECT s.lid, t.translation, s.version FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.source = :source AND s.context = :context AND s.textgroup = 'default'
(запрос из locale.module, видимо для перевода строк). Для незнакомых с MySQL объясняю — при переводе строки мало того, что Друпал делает запрос в БД (да еще и с джойном, чтобы не отпимизировался), так еще и с поиском по текстовому (до 65536 символов) полю source. Любой человек, кто прочел хотя бы полглавы мануала по MySQL будет за такое бить монитором по голове. Gettext герои-друпаловцы решили побрезговать, что нам стоит каждую строчку из БД выдергивать.
Я уж молчу, что в нем нет ни моделек, ни ORM, ни валидаторов, ни нормальной работы с формами, ни системы views/widgets, ни наследуемых шаблонов, ни контроллеров, ни MVC, вообще ничего, чем все прогрессивное человечество пользуется в последние 10 лет.
Но может быть, код не очень, но зато у него удобный и юзабельный интефейс? Ха, даже опытный разработчик не сразу разберется в дебрях админки (шаблон у нее сделали симпатичный, а вот навигация по прежнему запутанная).
В общем, с точки зрения разработчика, лучшее, что можно сделать с Друпалом — отправить на свалку истории. Искренне не понимаю, что побуждает людей его использовать.
ровно одна причина — привычка
Я конечно понимаю что с большой степенью вероятности вы троллите, и аргументы не возымеют действия, но все-таки:
1. По поводу организации кода здравые мысли и вас есть, но дело в том что «ручной» require делать надо очень редко. А пассажи про про расширения и папки просто смешны.
2. ООП vs. СОП (событийно-ориентированное программирование). Т.е. хуки, если отбросить «маркетинговую» шелуху ООП, то события не так уж и плохи. К примеру form_alter очень гибок, тут и валидаторы и изменение формы и другие «плюшки». Хуков js_alter и css_alter нет в природе, шаблонизируется все отлично.
3. API — ваши ремарки по поводу документации высосаны из пальца. Если вам надо получить полностью собранную ноду, используйте предоставленную функцию. Для получения ограниченных данный никто конечно же не мешает использовать прямой запрос.
В качестве резюме могу сказать — еще один не разобравшийся, и пытающийся применить чуждую идеологию.
И знаете что самое плохое? Мне доводилось дорабатывать проекты на друпале сделанные вот такими не разобравшимися. Я представляю как они плевались занимаясь этим сайтом, так как все было сделано чрезвычайно нелогично в свете концепции друпала, что лучше бы они и не брались.
1. По поводу организации кода здравые мысли и вас есть, но дело в том что «ручной» require делать надо очень редко. А пассажи про про расширения и папки просто смешны.
2. ООП vs. СОП (событийно-ориентированное программирование). Т.е. хуки, если отбросить «маркетинговую» шелуху ООП, то события не так уж и плохи. К примеру form_alter очень гибок, тут и валидаторы и изменение формы и другие «плюшки». Хуков js_alter и css_alter нет в природе, шаблонизируется все отлично.
3. API — ваши ремарки по поводу документации высосаны из пальца. Если вам надо получить полностью собранную ноду, используйте предоставленную функцию. Для получения ограниченных данный никто конечно же не мешает использовать прямой запрос.
В качестве резюме могу сказать — еще один не разобравшийся, и пытающийся применить чуждую идеологию.
И знаете что самое плохое? Мне доводилось дорабатывать проекты на друпале сделанные вот такими не разобравшимися. Я представляю как они плевались занимаясь этим сайтом, так как все было сделано чрезвычайно нелогично в свете концепции друпала, что лучше бы они и не брались.
ППКС
Полностью согласен.
Человек пытается своё полное непонимание всей архитектуры свалить в узкий круг своих отрывочных знаний о хорошем и плохом.
И действительно, потом сложно чистить прямые запросы, людей не знающих основ API :).
Человек пытается своё полное непонимание всей архитектуры свалить в узкий круг своих отрывочных знаний о хорошем и плохом.
И действительно, потом сложно чистить прямые запросы, людей не знающих основ API :).
Трудно понять архитектуру, безуспешно пытаясь найти нормальную документацию.
На drupal.org с его адресами вида node/1234567 — неудобно. Ищешь по-русски (надеясь быстрее понять) — натыкаешься на какой-нибудь drupal.ru, который по сути — форум, где одни чайники спрашивают совета у других.
Гуглишь описание какой-либо проблемы — натыкаешься на куски php-кода, которые непонятно, куда засунуть.
Бардак, в общем.
Как быть?
После друпала даже документация к перловым фреймворкам Catalyst и Mojolicious (а там всё ой как непросто) кажется простой, понятной и логичной.
На drupal.org с его адресами вида node/1234567 — неудобно. Ищешь по-русски (надеясь быстрее понять) — натыкаешься на какой-нибудь drupal.ru, который по сути — форум, где одни чайники спрашивают совета у других.
Гуглишь описание какой-либо проблемы — натыкаешься на куски php-кода, которые непонятно, куда засунуть.
Бардак, в общем.
Как быть?
После друпала даже документация к перловым фреймворкам Catalyst и Mojolicious (а там всё ой как непросто) кажется простой, понятной и логичной.
Вся основная документация: drupal.org/documentation (довольно исчерпывающе). Всё новое — да согласен, развитие очень и очень динамичное и не всегда поспевает…
node/1234567 вообще замечательно. всегда можно послать на нужный адрес #, не заботясь о том, что при очередной перестройке системы адресов всё потеряется.
drupal.ru — диагноз :) его нужно воспринимать как он есть. Кроме него полно отличных блогов, в которых практически все основные проблемы разобраны.
Очень сложно сравнивать небольшие классовые фреймворки и что-то подобное drupal. Drupal имеет >10к модулей, несколько систем шаблонизвции(смарти, твиг и т.д.), и несколько вариантов построения структуры сайта блоками, panels и т.д. В любом месте и можно найти как минимум 3-4 варианта решения. а количество комбинаций решений сложно описать.
Для начинающих, я бы советовал content-management-systems.info по пунктам прочитать. А так, имея очень продолжительные опыт работы с Drupal (давно за 100 проектов), практически каждый новый сайт начинаешь делать по новому, с учётом предыдущего опыта и знаний.
Удачи вам!
node/1234567 вообще замечательно. всегда можно послать на нужный адрес #, не заботясь о том, что при очередной перестройке системы адресов всё потеряется.
drupal.ru — диагноз :) его нужно воспринимать как он есть. Кроме него полно отличных блогов, в которых практически все основные проблемы разобраны.
Очень сложно сравнивать небольшие классовые фреймворки и что-то подобное drupal. Drupal имеет >10к модулей, несколько систем шаблонизвции(смарти, твиг и т.д.), и несколько вариантов построения структуры сайта блоками, panels и т.д. В любом месте и можно найти как минимум 3-4 варианта решения. а количество комбинаций решений сложно описать.
Для начинающих, я бы советовал content-management-systems.info по пунктам прочитать. А так, имея очень продолжительные опыт работы с Drupal (давно за 100 проектов), практически каждый новый сайт начинаешь делать по новому, с учётом предыдущего опыта и знаний.
Удачи вам!
Может быть вы правы и большинство не умеют его готовить. Возможно я просто не понял Друпал и от того испытал радость и вдохновение начав использовать Рельсы.
Но факт, что тех кто понял Друпал очень мало. Их сложно найти и они дорого стоят. И еще и не хотят работать в офисе)
В итоге все равно получаем, что использовать Друпал в больших кастомных проектах просто не выгодно.
Но факт, что тех кто понял Друпал очень мало. Их сложно найти и они дорого стоят. И еще и не хотят работать в офисе)
В итоге все равно получаем, что использовать Друпал в больших кастомных проектах просто не выгодно.
Но факт, что тех кто понял Друпал очень мало. Их сложно найти и они дорого стоят. И еще и не хотят работать в офисе)
В итоге все равно получаем, что использовать Друпал в больших кастомных проектах просто не выгодно.
Притянуто за уши.
Ну бытует у начинающих такое мнение, что проще и главное дешевле и быстрее написать собственный велик. Ну возможно если использовать инструменты из новой и красивой коробки.
Но после первых шишек наступает отрезвление, а после подсчёта вложены в этот велик денежных средств — получается что он в разы дороже хорошего порша выходит.
Рынок отлично расставляет все CMS, CMF, фреймворки и свои велики по местам…
Но после первых шишек наступает отрезвление, а после подсчёта вложены в этот велик денежных средств — получается что он в разы дороже хорошего порша выходит.
Рынок отлично расставляет все CMS, CMF, фреймворки и свои велики по местам…
До этого момента мне казалось, что вы знакомы с Drupal
Но после, извините, ваши слова перестали восприниматься как адекватные. Ну что ж, раз вы не знаете ничего про event-driven архитектуру, то не в теме о Drupal ее и объяснять, но если вы не увидели в Drupal своего ORM, архитектура которого и позволяет переписывать запросы, то какой смысл с вами общаться, если вы просто выдумываете аргументы от незнания?
Слова ярого «тупоконечника» у которого «остроконечники» виноваты в том, что бьют яйцо не с той стороны. Хотите пользоваться XSLT и подхватывать налету несуществующие css/js файлы, ваше право, а разработчики Drupal дали разработчику любого модуля изменять логику генерации страницы задавая динамически наследование логики. Я бы с удовольствием посмотрел бы как вы гоняли один объект, той же формы, через 20 модулей (только паре из которых нужно эту форму трогать) добавляя и меняя его свойства. Если считаете, что event-driven способ делать модульность хуже, чем многократные наследования или полный конвейер обработки каждой сущности, то попробуйте это как-то проиллюстрировать что ли.
Тут вы путаете теплое с мягким. Функция node_load() загружает результат прохода через все хуки, модифицирующие node, а прямой запрос достанет только то, что вы в него внесете без учета данных, добавленных другими модулями. То есть вы рискуете вообще отключить работу сторонних модулей в этом действии. Для некоторых задач оптимизации это имеет смысл, но в основном ничего кроме проблем и багов не сулит. Перед тем как критиковать этот подход дайте себе отчет, что вы просто не хотите соблюдать правила, и нарушая их получаете предсказуемые проблемы.
Первый достойный пример недостатков drupal. Конечно про gettext вы вспомнили, учтя возможность вносить перевод для неограниченного числа языков через админку? Решение разработчиков drupal и меня в свое время огорчило, хотя я пошел немного дальше, чем вы и обнаружил в коде и другой запрос
Надо ли объяснять, что это означает, что некоторые переводы загружаются (вы сами устанавливаете какие руководствуясь длинной для удобного распределения оперативной памяти) одним запросом? Кстати это может оказаться производительнее, чем gettext и одновременно гибче. Но беда, которую вы разглядели грозит тем, у кого variable_get('locale_cache_length', 75) вернет что-то близкое к нулю. Если вы считаете, что этот механизм при его гибкости не имеет права на существование, то пожалуйста аргументируйте, мне действительно интересно узнать что-то более эффективное и одновременно удобное.
Тут вы явно спорите о вкусах. ORM и валидаторы есть, просто они отвечают не привычным для вас потребностям. (Кстати отрицать существование ORM в продукте где один код используется минимум для трех заявленных СУБД, это слегка необдуманно на мой взгляд). Идея моделей не используется поскольку противоречит некоторым избранным стратегическим решениям, не хочу на этом заострять, вы можете найти это в словах самих разработчиков. Шаблоны Drupal реализуют совсем другую концепцию нежели Django. И вместо вертикального наследования они усилены горизонтальным. Вряд ли привычные вам шаблонизаторы дают возможность модулям влиять на рендеринг целых классов элементов страницы вне зависимости от даже используемой темы. Советую познакомиться с этой системой хотя бы для «общего развития», чтобы раздвинуть рамки узкого понимания шаблонизации. Опять же вызвано это неимоверной гибкостью. Причем «прогрессивное человечество» скорее всего еще будет иметь возможность оценить эту гибкость по мере последующего роста производительности серверов, а сейчас это просто футуристические эксперименты, имеющие полное на мой взгляд право на существование с учетом хорошего кеширования. И зря вы пытаетесь натянуть новые идеи на старый опыт. Это так же неэффективно, как оценивать Erlang с точки зрения парадигмы PHP.
Расскажите мне кто-нибудь, как вообще это можно использовать? Сколько кода надо написать, что бы полноценно анализировать Sql-запросы и тем более править их на лету?
Но после, извините, ваши слова перестали восприниматься как адекватные. Ну что ж, раз вы не знаете ничего про event-driven архитектуру, то не в теме о Drupal ее и объяснять, но если вы не увидели в Drupal своего ORM, архитектура которого и позволяет переписывать запросы, то какой смысл с вами общаться, если вы просто выдумываете аргументы от незнания?
Ну и туда же идут такие же кривые хуки типа form_alter (парни, в нормальном фреймворке вы либо расширяете объект с формой, либо если речь о внешнем виде, то наследуете/переписываете шаблон этой формы, а не ковыряетесь в пяти мерном массиве). Что касается хуков типа js_alter/css_alter — опять же, умные ребята просто делают систему шаблонов/виджетов и про сборке страницы автоматически учитывают все зависимости. Ну или хотя бы берут уже готовый XSLT — через него можно шаблоны хоть наизнанку выворачивать.
Слова ярого «тупоконечника» у которого «остроконечники» виноваты в том, что бьют яйцо не с той стороны. Хотите пользоваться XSLT и подхватывать налету несуществующие css/js файлы, ваше право, а разработчики Drupal дали разработчику любого модуля изменять логику генерации страницы задавая динамически наследование логики. Я бы с удовольствием посмотрел бы как вы гоняли один объект, той же формы, через 20 модулей (только паре из которых нужно эту форму трогать) добавляя и меняя его свойства. Если считаете, что event-driven способ делать модульность хуже, чем многократные наследования или полный конвейер обработки каждой сущности, то попробуйте это как-то проиллюстрировать что ли.
API Друпала — отдельная кривая вещь. Хотите получить ноду по id? В руководстве АПИ прямо написано, что для этого лучше использовать прямые запросы, так как метод АПИ выбирает много данных и медленно работает.
Тут вы путаете теплое с мягким. Функция node_load() загружает результат прохода через все хуки, модифицирующие node, а прямой запрос достанет только то, что вы в него внесете без учета данных, добавленных другими модулями. То есть вы рискуете вообще отключить работу сторонних модулей в этом действии. Для некоторых задач оптимизации это имеет смысл, но в основном ничего кроме проблем и багов не сулит. Перед тем как критиковать этот подход дайте себе отчет, что вы просто не хотите соблюдать правила, и нарушая их получаете предсказуемые проблемы.
SELECT s.lid, t.translation, s.version FROM {locales_source} s LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.source = :source AND s.context = :context AND s.textgroup = 'default'
(запрос из locale.module, видимо для перевода строк). Для незнакомых с MySQL объясняю — при переводе строки мало того, что Друпал делает запрос в БД (да еще и с джойном, чтобы не отпимизировался), так еще и с поиском по текстовому (до 65536 символов) полю source. Любой человек, кто прочел хотя бы полглавы мануала по MySQL будет за такое бить монитором по голове. Gettext герои-друпаловцы решили побрезговать, что нам стоит каждую строчку из БД выдергивать.
Первый достойный пример недостатков drupal. Конечно про gettext вы вспомнили, учтя возможность вносить перевод для неограниченного числа языков через админку? Решение разработчиков drupal и меня в свое время огорчило, хотя я пошел немного дальше, чем вы и обнаружил в коде и другой запрос
// Refresh database stored cache of translations for given language.
// We only store short strings used in current version, to improve
// performance and consume less memory.
$result = db_query("SELECT s.source, s.context, t.translation, t.language FROM {locales_source} s
LEFT JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.textgroup = 'default'
AND s.version = :version AND LENGTH(s.source) < :length", array(':language' => $langcode,
':version' => VERSION, ':length' => variable_get('locale_cache_length', 75)));
foreach ($result as $data) {
$locale_t[$langcode][$data->context][$data->source] = (empty($data->translation) ? TRUE : $data->translation);
}
cache_set('locale:' . $langcode, $locale_t[$langcode]);
Надо ли объяснять, что это означает, что некоторые переводы загружаются (вы сами устанавливаете какие руководствуясь длинной для удобного распределения оперативной памяти) одним запросом? Кстати это может оказаться производительнее, чем gettext и одновременно гибче. Но беда, которую вы разглядели грозит тем, у кого variable_get('locale_cache_length', 75) вернет что-то близкое к нулю. Если вы считаете, что этот механизм при его гибкости не имеет права на существование, то пожалуйста аргументируйте, мне действительно интересно узнать что-то более эффективное и одновременно удобное.
Я уж молчу, что в нем нет ни моделек, ни ORM, ни валидаторов, ни нормальной работы с формами, ни системы views/widgets, ни наследуемых шаблонов, ни контроллеров, ни MVC, вообще ничего, чем все прогрессивное человечество пользуется в последние 10 лет.
Тут вы явно спорите о вкусах. ORM и валидаторы есть, просто они отвечают не привычным для вас потребностям. (Кстати отрицать существование ORM в продукте где один код используется минимум для трех заявленных СУБД, это слегка необдуманно на мой взгляд). Идея моделей не используется поскольку противоречит некоторым избранным стратегическим решениям, не хочу на этом заострять, вы можете найти это в словах самих разработчиков. Шаблоны Drupal реализуют совсем другую концепцию нежели Django. И вместо вертикального наследования они усилены горизонтальным. Вряд ли привычные вам шаблонизаторы дают возможность модулям влиять на рендеринг целых классов элементов страницы вне зависимости от даже используемой темы. Советую познакомиться с этой системой хотя бы для «общего развития», чтобы раздвинуть рамки узкого понимания шаблонизации. Опять же вызвано это неимоверной гибкостью. Причем «прогрессивное человечество» скорее всего еще будет иметь возможность оценить эту гибкость по мере последующего роста производительности серверов, а сейчас это просто футуристические эксперименты, имеющие полное на мой взгляд право на существование с учетом хорошего кеширования. И зря вы пытаетесь натянуть новые идеи на старый опыт. Это так же неэффективно, как оценивать Erlang с точки зрения парадигмы PHP.
Ок, насчет alter_query я ошибся — он работает с разбитым в массив запросом. Это, однако, не делает его более осмысленным, так как трудно представить себе, сколько возможно труднообнаружимых багов, когда ты делаешь запрос, а какой-то модуль тихонько его переписывает на другой.
Насчет перевода — gettext выгоднее. В случае Apache например, бинарный файл с переводом загружается в память один раз и повторно используется при обработке следующих запросов, а его структура обеспечивает более компактное хранение данных и поиск строк. Не говоря о том, что gettext — это открытая и повсеместно используемая бибилиотека. Если уж так надо переводить строки через админку (вы вообще уверены, что это удобно? учитывая скорость работы друпала? и наличие специального софта для работы с переводами) — можно было хранить строки в БД, но генерировать по ней .po -файл для gettext.
Насчет ORM — «в Друпале он есть, только свой» — где там ORM? Там есть система хранения сущностей, которые должны быть основаны на нодах, но ORM — в том виде, как например, это сделано в Hibernate, Doctrine — там нет (замечу, что я считаю саму Doctrine неудачной реализцией ORM — но она в разы лучше того, что в Друпале). Как всегда, какой-то свой криво, тормозной, неудобный велосипед.
Насчет качества кода. Я не первый год занимаюсь веб-разработкой, и видел всякий код. Код Друпала плохой и неорганизованный, куча функций и глобальных переменных. Он некачественный, уродливый, производит впечатление написанного людьми, плохо разбирающимися в веб-тенологиях.
Насчет расширения системы через хуки. Многие вещи, типа регистрации действий в системе, добавления пунктов меню, свойств в ноды, валидация, сделаны через хуки (=костыли). Вы говорите, а как еще сделать это, когда у вас 20 разных модулей. Отвечаю. Модули должны при установке (а не при каждом запросе) регистрировать в системе новые пункты меню и свойства, типа:
class SomeModule {
public static function afterInstall() {
$drupal->menu()->addEntry(...)
$drupal->schema()->addContentType(...)
$drupal->schema()->addProperty(...)
$drupal->schema()->addValidator(...)
}
}
Это правильно и логично. А когда у вас в ходе выполнения запроса происходят сотни вызовов разных модулей, они могут на ходу что-то подправить (а могут и не подправить) — это каша в коде, каша в голове разработчиков, снижение производительности, источник трудновоспроизводимых багов.
И идея разнести базовую функциональность на 20 модулей тоже, на мой взгляд, не самая лучшая.
Про архитектуру. Архитектуры там нет. Возьмем, например, пример из мануала по Друпалу, описание хука node_validate():
if (что-то неправильно) {
form_set_error(....);
}
Какое отношение валидация сущности имеет к форме? студенты, которые придумали этот хук, не в курсе, что сущности могут создаваться без участия формы, что формы и модель данных — это разные компоненты, которые не должны быть жестко связаны (связанность - отдельная тема, в Друпале как и в этом примере, все связано намертво).
То, что вы пишите про event-driven архитектуру — да нет там никакой архитектуры, это наспех сделанная и непродуманная система расширений, которую они вынуждены поддерживать. Что еще ждать от людей, которые программируют на функциях и глобальных переменных.
> Вряд ли привычные вам шаблонизаторы дают возможность модулям влиять на рендеринг целых классов элементов страницы вне зависимости от даже используемой темы. Советую познакомиться с этой системой хотя бы для «общего развития», чтобы раздвинуть рамки узкого понимания шаблонизации.
Эм, а зачем? Как я понимаю процесс разработки сайта, дизайнер рисует макеты, верстальщик из них нарезает шаблоны, а зачем «модулям влиять на рендеринг целых классов элементов страницы вне зависимости от даже используемой темы»? Чтобы сломать чьим-то модулем готовый дизайн?
А, еще вспомнил про систему шаблонов: допустим, мы выводим на отдельной странице список разделов (используя модуль View). Каждый раздел мы хотим вывести большой красивой картинкой, а потом, внизу, еще сделать текстовый список разделов. Сделать это — нельзя! Потому что мы имеем 2 шаблона, для вывода категории и для вывода списка из отрендеренных категорий. И вывести категорию в 2 местах страницы картинкой, а потом текстовой ссылкой нельзя. Нельзя просто написать 2 раза foreach (...){} для списка категорий. По крайней мере, я не нашел как это сделать.
Если копать дальше, можно хоть каждый компонент Друпала разобрать и объяснить, почему это неправильно. Единственное, что мне напоминает код Друпала, это код всяких CMS типа битрикс и амиро, он такой же кривой, бестолковый, и написан студентами, которые про современные архитектуры приложений и концепции только краем уха слышали.
Насчет перевода — gettext выгоднее. В случае Apache например, бинарный файл с переводом загружается в память один раз и повторно используется при обработке следующих запросов, а его структура обеспечивает более компактное хранение данных и поиск строк. Не говоря о том, что gettext — это открытая и повсеместно используемая бибилиотека. Если уж так надо переводить строки через админку (вы вообще уверены, что это удобно? учитывая скорость работы друпала? и наличие специального софта для работы с переводами) — можно было хранить строки в БД, но генерировать по ней .po -файл для gettext.
Насчет ORM — «в Друпале он есть, только свой» — где там ORM? Там есть система хранения сущностей, которые должны быть основаны на нодах, но ORM — в том виде, как например, это сделано в Hibernate, Doctrine — там нет (замечу, что я считаю саму Doctrine неудачной реализцией ORM — но она в разы лучше того, что в Друпале). Как всегда, какой-то свой криво, тормозной, неудобный велосипед.
Насчет качества кода. Я не первый год занимаюсь веб-разработкой, и видел всякий код. Код Друпала плохой и неорганизованный, куча функций и глобальных переменных. Он некачественный, уродливый, производит впечатление написанного людьми, плохо разбирающимися в веб-тенологиях.
Насчет расширения системы через хуки. Многие вещи, типа регистрации действий в системе, добавления пунктов меню, свойств в ноды, валидация, сделаны через хуки (=костыли). Вы говорите, а как еще сделать это, когда у вас 20 разных модулей. Отвечаю. Модули должны при установке (а не при каждом запросе) регистрировать в системе новые пункты меню и свойства, типа:
class SomeModule {
public static function afterInstall() {
$drupal->menu()->addEntry(...)
$drupal->schema()->addContentType(...)
$drupal->schema()->addProperty(...)
$drupal->schema()->addValidator(...)
}
}
Это правильно и логично. А когда у вас в ходе выполнения запроса происходят сотни вызовов разных модулей, они могут на ходу что-то подправить (а могут и не подправить) — это каша в коде, каша в голове разработчиков, снижение производительности, источник трудновоспроизводимых багов.
И идея разнести базовую функциональность на 20 модулей тоже, на мой взгляд, не самая лучшая.
Про архитектуру. Архитектуры там нет. Возьмем, например, пример из мануала по Друпалу, описание хука node_validate():
if (что-то неправильно) {
form_set_error(....);
}
Какое отношение валидация сущности имеет к форме? студенты, которые придумали этот хук, не в курсе, что сущности могут создаваться без участия формы, что формы и модель данных — это разные компоненты, которые не должны быть жестко связаны (связанность - отдельная тема, в Друпале как и в этом примере, все связано намертво).
То, что вы пишите про event-driven архитектуру — да нет там никакой архитектуры, это наспех сделанная и непродуманная система расширений, которую они вынуждены поддерживать. Что еще ждать от людей, которые программируют на функциях и глобальных переменных.
> Вряд ли привычные вам шаблонизаторы дают возможность модулям влиять на рендеринг целых классов элементов страницы вне зависимости от даже используемой темы. Советую познакомиться с этой системой хотя бы для «общего развития», чтобы раздвинуть рамки узкого понимания шаблонизации.
Эм, а зачем? Как я понимаю процесс разработки сайта, дизайнер рисует макеты, верстальщик из них нарезает шаблоны, а зачем «модулям влиять на рендеринг целых классов элементов страницы вне зависимости от даже используемой темы»? Чтобы сломать чьим-то модулем готовый дизайн?
А, еще вспомнил про систему шаблонов: допустим, мы выводим на отдельной странице список разделов (используя модуль View). Каждый раздел мы хотим вывести большой красивой картинкой, а потом, внизу, еще сделать текстовый список разделов. Сделать это — нельзя! Потому что мы имеем 2 шаблона, для вывода категории и для вывода списка из отрендеренных категорий. И вывести категорию в 2 местах страницы картинкой, а потом текстовой ссылкой нельзя. Нельзя просто написать 2 раза foreach (...){} для списка категорий. По крайней мере, я не нашел как это сделать.
Если копать дальше, можно хоть каждый компонент Друпала разобрать и объяснить, почему это неправильно. Единственное, что мне напоминает код Друпала, это код всяких CMS типа битрикс и амиро, он такой же кривой, бестолковый, и написан студентами, которые про современные архитектуры приложений и концепции только краем уха слышали.
Спасибо, что описали свое мнение подробнее. Правда единственная мысль которая возникает при чтении — вы свято уверены, что для решения существует ровно один способ — тот, который знаете вы. И именно его вы ожидаете увидеть в правильной архитектуре, а остальные не правильные.
Во-первых если вы какой-то запрос переписываете, то делаете это не со всем запросом, а только с той частью, которая вам нужна. Обычно вы туда добавляете поля через join. Если вы собрались поменять базовую таблицу, то вы просто не поняли зачем вообще пользуетесь alter_query. Кстати совершенно странно от человека, который уже понял что запросы по правилам фреймворка делаются не напрямую, а через некий механизм, не признавать за этим механизмом разновидность ORM. Почему? Вам хочется придраться к буквам? Вы действительно не способны разглядеть новую для вас реализацию того же принципа?
В случае использования fcgi-php и кеширования в memcache накладные расходы на кеширование периводов в массиве в сериализованном виде могут оказаться меньше. Я делал эксперименты с gettext-patch, который кстати никто не мешает использовать.
Аргумент из разряда «миллионы мух не могут ошибаться»? Ничего не стоит.
Удобно и гибко. Позволяет отвязать переводы от шаблонов. Нюансы — дело вкуса, а не профессионализма.
Я право чувствую себя нелепо. С одной стороны вы рьяно критикуете технологию, а с другой тупо не знаете о том, из чего она состоит. Drupal в базовой поставке импортирует и экспортирует .po файлы и вы имеете полную возможность использовать весь привычный инструментарий для перевода.
Вот снова вы ведете себя как «тупоконечник». Далась вам ваша любимая архитектура ORM на OOP. Я право впервые встречаю программиста со столь узкими рамками восприятия. Даже и не знаю как вам объяснить, что привычная для вас модель не единственная и не самая эффективная. Она просто привычная для вас. Мир вокруг нас диалектичен — множество противоположных концепций являются одновременно правильными и нет никакого единственно верного решения, как ваш вариант ORM. Более того, именно из-за очень низкой гибкости ORM мне пару раз приходилось отказываться от использования Django и писать на фреймворке более низкого уровня. Именно потому что классический OOP ORM продуцирует чудовищно бедные запросы. А вы его возвели в ранг панацеи. ORM Drupal ближе к чистому SQL, что дает несомненную гибкость в сравнении с вашими привычными ORM, а если не полениться и разобраться с правилами его использования, то никаких глюков и путаницы не будет, поскольку поведение фреймворка логичное и предсказуемое (для тех, кто его понимает, конечно).
Ну вот опять «костыли». То есть модульность 95% программ в среде windows сделана на костылях и только ваш метод единственно правильный. Право, такие выражения выглядят странно.
Вы будете смеяться, но так и происходит. Жаль, вы поленились с этим ознакомиться перед тем, как критиковать.
То же самое и происходит. Даже как и в вашем примере метод имеет заранее предопределенное название, только и того, что это не метод, а функция. Но когда вы говорите что неправильно всё, что не обернуто в class, я искренне удивляюсь.
Каша пока только в вашей голове, поскольку вы описываете механизм, с которым пытаетесь спорить и при этом одновременно называете его правильным и неправильным. Еще раз — если вы соблюдаете правила фреймворка, то ничего не путается и тем более не вызывается без нужды.
А мне нравится, что если мне не нужны в проекте переводы, комментарии, блоги и книги (частый пример), я их просто отключаю галкой в админке. Хотите поспорить, что лучше отключать в конфигурационных файлах, займитесь холиваром «unix-way vs windows-way» в другом месте, поскольку я не собираюсь спорить о вкусах.
Вы не знаете как устроен скажем болид F1, значит болид F1 нет. Блестящая логика.
Ну что за детский сад? Скажите, что в вашем примере выше делает $drupal->schema()->addValidator(...)? Ту же роль в Drupal выполняет hook_node_validate().
Похоже именно вы не понимаете, что цепочка валидации node может осуществляться любым модулем в отрыве от формы. Для этого и существует hook_node_validate(). Кстати вы давно сами от парты?
Знаете, это звучит наиболее смешно. Вы хоть цвета еще правильно называете с такими авторитарными замашками?
То есть вам ничего о такой архитектуре не известно и потому ее нет. Прямо лейтмотив вашего выступления.
Ну, вашу… фимозность (простите более точного слова не подобрал) я уже устал комментировать, но скажите, php уже избавился от утроения времени исполнения кода, обернутого в class? Или ваша «единственно правильная» схема построения приложений всё еще неоправданно тратит производительность серверов?
То есть объектно-ориентированное программирование для вас константа, а объектно-ориентированная верстка это нечто непонятное? Ну да, чего еще ожидать от «гибкости» вашего мышления. Хорошо, расскажу. При написании модуля программист имеет возможность создать умолчательный шаблон для выводимого объекта. Любая тема дизайна наследует этот умолчательный шаблон и если дизайнера устраивает, как его реализовал программист, то он ничего со своей версткой не делает, а если не устраивает, то он создает свой шаблон, который замещает умолчательный. Знакомо, любитель ООП? Это позволяет менять шаблоны дизайна вне зависимости от количества и источников установленных модулей.
Понимаю, к такой гибкости никакой другой фреймворк или CMS вас не готовили и это вам будет непросто переварить, но уж вы сделайте над собой усилие.
А ведь это элементарная задачка на шаблонизацию. Создаете файлик views--view-name.tpl.php в каталоге вашей темы и в ней дважды или сколько там нужно раз вызываете foreach c $view, где находятся результаты. регистрируете этот шаблон в теме и получаете требуемое. Работы минут на 20.
Вы бы вместо этого прочли документацию и поняли что имелось в виду. А то как видно то, что вы понимаете и что есть на самом деле на практике часто расходится.
Что-то мне это всё напоминает. А у вас часом нет своей рабочей CMS, с модульной инфраструктурой, расширяемостью и «правильной» архитектурой, лишенной недостатков этих ужасных продуктов?
Ок, насчет alter_query я ошибся — он работает с разбитым в массив запросом. Это, однако, не делает его более осмысленным, так как трудно представить себе, сколько возможно труднообнаружимых багов, когда ты делаешь запрос, а какой-то модуль тихонько его переписывает на другой.
Во-первых если вы какой-то запрос переписываете, то делаете это не со всем запросом, а только с той частью, которая вам нужна. Обычно вы туда добавляете поля через join. Если вы собрались поменять базовую таблицу, то вы просто не поняли зачем вообще пользуетесь alter_query. Кстати совершенно странно от человека, который уже понял что запросы по правилам фреймворка делаются не напрямую, а через некий механизм, не признавать за этим механизмом разновидность ORM. Почему? Вам хочется придраться к буквам? Вы действительно не способны разглядеть новую для вас реализацию того же принципа?
Насчет перевода — gettext выгоднее. В случае Apache например, бинарный файл с переводом загружается в память один раз и повторно используется при обработке следующих запросов, а его структура обеспечивает более компактное хранение данных и поиск строк.
В случае использования fcgi-php и кеширования в memcache накладные расходы на кеширование периводов в массиве в сериализованном виде могут оказаться меньше. Я делал эксперименты с gettext-patch, который кстати никто не мешает использовать.
Не говоря о том, что gettext — это открытая и повсеместно используемая бибилиотека.
Аргумент из разряда «миллионы мух не могут ошибаться»? Ничего не стоит.
Если уж так надо переводить строки через админку (вы вообще уверены, что это удобно? учитывая скорость работы друпала?...
Удобно и гибко. Позволяет отвязать переводы от шаблонов. Нюансы — дело вкуса, а не профессионализма.
… и наличие специального софта для работы с переводами) — можно было хранить строки в БД, но генерировать по ней .po -файл для gettext.
Я право чувствую себя нелепо. С одной стороны вы рьяно критикуете технологию, а с другой тупо не знаете о том, из чего она состоит. Drupal в базовой поставке импортирует и экспортирует .po файлы и вы имеете полную возможность использовать весь привычный инструментарий для перевода.
Насчет ORM — «в Друпале он есть, только свой» — где там ORM? Там есть система хранения сущностей, которые должны быть основаны на нодах, но ORM — в том виде, как например, это сделано в Hibernate, Doctrine — там нет (замечу, что я считаю саму Doctrine неудачной реализцией ORM — но она в разы лучше того, что в Друпале). Как всегда, какой-то свой криво, тормозной, неудобный велосипед.
Вот снова вы ведете себя как «тупоконечник». Далась вам ваша любимая архитектура ORM на OOP. Я право впервые встречаю программиста со столь узкими рамками восприятия. Даже и не знаю как вам объяснить, что привычная для вас модель не единственная и не самая эффективная. Она просто привычная для вас. Мир вокруг нас диалектичен — множество противоположных концепций являются одновременно правильными и нет никакого единственно верного решения, как ваш вариант ORM. Более того, именно из-за очень низкой гибкости ORM мне пару раз приходилось отказываться от использования Django и писать на фреймворке более низкого уровня. Именно потому что классический OOP ORM продуцирует чудовищно бедные запросы. А вы его возвели в ранг панацеи. ORM Drupal ближе к чистому SQL, что дает несомненную гибкость в сравнении с вашими привычными ORM, а если не полениться и разобраться с правилами его использования, то никаких глюков и путаницы не будет, поскольку поведение фреймворка логичное и предсказуемое (для тех, кто его понимает, конечно).
Насчет расширения системы через хуки. Многие вещи, типа регистрации действий в системе, добавления пунктов меню, свойств в ноды, валидация, сделаны через хуки (=костыли).
Ну вот опять «костыли». То есть модульность 95% программ в среде windows сделана на костылях и только ваш метод единственно правильный. Право, такие выражения выглядят странно.
Вы говорите, а как еще сделать это, когда у вас 20 разных модулей. Отвечаю. Модули должны при установке (а не при каждом запросе) регистрировать в системе новые пункты меню и свойства
Вы будете смеяться, но так и происходит. Жаль, вы поленились с этим ознакомиться перед тем, как критиковать.
class SomeModule {
public static function afterInstall() {
$drupal->menu()->addEntry(...)
$drupal->schema()->addContentType(...)
$drupal->schema()->addProperty(...)
$drupal->schema()->addValidator(...)
}
}
То же самое и происходит. Даже как и в вашем примере метод имеет заранее предопределенное название, только и того, что это не метод, а функция. Но когда вы говорите что неправильно всё, что не обернуто в class, я искренне удивляюсь.
А когда у вас в ходе выполнения запроса происходят сотни вызовов разных модулей, они могут на ходу что-то подправить (а могут и не подправить) — это каша в коде, каша в голове разработчиков, снижение производительности, источник трудновоспроизводимых багов.
Каша пока только в вашей голове, поскольку вы описываете механизм, с которым пытаетесь спорить и при этом одновременно называете его правильным и неправильным. Еще раз — если вы соблюдаете правила фреймворка, то ничего не путается и тем более не вызывается без нужды.
И идея разнести базовую функциональность на 20 модулей тоже, на мой взгляд, не самая лучшая.
А мне нравится, что если мне не нужны в проекте переводы, комментарии, блоги и книги (частый пример), я их просто отключаю галкой в админке. Хотите поспорить, что лучше отключать в конфигурационных файлах, займитесь холиваром «unix-way vs windows-way» в другом месте, поскольку я не собираюсь спорить о вкусах.
Про архитектуру. Архитектуры там нет.
Вы не знаете как устроен скажем болид F1, значит болид F1 нет. Блестящая логика.
Возьмем, например, пример из мануала по Друпалу, описание хука node_validate():
if (что-то неправильно) {
form_set_error(....);
}
Какое отношение валидация сущности имеет к форме?
Ну что за детский сад? Скажите, что в вашем примере выше делает $drupal->schema()->addValidator(...)? Ту же роль в Drupal выполняет hook_node_validate().
студенты, которые придумали этот хук, не в курсе, что сущности могут создаваться без участия формы
Похоже именно вы не понимаете, что цепочка валидации node может осуществляться любым модулем в отрыве от формы. Для этого и существует hook_node_validate(). Кстати вы давно сами от парты?
связанность — отдельная тема, в Друпале как и в этом примере, все связано намертво
Знаете, это звучит наиболее смешно. Вы хоть цвета еще правильно называете с такими авторитарными замашками?
То, что вы пишите про event-driven архитектуру — да нет там никакой архитектуры
То есть вам ничего о такой архитектуре не известно и потому ее нет. Прямо лейтмотив вашего выступления.
Что еще ждать от людей, которые программируют на функциях и глобальных переменных.
Ну, вашу… фимозность (простите более точного слова не подобрал) я уже устал комментировать, но скажите, php уже избавился от утроения времени исполнения кода, обернутого в class? Или ваша «единственно правильная» схема построения приложений всё еще неоправданно тратит производительность серверов?
Эм, а зачем? Как я понимаю процесс разработки сайта, дизайнер рисует макеты, верстальщик из них нарезает шаблоны, а зачем «модулям влиять на рендеринг целых классов элементов страницы вне зависимости от даже используемой темы»? Чтобы сломать чьим-то модулем готовый дизайн?
То есть объектно-ориентированное программирование для вас константа, а объектно-ориентированная верстка это нечто непонятное? Ну да, чего еще ожидать от «гибкости» вашего мышления. Хорошо, расскажу. При написании модуля программист имеет возможность создать умолчательный шаблон для выводимого объекта. Любая тема дизайна наследует этот умолчательный шаблон и если дизайнера устраивает, как его реализовал программист, то он ничего со своей версткой не делает, а если не устраивает, то он создает свой шаблон, который замещает умолчательный. Знакомо, любитель ООП? Это позволяет менять шаблоны дизайна вне зависимости от количества и источников установленных модулей.
Понимаю, к такой гибкости никакой другой фреймворк или CMS вас не готовили и это вам будет непросто переварить, но уж вы сделайте над собой усилие.
А, еще вспомнил про систему шаблонов: допустим, мы выводим на отдельной странице список разделов (используя модуль View). Каждый раздел мы хотим вывести большой красивой картинкой, а потом, внизу, еще сделать текстовый список разделов. Сделать это — нельзя! Потому что мы имеем 2 шаблона, для вывода категории и для вывода списка из отрендеренных категорий. И вывести категорию в 2 местах страницы картинкой, а потом текстовой ссылкой нельзя. Нельзя просто написать 2 раза foreach (...){} для списка категорий. По крайней мере, я не нашел как это сделать.
А ведь это элементарная задачка на шаблонизацию. Создаете файлик views--view-name.tpl.php в каталоге вашей темы и в ней дважды или сколько там нужно раз вызываете foreach c $view, где находятся результаты. регистрируете этот шаблон в теме и получаете требуемое. Работы минут на 20.
Если копать дальше, можно хоть каждый компонент Друпала разобрать и объяснить, почему это неправильно.
Вы бы вместо этого прочли документацию и поняли что имелось в виду. А то как видно то, что вы понимаете и что есть на самом деле на практике часто расходится.
Единственное, что мне напоминает код Друпала, это код всяких CMS типа битрикс и амиро, он такой же кривой, бестолковый, и написан студентами, которые про современные архитектуры приложений и концепции только краем уха слышали.
Что-то мне это всё напоминает. А у вас часом нет своей рабочей CMS, с модульной инфраструктурой, расширяемостью и «правильной» архитектурой, лишенной недостатков этих ужасных продуктов?
> А ведь это элементарная задачка на шаблонизацию. Создаете файлик views--view-name.tpl.php в каталоге вашей темы и в ней дважды или сколько там нужно раз вызываете foreach c $view, где находятся результаты. регистрируете этот шаблон в теме и получаете требуемое. Работы минут на 20.
Если мне не изменяет память, там есть шаблон для вывода отдельной ноды, и шаблон для вывода списка нод, который получает на вход HTML-код отрендеренной ноды (а не массив с данными этой ноды). Вывести одним шаблоном 2 раза список нод в разном виде (один раз картинками, другой — текстом) — невозможно. Либо я тогда что-то не нашел, либо вы меня не поняли.
По поводу ООП — вы знаете, зачем его придумали? Думаете, академикам было скучно и они решили внедрить новую концепцию программирования? ООП нужно для упорядочивания, организации кода больших проектов, над которыми работает много человек. Потому, что ООП-код подразумевает отсутствие глобальных переменных: это значит, область видимости переменной ограничены одной функцией и вам не надо гадать, в каком из 1000 файлов в эту переменную записалось что-то не подходящее. ООП позволяет разбить код на классы, и вы знаете, что в классе Database_Access не окажется кода переписывания УРЛ. Классы хранятся каждый в своем файле, файлы по папкам. У классов есть приватные функции: вы можете быть спокойными, что эту функцию из другого файла никто не вызовет, и легко найти все места ее вызова. С таким кодом действительно проще работать.
А вы мне что-то рассказываете про альтернативный подход в Друпале. Альтернативный в том, что мы сваливаем 200 функций в один файл common.inc? И сваливаем файлы с кодом все в одну папку? Да, это скорее неумение организовать код. Поэтому и появляются специалисты за 200 долларов в час, потому, что никто потом в этом коде разобраться не может.
Кстати, запутанный код очень трудно поддерживать и оптимизировать — возможно, поэтому никто до сих пор и не может нормально этот друпал ускорить, кроме как кешированием страниц на нгинксе. И вряд ли его кто дооптимизирует — скоро его будет проще выбросить и написать заново. Да и непонятно, как кешировать результаты выборки списка сущностей, и как сбрасывать этот кеш, если, например, отдельные модули могут менять на ходу как параметры запроса, так и менять что-то в результате его выполнения.
И смешно говорить про какое-то замедление выполнение времени кода от использования классов. Пока Друпал делает кучу неиндексируемых нормально запросов, с джойнами, которые MySQL нормально оптимизировать не умеет, это не имеет никакого значения. Нормальные MySQL запросы, без джойнов и с индексами, выполняются обычно за 300-1000 мкс, но друпалу такие цифры только снятся.
> ORM Drupal ближе к чистому SQL, что дает несомненную гибкость в сравнении с вашими привычными ORM, а если не полениться и разобраться с правилами его использования, то никаких глюков и путаницы не будет, поскольку поведение фреймворка логичное и предсказуемое (для тех, кто его понимает, конечно).
Простите, мне кажется, вы так и не поняли, что такое ORM. ORM — средство для организации хранения объектов бизнес-логики в реляционной таблице, получения этих объектов, их валидации и их получения коллекций с учетом связей между ними, а не средство выполнения SQL-запросов. То, что есть в Друпале, называется DBAL — Database Access Layer. Если там вопросики в запросе заменяются на значения параметров — это не ORM.
Возвращаясь к валидации.
> Ну что за детский сад? Скажите, что в вашем примере выше делает $drupal->schema()->addValidator(...)? Ту же роль в Drupal выполняет hook_node_validate().
Вы не видите разницы между изменением схемы данных (добавление полей и валидаторов) в момент установки модуля и костылем, который на ходу при выполнении каждого запроса добавляет в массив поля? Это то же самое? По моему, нет.
> Похоже именно вы не понимаете, что цепочка валидации node может осуществляться любым модулем в отрыве от формы. Для этого и существует hook_node_validate(). Кстати вы давно сами от парты?
процитирую мануал ( api.drupal.org/api/drupal/modules--node--node.api.php/function/hook_node_validate/7 ):
> hook_node_validate
> hook_node_validate($node, $form, &$form_state)
> Perform node validation before a node is created or updated.
> To indicate a validation error, use form_set_error().
Почему валидация сущности привязана к использованию формы редактирования? Какая ему, Друпалу, разница, откуда (из формы или другого источника) пришли данные? Что, нельзя провалидировать сущность, полученную не через форму редактирования? Как я уже написал, индусы, которые этот код написали, своим ограниченным мышлением не понимают, что объекты можно создавать и без форм и участия пользователя, скриптом, например. Они просто не могут разделить компоненту для обработки форм и пользовательского ввода от компоненты для поверки и сохранения сущностей в БД.
Если мне не изменяет память, там есть шаблон для вывода отдельной ноды, и шаблон для вывода списка нод, который получает на вход HTML-код отрендеренной ноды (а не массив с данными этой ноды). Вывести одним шаблоном 2 раза список нод в разном виде (один раз картинками, другой — текстом) — невозможно. Либо я тогда что-то не нашел, либо вы меня не поняли.
По поводу ООП — вы знаете, зачем его придумали? Думаете, академикам было скучно и они решили внедрить новую концепцию программирования? ООП нужно для упорядочивания, организации кода больших проектов, над которыми работает много человек. Потому, что ООП-код подразумевает отсутствие глобальных переменных: это значит, область видимости переменной ограничены одной функцией и вам не надо гадать, в каком из 1000 файлов в эту переменную записалось что-то не подходящее. ООП позволяет разбить код на классы, и вы знаете, что в классе Database_Access не окажется кода переписывания УРЛ. Классы хранятся каждый в своем файле, файлы по папкам. У классов есть приватные функции: вы можете быть спокойными, что эту функцию из другого файла никто не вызовет, и легко найти все места ее вызова. С таким кодом действительно проще работать.
А вы мне что-то рассказываете про альтернативный подход в Друпале. Альтернативный в том, что мы сваливаем 200 функций в один файл common.inc? И сваливаем файлы с кодом все в одну папку? Да, это скорее неумение организовать код. Поэтому и появляются специалисты за 200 долларов в час, потому, что никто потом в этом коде разобраться не может.
Кстати, запутанный код очень трудно поддерживать и оптимизировать — возможно, поэтому никто до сих пор и не может нормально этот друпал ускорить, кроме как кешированием страниц на нгинксе. И вряд ли его кто дооптимизирует — скоро его будет проще выбросить и написать заново. Да и непонятно, как кешировать результаты выборки списка сущностей, и как сбрасывать этот кеш, если, например, отдельные модули могут менять на ходу как параметры запроса, так и менять что-то в результате его выполнения.
И смешно говорить про какое-то замедление выполнение времени кода от использования классов. Пока Друпал делает кучу неиндексируемых нормально запросов, с джойнами, которые MySQL нормально оптимизировать не умеет, это не имеет никакого значения. Нормальные MySQL запросы, без джойнов и с индексами, выполняются обычно за 300-1000 мкс, но друпалу такие цифры только снятся.
> ORM Drupal ближе к чистому SQL, что дает несомненную гибкость в сравнении с вашими привычными ORM, а если не полениться и разобраться с правилами его использования, то никаких глюков и путаницы не будет, поскольку поведение фреймворка логичное и предсказуемое (для тех, кто его понимает, конечно).
Простите, мне кажется, вы так и не поняли, что такое ORM. ORM — средство для организации хранения объектов бизнес-логики в реляционной таблице, получения этих объектов, их валидации и их получения коллекций с учетом связей между ними, а не средство выполнения SQL-запросов. То, что есть в Друпале, называется DBAL — Database Access Layer. Если там вопросики в запросе заменяются на значения параметров — это не ORM.
Возвращаясь к валидации.
> Ну что за детский сад? Скажите, что в вашем примере выше делает $drupal->schema()->addValidator(...)? Ту же роль в Drupal выполняет hook_node_validate().
Вы не видите разницы между изменением схемы данных (добавление полей и валидаторов) в момент установки модуля и костылем, который на ходу при выполнении каждого запроса добавляет в массив поля? Это то же самое? По моему, нет.
> Похоже именно вы не понимаете, что цепочка валидации node может осуществляться любым модулем в отрыве от формы. Для этого и существует hook_node_validate(). Кстати вы давно сами от парты?
процитирую мануал ( api.drupal.org/api/drupal/modules--node--node.api.php/function/hook_node_validate/7 ):
> hook_node_validate
> hook_node_validate($node, $form, &$form_state)
> Perform node validation before a node is created or updated.
> To indicate a validation error, use form_set_error().
Почему валидация сущности привязана к использованию формы редактирования? Какая ему, Друпалу, разница, откуда (из формы или другого источника) пришли данные? Что, нельзя провалидировать сущность, полученную не через форму редактирования? Как я уже написал, индусы, которые этот код написали, своим ограниченным мышлением не понимают, что объекты можно создавать и без форм и участия пользователя, скриптом, например. Они просто не могут разделить компоненту для обработки форм и пользовательского ввода от компоненты для поверки и сохранения сущностей в БД.
Если мне не изменяет память, там есть шаблон для вывода отдельной ноды, и шаблон для вывода списка нод, который получает на вход HTML-код отрендеренной ноды (а не массив с данными этой ноды). Вывести одним шаблоном 2 раза список нод в разном виде (один раз картинками, другой — текстом) — невозможно. Либо я тогда что-то не нашел, либо вы меня не поняли.
Вам изменяет память. С ленью. Будь вы менее ленивым, прочли бы документацию по темизации. Повторяю еще раз — ваша задачка решается одним файлом в каталоге темы. Внутри этого файла вам надо организовать два цикла по одному и тому же массиву. Решение настолько тривиально, что даже не имеет смысла его разжевывать.
По поводу ООП — вы знаете, зачем его придумали? Думаете, академикам было скучно и они решили внедрить новую концепцию программирования? ООП нужно для упорядочивания, организации кода больших проектов, над которыми работает много человек. Потому, что ООП-код подразумевает отсутствие глобальных переменных: это значит, область видимости переменной ограничены одной функцией и вам не надо гадать, в каком из 1000 файлов в эту переменную записалось что-то не подходящее. ООП позволяет разбить код на классы, и вы знаете, что в классе Database_Access не окажется кода переписывания УРЛ. Классы хранятся каждый в своем файле, файлы по папкам. У классов есть приватные функции: вы можете быть спокойными, что эту функцию из другого файла никто не вызовет, и легко найти все места ее вызова. С таким кодом действительно проще работать.
Да вы просто медитируете на правильность единственного пути. Умные люди говорят — у плохого актера 3 маски, а у хорошего не меньше чем 33. Это применимо и к программистам. Вы актер одной маски OOP. Другими парадигмами вы пользоваться не умеете. Оттого и ваши слепые перетяжки вроде «раз программирование не объектное, значит переменные глобальные и объявлены чёрт знает где». Код Drupal таким не является, хотя вы упорно это игнорируете. Переменные хранятся в базе, модули представляют собой абстракцию вроде объектов и объявленные внутри них переменные в другие части кода не попадают. Почему, вам наверно не дано понять с вашим упорством утверждать то, что вы думаете вместо того, что есть на самом деле.
А вы мне что-то рассказываете про альтернативный подход в Друпале. Альтернативный в том, что мы сваливаем 200 функций в один файл common.inc?
Нет, альтернативность не в этом, хотя этот файл мало чем отличается от многих серьезных библиотек. Конечно если у вас нет IDE с поддержкой навигации по функциям, вам будет неприятно разбираться в коде этого файла, но если учесть, что лезть туда вам вряд ли вообще потребуется, то он всего лишь экономит файловые дескрипторы и не более того.
И сваливаем файлы с кодом все в одну папку? Да, это скорее неумение организовать код.
О какой папке идет речь? Об одной из десятка папок ядра? По моему вы сильно перегибаете палку. Разработчику сайта, темы или модуля вообще незачем трогать ядро. Тактика разработки на Drupal как раз и заключается в том, чтобы весь код модификации можно было атомизировать в пределах одной папки — папки модуля занимающегося конкретной работой. Черт, кому я это рассказываю? Твердолобому фанату своей школы, который не собирается разбираться в том, что критикует?
Поэтому и появляются специалисты за 200 долларов в час, потому, что никто потом в этом коде разобраться не может.
:) А можно посмотреть на это и по-другому. Мало у кого хватает мозгов понять стройность и гениальность такой сложной и самобытной системы. Вот и ценятся специалисты, которые знают как одинм файлом в теме решить задачу для которой другие будут переписывать модуль views или писать свои костыли, как предлагали вы выше.
Кстати, запутанный код очень трудно поддерживать и оптимизировать — возможно, поэтому никто до сих пор и не может нормально этот друпал ускорить, кроме как кешированием страниц на нгинксе.
Там дело не в запутанности, а в гибкости. Этот движок явно предназначен не для высоконагруженных приложений, но на своем любимом фреймворке вы потратите не один человеко-год, чтобы дать заказчику столько власти над контентом и структурой сайта, сколько Drupal дает из коробки. Жаль, что вы слишколм упрямы, чтобы принимать такие аргументы, вы же считаете себя носителем единственно правильного пути в интерфейсе и функционале админки, не так ли?
Да и непонятно, как кешировать результаты выборки списка сущностей, и как сбрасывать этот кеш, если, например, отдельные модули могут менять на ходу как параметры запроса, так и менять что-то в результате его выполнения.
Вообще-то это эелементарно, но для тех, кто понимает как организован Drupal. Я например для разгрузки очень посещаемого сайта использовал перенос кеширования с MySQL на memcache. И сделал это drupal-way — отдельным модулем, который как бы вам не казалось невероятным спокойно обслуживает все обращения к кешу из всех модулей. Повторяю ничего непредсказуемого в движке не происходит, просто порядок вызовов и динамика данных обусловлена не написанной одним программистом последовательностью, а заранее определенной при помощи программы последовательностью вызовов хуков. Вся разница в том, что делается это галочками в админке, а не кодом в специальном файле, как вы привыкли (и похоже больше ничему не учились).
Простите, мне кажется, вы так и не поняли, что такое ORM. ORM — средство для организации хранения объектов бизнес-логики в реляционной таблице, получения этих объектов, их валидации и их получения коллекций с учетом связей между ними, а не средство выполнения SQL-запросов. То, что есть в Друпале, называется DBAL — Database Access Layer. Если там вопросики в запросе заменяются на значения параметров — это не ORM.
Я же предлагал не придираться буковкам. Главная задача ORM — прокладка между базой и логикой программы, с этим DBAL справляется великолепно, остальное, к чему вы привыкли реализуется по-другому. Оно по-другому задумано и тоже логично. Увы, эта логика вам не доступна из-за ненужного упорства.
Вы не видите разницы между изменением схемы данных (добавление полей и валидаторов) в момент установки модуля и костылем, который на ходу при выполнении каждого запроса добавляет в массив поля? Это то же самое? По моему, нет.
Вас заклинило на статичности схемы данных. А Drupal дает делать схему динамической. Вам нужен тип материалов с фотографией в виде поля, вы идете в админку и создаете его там. Вам надо, чтобы этих фотографий в материале могло быть не ограниченное число, вы выбираете соответствующий пункт. для этого не придется ничего переписывать, схема данных расширится нужными таблицами, а генераторы и валидаторы автоматически включат обработчики нового типа материала и его полей. Да, это не то, к чему вы привыкли, но именно из-за этого hook_node_validate работает так, как задумали разработчики Drupal.
Почему валидация сущности привязана к использованию формы редактирования? Какая ему, Друпалу, разница, откуда (из формы или другого источника) пришли данные? Что, нельзя провалидировать сущность, полученную не через форму редактирования?
А что вы подразумеваете под валидацией node, если не часть процесса сохранения данных в базе? Вы хотите проверять данные при выводе? Для этого существует другой hook. Для чего вы еще используете валидатор?
Как я уже написал, индусы, которые этот код написали, своим ограниченным мышлением не понимают, что объекты можно создавать и без форм и участия пользователя, скриптом, например.
Вы снова пытаетесь оскорблять разработчиков на основании собственного незнания архитектуры этой системы. это некрасиво. Хотя судя по вашей карме, (только что глянул) становится понятно, что скорее всего вы не относитесь к тактичным людям. Будь вы чуть менее хамовитым и чуть более любопытным, посмотрели бы сами на код создания node api.drupal.org/api/drupal/modules--node--node.pages.inc/function/node_add/7 и не пришлось бы снова демонстрировать свою агрессивную неосведомленность.
Они просто не могут разделить компоненту для обработки форм и пользовательского ввода от компоненты для поверки и сохранения сущностей в БД.
Да ну хватит уже гнать, у вас же перед глазами api.drupal.org. Сами посмотрите ведь есть и контролируемый этап создания, и контролируемый этап сохранения api.drupal.org/api/drupal/modules--node--node.module/function/node_save/7
В любой из них можно при необходимости встроить любой валидатор через хуки (node_presave и entity_presave).
Знаете, вы своим толстым троллингом кажется только помогаете другим присмотреться к архитектуре Drupal :)
Ладно, я думаю, дальнейший спор уже ни к чему не приведет. Все равно я останусь при своей точке зрения, а вы при своей. Если у вас хорошо получается делать сайты на Друпале, и клиенты довольны, то можно только порадоваться за вас.
Если кто-то решит «присмотреться к архитектуре Друпал» — ну замечательно, пусть присмотрится, посмотрит исходный код, и сам для себя решит, подходит она ему или нет.
Вы еще спрашивали, что я думаю о коде джумлы — смотрел мельком когда-то давно, не понравилось.
Если кто-то решит «присмотреться к архитектуре Друпал» — ну замечательно, пусть присмотрится, посмотрит исходный код, и сам для себя решит, подходит она ему или нет.
Вы еще спрашивали, что я думаю о коде джумлы — смотрел мельком когда-то давно, не понравилось.
Ладно, я думаю, дальнейший спор уже ни к чему не приведет. Все равно я останусь при своей точке зрения, а вы при своей.
Какая прелесть — программист с «эмоциональной» логикой блондинки. Так для вас изначально наговорить гадостей в сторону Drupal и его разработчиков важнее, чем разобраться сколько под вашими словами правды? Я привожу доводы на конкретные глупейшие замечания. При этом я не являюсь фанатом Drupal и знаю его недостатки лучше многих критиканов. Я делаю это не из привычки и не из преданности. Мне вообще наплевать и я не привязан. Есть проекты, в которых Drupal подходит, есть те, в которых не подходит. Но я не буду его говнять только потому, что мне лень в нем разобраться.
Если у вас хорошо получается делать сайты на Друпале, и клиенты довольны, то можно только порадоваться за вас.
Разве мы об этом спорили? Мы спорили об архитектуре. Вы вообще отказывали в логике там, где она есть.
Вы еще спрашивали, что я думаю о коде джумлы — смотрел мельком когда-то давно, не понравилось.
Мне всё равно понравился вам код Joomla или нет. Я спрашивал профессионального, по возможности, мотивированного мнения о его качестве, раз уж вы позиционируете себя как специалист. Спросил это для того, чтобы откалибровать шкалу представлений о качестве кода подобных движков. Лично я нашел код Joomla чрезвычайно непродуманным и полным костылей.
Хорошо, если вы настаиваете на профессиональной точке зрения, для меня код и Джумлы, и друпала в равной степени неструктурирован, неорганизован и бестолков, не использует современные подходы к разработке, вместо них содержит неудачные велосипеды.
А еще, у них плохо с правильным названием функций и классов — например, роутинг и связанные с ним функции в друпале почему-то называют menu.
Насчет архитектуры — ну да, так можно взять любой кривой скрипт, написать к каждой функции по комментарию, размером больше самой функции, и сказать, что в нем есть архитектура, только своя, особенная, альтернативная, и не всем понятная. Кривым скриптом от этого он быть не перестанет.
Если вы делаете не блогоподобный сайт на друпале со стандартными модулями, надо готовиться к тому, что половину времени вы будете не писать код, а думать, каким костылем исправить поведение Друпала или его модулей.
А еще, у них плохо с правильным названием функций и классов — например, роутинг и связанные с ним функции в друпале почему-то называют menu.
Насчет архитектуры — ну да, так можно взять любой кривой скрипт, написать к каждой функции по комментарию, размером больше самой функции, и сказать, что в нем есть архитектура, только своя, особенная, альтернативная, и не всем понятная. Кривым скриптом от этого он быть не перестанет.
Если вы делаете не блогоподобный сайт на друпале со стандартными модулями, надо готовиться к тому, что половину времени вы будете не писать код, а думать, каким костылем исправить поведение Друпала или его модулей.
Ну да, что еще было от вас ожидать. Снова заявления о том, что архитектуры может не быть, снова превознесение одних технологий за то, что они де «современные», и принижение других за то, что они не понятны.
Самое интересное — спор о терминах. Dispatch, routing, menu… Вам как будто не все равно как оно называется. Или с той же энергией вы собираетесь рассказывать носителям другого человеческого языка, что он называет всё не правильно? Какое барбекю, — с пеной у рта будете кричать вы, — шашлык, вот как это правильно называется! Дураки все, кто шашлык называет барбекю. И вообще английский это неудобный велосипед — целых 20 времен и нет падежей.
Короче говоря — сюр невыразимый. Спасибо, давно так не смеялся, как при общении с вами.
Самое интересное — спор о терминах. Dispatch, routing, menu… Вам как будто не все равно как оно называется. Или с той же энергией вы собираетесь рассказывать носителям другого человеческого языка, что он называет всё не правильно? Какое барбекю, — с пеной у рта будете кричать вы, — шашлык, вот как это правильно называется! Дураки все, кто шашлык называет барбекю. И вообще английский это неудобный велосипед — целых 20 времен и нет падежей.
Короче говоря — сюр невыразимый. Спасибо, давно так не смеялся, как при общении с вами.
>… то он всего лишь экономит файловые дескрипторы и не более того.
OMG, вот это жесть
OMG, вот это жесть
Что «жесть» то? Для вас не понятно, что один файл с функциями, в которые не надо постоянно лезть разработчику лучше, чем 50 файлов с теми же функциями? Ну так почитайте на досуге про файловые дескрипторы. Или может кто-то из системщиков объяснит, что для системы, для которой эти 200 функций нужно постоянно загружать в память (под Apache на каждый запрос) есть существенная разница между тем один это файл или 50.
А чё так резко-то? И вроде как для PHP придумали всякие phar и кеши опкода (apc, xcache, etc).
Ах вот к чему вы придираетесь. Да, конечно, эти кешеровщики существуют, как существует и системный кеш для открываемых файлов. Но равенства по затрате ресурсов между одним файлом и 50 не будет никогда. Теперь ситуация — у вас есть набор функций, которые вам нужно вызывать часто, но совсем не нужно модифицировать. Вам, как разработчику модулей, (но не ядра) есть хоть какая-то разница в скольки файлах они лежат, если вам даже упоминать подгрузку этих файлов никогда не потребуется? Ответ очевиден — это обстоятельство не имеет ровным счетом никакого значения. Я бы даже не стал об этом вспоминать, если бы не смешные наезды блондинко-программера.
Кстати о быдлокоде — вы когда-нибудь разбирали код Joomla? Что скажете на его счет?
Почему, когда надо обосрать Drupal всегда вспоминают 6-ую версию, которая разрабатывалась в 2007 г.? ОПП на PHP4 это мазохизм.
Из того что здесь приведено 80% не соответствует тому, что есть в Drupal 7, и 99% тому, что будет в Drupal 8.
Из того что здесь приведено 80% не соответствует тому, что есть в Drupal 7, и 99% тому, что будет в Drupal 8.
Заголовок поста вызывает только одну ассоциацию: «7 причин для перехода с общественного транспорта на личный автомобиль». У кого-то нет денег на авто, да и живёт он в 15 минутах от работы одним транспортом, улавливаете?
Если без метафор, то Drupal — это CMS впервую очередь, а Yii — это то, на чём пишут CMS. У всех инструментов своё предназначение, хотя я в большинстве жизненных ситуаций всё же предпочитаю автомобиль (в виде Symfony2).
Если без метафор, то Drupal — это CMS впервую очередь, а Yii — это то, на чём пишут CMS. У всех инструментов своё предназначение, хотя я в большинстве жизненных ситуаций всё же предпочитаю автомобиль (в виде Symfony2).
Хочу добавить лично от себя: Я не собираюсь защищать Drupal в плане нагрузки на базу данных. Это действительно может оказаться тяжелым минусом его использования, и мне на своем опыте пришлось пройти через то же самое, что и автору изначальной статьи. Однако я не склонен поддерживать и тех оголтелых критиканов, которые называют его архитектуру принципиально неудачной. После углубленного знакомства с ней я пришел к выводу, что архитектура как раз чрезвычайно продумана и там нет кода, не оправданного целями. Я убежден, что критиковать не знакомую архитектуру попросту глупо и именно это выставляет некоторых критиков в невыгодном свете. У меня даже появились подозрения, что лагерь ярых противников Drupal состоит из людей, которые просто не смогли его понять и освоить. Поскольку будучи в курсе архитектуры и инструментария этого CMF, вряд ли можно ожидать от него больше, чем осмысленно занесено туда разработчиками. Я уверен, что Drupal имеет свою нишу и чертовски хорош в ней, но затыкать им любую дырку попросту неправильно. Как нельзя абстрактно выбирать лучшего из автомобилей F1 и скажем Hammer — конкретное применение и объяснит что в данной ситуации выгоднее, даже не придется устраивать соревнования, если знаешь особенности этих ТС. Точно так же и с движками сайтов и это нельзя сбрасывать со счетов. На мой взгляд автор статьи проделал совершенно правильную и осмысленную работу, но сделал заступ в оценках, чем и вызвал некорректную местами полемику.
Вот собственно с апрельской конференции video.yandex.ru/users/vaspi/view/40
Доклад от ребят из Axel Springer (Forbes) по поводу настройки окружения для Drupal под high loaded проект.
Доклад от ребят из Axel Springer (Forbes) по поводу настройки окружения для Drupal под high loaded проект.
Уважаемые рельсовики перфекционисты, сделайте пожалуйста в Redmine настройку видимости полей у задач в зависимости от ролей и проектов. Очень нужно, а который год ждем. Спасибо;)
Думаю, это относится к любому php-фреймворку (несмотря на то, что yii, особенно второй мне очень нравится, но надо быть объективным).
Любая CMS большую часть времени тратит на самоподъем. Фреймворки просто работают на более низком уровне, предоставляя при этом большую гибкость.
Для любого сколько нибудь крупного проекта фреймворк, так же предпочтительнее и разработки на чистом php, поскольку все равно придется организовывать код, а так хорошо, как это сделано в фреймворке сделать все равно вряд ли получится, плюс время на наработку такого «библиотечного» кода потратится много.
Статью обязаны читать все «заказчики». По опыту переубедить делать серьезный проект не на «Битриксе» или «Друпале» порой бывает очень сложно. Теперь просто буду давать ссылку )
Любая CMS большую часть времени тратит на самоподъем. Фреймворки просто работают на более низком уровне, предоставляя при этом большую гибкость.
Для любого сколько нибудь крупного проекта фреймворк, так же предпочтительнее и разработки на чистом php, поскольку все равно придется организовывать код, а так хорошо, как это сделано в фреймворке сделать все равно вряд ли получится, плюс время на наработку такого «библиотечного» кода потратится много.
Статью обязаны читать все «заказчики». По опыту переубедить делать серьезный проект не на «Битриксе» или «Друпале» порой бывает очень сложно. Теперь просто буду давать ссылку )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
7 причин для перехода с Drupal на Yii