Поправьте меня если я не прав:
1. Вы считаете, что Apache со своей армией потомков нормально без nginx может обслуживать медленные соединения и это не отразится на занимаемой памяти? Если так, то вы ошибаетесь. Nginx стоит поставить перед apache как минимум для того, чтобы процесс apache быстро отдал ответ nginx-у и освободил память для следующего запроса, а nginx уже разберется с медленным клиентом без затрат дорогого ресурса.
2. Вы не стали использовать nginx потому, что не нашли в репозиториях, а «make делает любой дистрибутив… и дальше по тексту»? Тогда это просто лень, чреватая проблемами именно в ситуации ограниченных ресурсов VDS
Себестоимость sms равна нулю, ресурс сети одинаково используется и когда шлются смс и когда нет. Но чрезмерное количество sms может сделать работу сети настабильной, что впрочем снова не имеет никакого отношения к себестоимости sms. Иными словами стоимость sms рассчитывается исключительно из коммерческой выгоды.
Ага, положим нафиг сеть опсосам :) Они же так хотели бы, чтобы мы делали мало длинных сессий, а получится, что мы с этими GPRS-EDGE-чатами забьем командный канал сильнее, чем сейчас sms-ками и они еще пожалеют об этом.
sms, ЕМНИП, использует командный канал, который в отличие от остальных каналов не расширяется т.е. имеет фиксированную полосу. А используется и под установку соединения, и под коммутацию остальных каналов. Этим опсосы и объясняли беспрецедентную стоимость sms в сравнении с другими услугами передачи данных. Правда никто из них не пошевелился перенести sms в каналы данных, поскольку это не только дешевле, но и уменьшило бы стабильность работы сети, как уменьшают ее мобильные устройства, которые часто «проверяют почту». Короче говоря ни с чем однозначным к опсосам не придерешься, хотя пахнет эта ситуация плохо.
Ну да, что еще было от вас ожидать. Снова заявления о том, что архитектуры может не быть, снова превознесение одних технологий за то, что они де «современные», и принижение других за то, что они не понятны.
Самое интересное — спор о терминах. Dispatch, routing, menu… Вам как будто не все равно как оно называется. Или с той же энергией вы собираетесь рассказывать носителям другого человеческого языка, что он называет всё не правильно? Какое барбекю, — с пеной у рта будете кричать вы, — шашлык, вот как это правильно называется! Дураки все, кто шашлык называет барбекю. И вообще английский это неудобный велосипед — целых 20 времен и нет падежей.
Короче говоря — сюр невыразимый. Спасибо, давно так не смеялся, как при общении с вами.
Ах вот к чему вы придираетесь. Да, конечно, эти кешеровщики существуют, как существует и системный кеш для открываемых файлов. Но равенства по затрате ресурсов между одним файлом и 50 не будет никогда. Теперь ситуация — у вас есть набор функций, которые вам нужно вызывать часто, но совсем не нужно модифицировать. Вам, как разработчику модулей, (но не ядра) есть хоть какая-то разница в скольки файлах они лежат, если вам даже упоминать подгрузку этих файлов никогда не потребуется? Ответ очевиден — это обстоятельство не имеет ровным счетом никакого значения. Я бы даже не стал об этом вспоминать, если бы не смешные наезды блондинко-программера.
Ладно, я думаю, дальнейший спор уже ни к чему не приведет. Все равно я останусь при своей точке зрения, а вы при своей.
Какая прелесть — программист с «эмоциональной» логикой блондинки. Так для вас изначально наговорить гадостей в сторону Drupal и его разработчиков важнее, чем разобраться сколько под вашими словами правды? Я привожу доводы на конкретные глупейшие замечания. При этом я не являюсь фанатом Drupal и знаю его недостатки лучше многих критиканов. Я делаю это не из привычки и не из преданности. Мне вообще наплевать и я не привязан. Есть проекты, в которых Drupal подходит, есть те, в которых не подходит. Но я не буду его говнять только потому, что мне лень в нем разобраться.
Если у вас хорошо получается делать сайты на Друпале, и клиенты довольны, то можно только порадоваться за вас.
Разве мы об этом спорили? Мы спорили об архитектуре. Вы вообще отказывали в логике там, где она есть.
Вы еще спрашивали, что я думаю о коде джумлы — смотрел мельком когда-то давно, не понравилось.
Мне всё равно понравился вам код Joomla или нет. Я спрашивал профессионального, по возможности, мотивированного мнения о его качестве, раз уж вы позиционируете себя как специалист. Спросил это для того, чтобы откалибровать шкалу представлений о качестве кода подобных движков. Лично я нашел код Joomla чрезвычайно непродуманным и полным костылей.
Что «жесть» то? Для вас не понятно, что один файл с функциями, в которые не надо постоянно лезть разработчику лучше, чем 50 файлов с теми же функциями? Ну так почитайте на досуге про файловые дескрипторы. Или может кто-то из системщиков объяснит, что для системы, для которой эти 200 функций нужно постоянно загружать в память (под Apache на каждый запрос) есть существенная разница между тем один это файл или 50.
А при чем здесь ядро? Я говорю про модуль views, в котором это есть уже минимум года три. Вы хотите сказать, что пользуетесь еще более древней версией views?
Я написал десятки модулей разной сложности для десятков сайтов. Бывают модули с чёткой и понятной функциональностью, а бывают и вот такие:
…
Это весь модуль.
А я весь этот набор мелких правок под конкретный сайт, которые больше нигде не пригодятся объединяю в один модуль, который обычно и называл именем сайта. В последнее время для большей гибкости этот модуль имеет машинное название «zzz», чтобы было проще рефакторить. Ничего предосудительного в таком подходе не нахожу.
Для этой же view в template.php +15 строчек, чтобы просто добавить class к table.
Правильнее в рамках идеологии Drupal скопировать из модуля views в свою тему файлик views-view-table.tpl.php и вписать туда все свои хотелки прямо в html часть.
И еще много строчек, чтобы URL сделать ссылкой в таблице (не ставя для этого модуль на сотни строк кода).
Бедняжечка. Вот что с людьми лень делает. Ну прочти же ты доку по themeing один раз. тот же файлик темы views-view-table.tpl.php с включением простого ветвления даст тебе это сделать просто и элегантно. И, кстати, более производительно.
Не путайте свои недостатки с чужими достоинствами. Тем более что вы просто не поняли что то, что подразумевается под хуками в Drupal, не имеет никакого отношения к вашим костылям.
Если мне не изменяет память, там есть шаблон для вывода отдельной ноды, и шаблон для вывода списка нод, который получает на вход 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 такая архитектура, что хуками в модулях обозначаются перехваты определенных операций. В сравнении с механизмом, к которому вы привыкли это «та же жопа только в профиль».
Поменять заголовок можно не только хуком, но и соответствующим node--type.tpl.php, который никакого отношения к хукам не имеет. Да и вообще ваше отношение к хукам выглядит каким-то суеверным ужасом, хотя выше вы показали, что знаете что требуется для регистрации модуля в движке, но напрочь отрицаете событийную архитектуру.
Ей богу, вы самый странный программист из встреченных мною за долгую профессиональную жизнь.
Спасибо, что описали свое мнение подробнее. Правда единственная мысль которая возникает при чтении — вы свято уверены, что для решения существует ровно один способ — тот, который знаете вы. И именно его вы ожидаете увидеть в правильной архитектуре, а остальные не правильные.
Ок, насчет 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, с модульной инфраструктурой, расширяемостью и «правильной» архитектурой, лишенной недостатков этих ужасных продуктов?
1. Вы считаете, что Apache со своей армией потомков нормально без nginx может обслуживать медленные соединения и это не отразится на занимаемой памяти? Если так, то вы ошибаетесь. Nginx стоит поставить перед apache как минимум для того, чтобы процесс apache быстро отдал ответ nginx-у и освободил память для следующего запроса, а nginx уже разберется с медленным клиентом без затрат дорогого ресурса.
2. Вы не стали использовать nginx потому, что не нашли в репозиториях, а «make делает любой дистрибутив… и дальше по тексту»? Тогда это просто лень, чреватая проблемами именно в ситуации ограниченных ресурсов VDS
Самое интересное — спор о терминах. Dispatch, routing, menu… Вам как будто не все равно как оно называется. Или с той же энергией вы собираетесь рассказывать носителям другого человеческого языка, что он называет всё не правильно? Какое барбекю, — с пеной у рта будете кричать вы, — шашлык, вот как это правильно называется! Дураки все, кто шашлык называет барбекю. И вообще английский это неудобный велосипед — целых 20 времен и нет падежей.
Короче говоря — сюр невыразимый. Спасибо, давно так не смеялся, как при общении с вами.
Какая прелесть — программист с «эмоциональной» логикой блондинки. Так для вас изначально наговорить гадостей в сторону Drupal и его разработчиков важнее, чем разобраться сколько под вашими словами правды? Я привожу доводы на конкретные глупейшие замечания. При этом я не являюсь фанатом Drupal и знаю его недостатки лучше многих критиканов. Я делаю это не из привычки и не из преданности. Мне вообще наплевать и я не привязан. Есть проекты, в которых Drupal подходит, есть те, в которых не подходит. Но я не буду его говнять только потому, что мне лень в нем разобраться.
Если у вас хорошо получается делать сайты на Друпале, и клиенты довольны, то можно только порадоваться за вас.
Разве мы об этом спорили? Мы спорили об архитектуре. Вы вообще отказывали в логике там, где она есть.
Вы еще спрашивали, что я думаю о коде джумлы — смотрел мельком когда-то давно, не понравилось.
Мне всё равно понравился вам код Joomla или нет. Я спрашивал профессионального, по возможности, мотивированного мнения о его качестве, раз уж вы позиционируете себя как специалист. Спросил это для того, чтобы откалибровать шкалу представлений о качестве кода подобных движков. Лично я нашел код Joomla чрезвычайно непродуманным и полным костылей.
А я весь этот набор мелких правок под конкретный сайт, которые больше нигде не пригодятся объединяю в один модуль, который обычно и называл именем сайта. В последнее время для большей гибкости этот модуль имеет машинное название «zzz», чтобы было проще рефакторить. Ничего предосудительного в таком подходе не нахожу.
Правильнее в рамках идеологии Drupal скопировать из модуля views в свою тему файлик views-view-table.tpl.php и вписать туда все свои хотелки прямо в html часть.
Бедняжечка. Вот что с людьми лень делает. Ну прочти же ты доку по themeing один раз. тот же файлик темы views-view-table.tpl.php с включением простого ветвления даст тебе это сделать просто и элегантно. И, кстати, более производительно.
Вам изменяет память. С ленью. Будь вы менее ленивым, прочли бы документацию по темизации. Повторяю еще раз — ваша задачка решается одним файлом в каталоге темы. Внутри этого файла вам надо организовать два цикла по одному и тому же массиву. Решение настолько тривиально, что даже не имеет смысла его разжевывать.
Да вы просто медитируете на правильность единственного пути. Умные люди говорят — у плохого актера 3 маски, а у хорошего не меньше чем 33. Это применимо и к программистам. Вы актер одной маски OOP. Другими парадигмами вы пользоваться не умеете. Оттого и ваши слепые перетяжки вроде «раз программирование не объектное, значит переменные глобальные и объявлены чёрт знает где». Код Drupal таким не является, хотя вы упорно это игнорируете. Переменные хранятся в базе, модули представляют собой абстракцию вроде объектов и объявленные внутри них переменные в другие части кода не попадают. Почему, вам наверно не дано понять с вашим упорством утверждать то, что вы думаете вместо того, что есть на самом деле.
Нет, альтернативность не в этом, хотя этот файл мало чем отличается от многих серьезных библиотек. Конечно если у вас нет IDE с поддержкой навигации по функциям, вам будет неприятно разбираться в коде этого файла, но если учесть, что лезть туда вам вряд ли вообще потребуется, то он всего лишь экономит файловые дескрипторы и не более того.
О какой папке идет речь? Об одной из десятка папок ядра? По моему вы сильно перегибаете палку. Разработчику сайта, темы или модуля вообще незачем трогать ядро. Тактика разработки на Drupal как раз и заключается в том, чтобы весь код модификации можно было атомизировать в пределах одной папки — папки модуля занимающегося конкретной работой. Черт, кому я это рассказываю? Твердолобому фанату своей школы, который не собирается разбираться в том, что критикует?
:) А можно посмотреть на это и по-другому. Мало у кого хватает мозгов понять стройность и гениальность такой сложной и самобытной системы. Вот и ценятся специалисты, которые знают как одинм файлом в теме решить задачу для которой другие будут переписывать модуль views или писать свои костыли, как предлагали вы выше.
Там дело не в запутанности, а в гибкости. Этот движок явно предназначен не для высоконагруженных приложений, но на своем любимом фреймворке вы потратите не один человеко-год, чтобы дать заказчику столько власти над контентом и структурой сайта, сколько Drupal дает из коробки. Жаль, что вы слишколм упрямы, чтобы принимать такие аргументы, вы же считаете себя носителем единственно правильного пути в интерфейсе и функционале админки, не так ли?
Вообще-то это эелементарно, но для тех, кто понимает как организован Drupal. Я например для разгрузки очень посещаемого сайта использовал перенос кеширования с MySQL на memcache. И сделал это drupal-way — отдельным модулем, который как бы вам не казалось невероятным спокойно обслуживает все обращения к кешу из всех модулей. Повторяю ничего непредсказуемого в движке не происходит, просто порядок вызовов и динамика данных обусловлена не написанной одним программистом последовательностью, а заранее определенной при помощи программы последовательностью вызовов хуков. Вся разница в том, что делается это галочками в админке, а не кодом в специальном файле, как вы привыкли (и похоже больше ничему не учились).
Я же предлагал не придираться буковкам. Главная задача 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 :)
Поменять заголовок можно не только хуком, но и соответствующим node--type.tpl.php, который никакого отношения к хукам не имеет. Да и вообще ваше отношение к хукам выглядит каким-то суеверным ужасом, хотя выше вы показали, что знаете что требуется для регистрации модуля в движке, но напрочь отрицаете событийную архитектуру.
Ей богу, вы самый странный программист из встреченных мною за долгую профессиональную жизнь.
Во-первых если вы какой-то запрос переписываете, то делаете это не со всем запросом, а только с той частью, которая вам нужна. Обычно вы туда добавляете поля через 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, с модульной инфраструктурой, расширяемостью и «правильной» архитектурой, лишенной недостатков этих ужасных продуктов?