eZ Publish, Drupal, TYPO3
Для доступа к форумам необходимо авторизоваться. Это можно сделать здесь
| Автор | |
|---|---|
|
|
|
Чт, 12 ноября 2009 9:56:05 С Друпалом сталкивался косвенно... На первый взгляд кажется кривым и неудобным, но можно привыкнуть. В принципе довольно хорошая система. Один из основных плюсов - развитое сообщество и куча готовых фич. В плане разработки/функциональности явных преимуществ перед eZ не заметил. Только неудобства (может из-за непривычки)С ТУРО3 не работал, сравнивать не могу Ссылки по теме: http://www.cmsmatrix.org/matrix/cms-matrix/ez-publish (там есть функция сравнения) http://cms-software-review.toptenreviews.com/ (не сочтите за рекламу, но в этом рейтинге eZ выиграло http://ez.no/company/news/ez_publish_is_on_top_at_toptenreviews ) Лично я на Друпал переходить пока не собираюсь) Тема о критики eZ как быстрого решения http://ezpublish.tv/ru/Forumy/Dly...vichkov/Eto-ne-ready-to-use-reshenie . Думаю она уже устарела после выхода новых фич позволяющих управлять сайтом использую драг-н-дроп и прочие пользовательские улюлюки |
|
Пт, 30 июля 2010 8:53:20 В основном разрабатываю под eZ и Drupal. C TYPO3 не работал давно, может что-то изменилось, поэтому мнение может быть не вполне адекватным. Но тем не менее попробую сделать небольшой сравнительный обзор всех систем описанных в вопросе.Начну с худшей на мой взгляд, TYPO3. Интуитивность интерфейса адмонки стремится к нулю, приходится долго обучать заказчика. Для создания нового типа содержимого приходится писать дополнения. Что бы создать хорошее дополнение, нужно написать три отдльно работающих компонента модуля и растолкать это по стого определённым папкам. Про отладку даже не хочется вспоминать. eZ Publish одна из лучших универсальных CMSок Содержимое хранится нодами, поля нод набираются за счёт классов и всё бы в этом было прикольно, если бы атрибуты(поля) можно было прикреплять к несколким классам одновременно, по крайней мере я такой функции не нашел. Это очень не удобно потому что иногда хочется сделать выборку, например, нодов любого типа с атрибутом email равным info@yandex.ru такие вопроси приходится писать подключением узко направленных экстеншенов. Интерфейс админки довольно сильно нагружен, но всё лишнее достаточно удобно кастрировать. Что казается разработки под систему, то тут всё лучше чем в предыдущем случае, всё содержимое можно хранить в одной папке правдо в стого определённой структуре описаннойчто касается настроек, тут тихий ужас, какие-то вещи определяются структурой, какие-то ini-шником, что-то определяется прямо в коде притом логику разделения уловить невозможно. При всём при этом под неё намного удобнее писать чем под ТИПО3. Переводится система файлами трансляции, такая система есть и в TYPO3 однако там всё нужно раскидывать опять же по папкам в eZ всё можно сложить в один файл перевода, поэому переводить систем удобнее. Есть один недостаток посравнению с предышущей админкой, это прожорливость, ресурсов система, которая позиционируется в основном как платформа интернет-магазина и корпоративного сайта просто немерено. Drupal считаю самой адекватной CMSкой на PHP в данный момент. В базовой поставке на друпале нет ничего, толко возможность писать одну ленту из постов, там даж админки как таковой нет, вся административная часть идёт в том же шаблоне что и сайт нет никаких удобных фичей администрирования, система кажется толком не расширяемой, потому как сколько бы мы не создавали типов нод, все они будут одинаковыми, до кучи друпал не имеет ничего общего с ООП. Это многих от системы сразу отталкивает и люди в ужасе убегают, но те кто попытался разобраться в системе будут приятно удивлены. Немного отойду от темы, и скажу что с eZ Publish я начал работать раньше чем с друпалом, считал её реально лучшей системой, но после знакомства с Drupal она мне кажется маленьким противным карликом, однако кое что делаю на ней по сей день. Вернёмся к обзору, за расширение типов нод, аля классы в eZ, в Drupal отвечает отдельно идущий модуль cck, разработан он давно и работает очень стабильно. Для выводов Уникалных списков нод, а не всё в одну кучу, как сделано по умолчанию используется модуль Views, он не только составляет списки различной степени сложности и связанности но и очень удобно расширяется под ваши нужды средствами специальных хуков, так что вам не нужно думать как в eZ бы вам извернуться с фетчем что бы вывести списки нодов из разных веток дерева и отсортировать их по какому-то признаку. Деревьев в Drupal кстати тоже нет, зато есть таксономия, это словари имеющюе любую вложенность какую вам надо и возможность привязаться к нодам по типам, более того словарей можно привязать несколько и сделать удобную фильтрацию содержимого. Разработка под друпал имеет 3 приятных отличительных особенности. 1. Модули имеют иерархию, а значит стандартный модуль можно заменить изменённым в конкретном проекте не залезая при этом в ядро 2. Модуль состоит из 2-3 файлов один файл описания модуля и связи его с другими модулями, второй непосредственно модуль, внём обявляются хуки, которых может быть от 1 до 6и, больше использовать ещё не приходилось, остальная логика может быть разнесена в отдельные файлы как заблагорассудится программисту, третий, не обязательный файл, файл инсталляции внём описано какие действия должна совершить система при установке и удалении модуля. 3 Forms API - система формирования форм в которой например можно легко добавить к любой форме кнопку отправляющую форму в обработку нестандартной функцией а написанной вами, при этом надо написать 3 строки кода, тогдака в eZ вам надо создать модуль с самой функцией, переопределить шаблон одной из стандартных форм, а потом ещё навесить action для обработки кнопки определённой вами функцией. Что касается админки она приводится в божеский вид темой RootCandy и модулями Admin Menu и Jquery menu, после чего админка становится привычного для конечных пользователей вида. Писал в спешке, посреди рабочего дня, прошу прощения за ошибки) |
|
|
|
Сб, 31 июля 2010 6:51:05 Обзор получился детальный ("многобуквенный" , но лично я что-то не увидел конкретных пунктов для сравнения  Попробуйте написать список фич с которыми вы сталкивались и потом описать как это реализовано в изи, а как в друпале. Список недостатков так же... а то в текущем списке недостатков/достоинств сравнивается "синее с квадратным". Не хочется чтобы о видеокамере судили по ее способности забивать гвозди PS Спасибо за незангажированное мнение разработчика! |
|
Сб, 31 июля 2010 15:20:18 Вообщем-то я привёл конкретные примеры по выборке нод, модификации форм и удобству подготовки списков. Если этого мало могу привести ещё один пример, модуль рассылки.Задачу эту выполнял недавно под eZ Publish, был в ужасе. Итак предаоложим нам нужно слелать модуль рассылки прайса у которого есть шаблонный оператор {form()} для вывода формы подписки на прайс, редактор заданий с фозможностю отправки файла и списки подписчиков и заданий. В eZ Pubhlish нам нужно 1.Создать модуль управления списками e-mail'ов и заданий с сортировкой списков Для этого нужно создать два отдельных представления для fetch с возможностью добавления лимита и сортировки по разным параметрам. 2.Создать определение для оператора + обработчик для оператора Для этого создаём автолоад, класс оператора и отдельное представление модуля для обработки данных формы 3.Для правильной работы экстеншна нужно обвесить его рядом конфигурационных файлов. В частности cronjob, design, menu, module, site и добавить собственный файл конфигурации для экстеншна, плюсом к тому если я хочу изменять эти настройки через админку нужно делать отдельное ответвление модуля для работы с файлом настроек. 4.Далее шаблон навигаци по компонентам модуля, это реальный идиотизм системы, нужно создать отдельный файл шаблона и руками в нём прописать с ссылки, а потом в каждом компоненте модуля дописать строку вида $Result['left_menu'] = "design:<название_эктеншна>/backoffice_left_menu.tpl"; 5.Для того что бы запускать рассылку мы создаём опять же отдельный файл для кронджоба, указываем информацию о нём в настройках, а так же, в рамках конкретной задачи, средствами eZ Publish нельзя(или можно но очень сложно) организовать внятную рассылку, поэтому пришлось подключить ещё и eZ Components. Вне пунктов разработки модуля добавлю ещё одну притензию к eZ Publish, это периодическая необходимость вызовов типа include_once('lib/ezdb/classes/ezdb.php'); и include_once( "kernel/common/template.php" );, что нельзя было сделать эктеншену доступным всё окружение системы. Ну да ладно, в целом это довольно удобный способ написания расширения, по сравнению с каким-нибудь движком типа Joomla Теперь рассмотрим способ написания того же модуля, по тем же пунктам в CMS Drupal 1.Создать модуль управления списками e-mail'ов и заданий с сортировкой списков Делаем обычные запрсы к БД(или через schema API кому как удобно) и создаём таблицы для вывода средствами Drupal, приемущество их состоит в том что в них есть hendler - система формирования заголовков, которая позволяет связать столбцы таблицы с полями mysql для сортировки, в итоге на создание каждого ис списков вам понадобится от 2х до 8и строк в зависимости от длинны запроса, и у вас уже готов управляемый список. 2.Создать определение для оператора + обработчик для оператора С этим в друпал вообще всё просто, вы просто делаете функцию темы(формы) и вызываете её в нужном месте шаблона, прямо в описании формы вы выбираете какая функция её будет отрабатывать, никаких отдельных представлений модуля. 3.В друпал всё делается так называемыми хуками, функциями которые система отлавливает сама, вам не нужно писать кучу определений и настроек что бы система знала что у вас есть модуль и о том что он может делать. Сделать активные настройки не проблема, вы просто создаёте форму settings_form а о том где и как хранятся настройки и как их обрабатывать система заботится сама, вы просто dspsdftnt aeyrwb. variable_get которой передаёте имя поля в форме настроек. 4.Навигация достигаестя при обьявлении представлений модуля, система сама складывает ссылки в навигацию и показывает их пользователям имеющим доступ к модулю или его части. Если содержание меню надо поправить используется хук hook_menu_alter, но в основном это не нужно по этому над четвёртым пунктом в Drupal в отличае от eZ работать почти не надо. 5.Что бы запускать рассылку мы применяем хук hook_cron который вызывается пи вызове крона системы, как уже было сказано ранее хуки в друпал не только работают как обычные функции, выполняя какой-то набор действий, но и повествуют системе Drupal о возможностях модуля, т.е. никакой конфигурации и объявления о том что есть файл крона нам делать не понадобится. На этом повесть свою пожалуй и завершу, есть ещё ряд примеров выгодности друпала, однако считаю что одного примера более чем достаточно, если комуто интересно получить болше информации о системе, посетите сайт русскоязычного сообщества Drupal. Добавлю так же что с eZ Publish активно работаю с 2007ого с Drupal c ноября 2009, в 2007ом тоже пытался работать с Drupal, но тогда он утупал eZ Publish, сейчас картина обратная. P.S. Ещё пару слов о рейтинге http://cms-software-review.toptenreviews.com/ Там eZ Publish выиграл по причине наличия "всего из коробки" магазина, внешнего вида админки и т.п. Всё это в системе Drupal есть, и в части электронной коммерции даже лучше, но не из коробки, потому что Drupal скорее конструктор CMS чем ready-to-use система. А про оченку безопасности можно вообще анекдоты складывать, при нажати на ссылку Security мы получаем сообщение "This category examines the type of verifications and authentication protocols supported by the system.(Эта категория рассматривает тип проверки подлинности и протоколы, поддерживаемые системой.)". Дело в том что тип проверки у систем Drupal и eZ одинаковый и протоколы применяемые системами практически одинаковы, только в Drupal есть ещё поддержка проторола Вконтакте. А разница в позиции между братьсями блезницами, joomla и mambo вообще бредова особенно по пункту Commerce, учитывая что обе системы используют для этих челей один и тот же модуль VirtueMart. |
|
|
|
Вс, 1 августа 2010 7:23:31 Ваш пример демонстрирует неоптимальное использование системы. Про универсальность и масштабируемость реализации на Drupal'е тоже умалчивается. Могу предложить навскидку еще 2-3 варианта реализации формы отправки (newsletter, notification, custom extension) А аргументы типа "нужно создать отдельный файл" выглядят смешными. Если я дружу с файл-менеджером и кнопками Ctrl+C Ctrl+V но не дружу с SQL то я так же могу сказать, что написать запрос "от 2х до 8и строк" это очень неудобно Настройки нужны для того, чтобы можно было что-то включить/отключить/подправить не залезая в шаблоны и уж тем более в php-скрипты (как в свои так и в чужие).Раздел форума называется "Для руководителей". Так вот есть одно важное преимущество, которое дает применение объектно-ориентировочного подхода в программировании - меньшие трудозатраты при большом количестве типовых проектов. Если я для eZPublish напишу расширение по отправке прайсов, то его можно будет быстро адаптировать для других проектов. При чем не как узкоспециальное решение, а как универсальное - можно отправлять один прайс, а можно несколько разных, а можно разным группам пользователей, а если надо, то и не только прайс отправить можно и т.д. Сам я с Друпалом довольно поверхностно знаком. И мне он сперва очень не понравился, но потом я понял что это мощная CMS-ка. Вот только для реализации и поддержки сложных масштабируемых систем я бы стал использовать именно eZ. На счет безопасности: не знаю как там с Друпалом, но посмотрите раздел с уязвимостями eZ на официальном сайте - "дыр" и "дырочек" не так и много... они появляются редко и сразу патчатся. Про джумлу и мамбу сморить не буду - в свое время пытался что-то делать на джумле - все закончилось написанием собственного "движка"... из впечатлений - одни междометия Мамбу не юзал, но она по идее должна отличатся только меньшим количеством багов (возможно отсюда и разница в вышеупомянутом обзоре).
|
|
Пн, 9 августа 2010 8:31:09 Какая-то беготня по кругу получается, я говорю Drupal удобен, вы мне говорите про то что можно привыкнуть к корявости eZ Publish и использовать Ctrl+C Ctrl+V, мне просто не нравится что я должен описывать свой экстеншт в 5и местах, я не доволен тем что за меня подумали разработчики eZ и в конце-концов мне приходится тратить больше времени на обучение специалистов работе с eZ. Я не отказываюсь от настроек и в своём примере я явно указал информацию о работе с настройками Drupal.Как показывает практика объектность eZ прироста в скорости не даёт, только усложняет вопрос, потому что надо делать несколько дочерних классов для работы, запоминать в каком классе, какие фунции используются, а делать класс дочерним для 2х и более классов в eZ приводит к просто непредсказуемым результатам, т.к. в разных классах могут применятся функции с одним названием и разными результатами работы, всё это надо отлавливать и переопределять, иногда быстрее собрать систему из какого-нибудь ООП фреймворка, типа симфони, чем из eZ. В Drupal всё просто, всё в функциях, притом для работы о кружнием системы там есть всё, а если мне надо подключить какую-то дополнительную функциональность, никто мне не мешает использовать классы для выполнения своих целей, например популярный модуль views использует ООП подход. Поэтому разработка под Drupal в 2-3 раза проще и сорответственно на неё тратится меньше времени. После утверждения "Вот только для реализации и поддержки сложных масштабируемых систем я бы стал использовать именно eZ." явно что знакомы вы с Drupal очень-очень поверхностно, потому что масштабировать систему сделанную на Drupal проще, за счёт системы переопределения модулей, что избавляет от необходимости заниматься рефакторингом ранних разработок, и Drupal поедает намного меньше ресурсов системы. На счет безопасности у Drupal всё даже лучше, сообщество больше дыры выявляются быстрее, патчятся тоже. Сайт белого дома вряд ли бы стали делать на дырявой системе. В целом сейчас eZ Publish используется только по тому что на нём нами сделан уже ряд готовых решений, все новые сборки делаем на Drupal и это реально быстрее и удобнее чем раньше с eZ, поэтому лучше один раз познакомится с системой поближе, чем после "поверхностного" знакомства утверждать, что Drupal плохо масштабируем или требует больше времени на разработку. |
|
|
|
Пн, 9 августа 2010 17:54:15 На счет сайта Белого дома - сайты часто заказывают делать на том или ином движке только потому, что знакомы лишь с несколькими движками или потому, что так проще организовать совместимость (например, контора заказывает сайт на каком-то движке ибо их служба тех поддержки использует именно его на других проектах). Знаю сайт одного американского губернатора, сделанный на изи На счет удобства настроек - при поддержке сайта мне удобней безболезненно поменять одну настройку в файле настроек, чем лазить по движку в поисках шаблона/скрипта в котором я должен что-либо править. И при надобности я могу попросить это сделать менее квалифицированного сотрудника это сделать, не отвлекаясь при этом и не боясь что-то поломать. На счет моих поверхностных знаний друпала - над проектом который меня касался работали более продвинутые php-прогарммисты, чем я. И им тоже приходилось долго ковырять именно те особенности системы, которые Вы причисляете к ее преимуществам (отсутствие деревьев, например). На счет ресурсов и Друпала ничего не могу сказать. Видимо тут надо уметь настраивать. Ибо Друпал у меня (когда я его тестировал) падал именно из-за проблем с памятью (как раньше бывало у новичков c eZ). Обучить новичка работать с базовой функциональность eZ могу за неделю-две. Настраивать экстеншны не так просто. Для этого надо создать аж 5 файлов Это я утрирую - для расширения переводов, к примеру нужно потратить 10 минут рабочего времени http://ezpublish.tv/ru/forumy/Dly...iya_perevodov_translation_extensions и создать целый один файл настроек. Чтобы подключить несложный модуль - нужно еще один файл настроек и файл с самим скриптом. Тут сложность структуры сильно зависит от поставленной задачи. Но ничего титанического не припомнюНаконец-то про безопасность. Можно проводить статистику Сравнить http://ez.no/developer/security/security_advisories и http://drupal.org/forum/1852 Визуально все соразмерно Я не хочу зацикливаться на одной cms. Для своей домашней странички я бы ее не использовал потому, что не потяну по ресурсам хостинг. Для блога или форума я бы тоже ее не выбрал. Но я и мои коллеги работающие с eZ достаточно хорошо знают систему чтобы в сжатые сроки решить поставленную задачу. И поддерживать качественно написанный сайт на eZ - одно удовольствие. Но это мнение разработчика. Для моего начальства и для начальства заказчиков тоже есть свои плюсики Видел проекты, где на одном движке eZ работали десятки сайтов (очень редко и сотни).Если вы руководитель крупной компании, то думаю сможете оценить преимущества системы, где все сайты отделов структурированы и управляются в одном месте. При этом существует система разграничения прав доступа к содержимому. При этом к сайт можно прикрутить что угодно Например расширения импорта/экспорта данных, расширения удаленного редактирования, интеграцию с фейсбуком и твиттером, а для особо заинтересованных хоть расширение для связи с космосом. При этом у сайта есть еще и флешовая версия и версия для pda.Уверен, что найдутся умельцы, готовые повторить это все хоть на ВордПрессе. И скорость разработки сильно зависит от кривизны рук разработчика. Как говорил один преподаватель: "лучшая книга - прочитанная". А лучший движок - быстро заточенный под реальную систему. Ну и естественно каждая свинья свое болото хвалит. Я не исключение Поэтому не стоит причислять к объективным свойствам (недостаткам или преимуществам) системы субъективные предпочтения. Кто-то любит делать все с нуля, а кто-то - возвращаться к условиям предыдущей задачи (как в анекдоте про математиков). Кто-то любит Генту, а кто-то - Убунту. Так и в движках - кто-то любит быстро написать и подключить модуль, а кто-то - скопировать готовый и поменять настройки. А разработчики на java тоже могут вмешаться и как недостаток указать некомпилируость программ на php Jedem das Seine
|
