Писать или не писать свю CMS?

Просмотров: 17920Комментарии: 32
Web frameworks

Я тут напряженно думаю над вопросом. Нужна CMS. Вообще-то, у нас уже есть рабочий вариант, и вполне хорошо работает. Но познакомившись с Kohana уже практически невозможно работать с обычным PHP-кодом. Поэтому хочется Kohana-based CMS, чтоб легко и непринужденно дописывать модули, расширяя и расширяя ее под бесконечно разнообразные нужды любимых заказчиков.

К сожалению, одной из немногих проблем фреймворка является отсутствие под него готовых ЦМС. Все, которые есть, пока еще в разработке. А насчитал я всего 2,5 штук. Это YurikoCMS, s7ncms и Hanami  (у которой пока отстутсвует версия для скачивания, только SVN, -- потому и посчитал ее за 0,5 штуки smile.

В общем, скачал две первые, попробовал. С "полпинка" завелась только s7n, но оказалась на удивление приятной, хотя и весьма аскетичной по возможностям (создание/удаление/редактирование админов, страниц, подключение/отключение модулей, двуязычные публикации и пр.). Естественно, разработчик не судит о перспективах по первому впечатлению об интерфейсе, поэтому придется углубиться в код. И вот тут меня, вероятно, будет ждать непростой выбор: присоединяться к какому-нибудь из уже имеющихся проектов либо начинать свое с нуля. Скажу прямо: творческие муки меня беспокоят меньше, чем необходимость быстро и качественно делать дело, и с этой точки зрения хотел бы присоединитья к уже начатому (тем более времени в обрез, идут два неслабых проекта). Однако только изучение кода покажет, насколько возможности имеющихся вариантов идейно мне близки, ведь не хочется заниматься тем, на что потом буду морщась смотреть.

Из идеологических соображений наиболее существенны для меня следующие:

  • компактное ядро, предоставляющее базовый функционал (прием запросов, безопасность, аутентификация, возможно кэширование + шаблоны) -- по сути то же, чем является Kohana, только более высокого уровня
  • модульность -- весь остальной функционал (разделы сайта, отдельные страницы, текстовые и прочие блоки) реализуется через систему относительно самостоятельных модулей
  • прозрачная система межмодульного взаимодействия (бич многих CMS) -- впрочем, это наверное недостижимо smile
Вот. Буду сильно подумать...

Комментариев: 32 RSS

1 Броткин Иван 22-05-2009 14:58

Да, я тоже еще не видел ни одного развитого проекта с открытым кодом. Чем хорошо написание своей CMS - можно ее создавать под свои идеалы. Чем плохо тоже понятно - пишем только в свободное время, которого ох как мало :(

2 Александр Купреев 22-05-2009 15:12

Есть тут еще одна проблема. А вдруг у меня идеалы неправильные smile? Можно ли это проверить как-нибудь кроме попыток написания кода?

3 Броткин Иван 22-05-2009 15:42

Ну, приведенные пункты выглядят вполне логично (разве что прием запросов не совсем понятен, это Вы про Routing?). В конце концов, если грамотно спроектировать систему, то и вносить изменения более-менее приятно. Другое дело, кто бы еще научил этому самому проектированию ;)

4 Александр Купреев 22-05-2009 15:47

К сожалению, даже если в общем все ОК, проблемы начинаются в деталях. Ими то и планирую заняться, если повезет, то в ближайшее время smile

5 Броткин Иван 22-05-2009 15:57

Удачи Вам на этом нелегком пути smile

PS. Три подряд каптчи были одинаковыми (4220, буквы менялись). Это так и задумано?

6 Александр Купреев 22-05-2009 16:16

Спасибо smile

Насчет капчи -- не знаю, я просто разместил объяву не лазил в код. Скорее всего так не задумано, но боты пока не беспокоят smile

7 Wave 23-05-2009 20:58

А чем плох вариант с MaxSite CMS?

Основана на прародителе коханы — кодигнайтере. Развивается уже полтора года. Довольно много возможностей, стройная архитектура (тут дифирамбы в сторону макссайта).

Я вобщем-то пришёл к выводу, что свою CMS хоть сколько-нибудь общего назначения нельзя сделать меньше чем за полгода, а лучше год (это понаблюдавши за несколькими проджектами). Более-менее быстро можно под конкретный проект взять фреймворк, несколько библиотек (авторизация и права, … … … и т.п.). Но это будет довольно специализированный проект. Плагины к нему прикручивать — переделка в две недели-месяц-два. Спроектировать масштабируемую архитектуру (считая поддержку плагинов, типы данных и т.п.) — это тоже немало времени. Каждая конкретная задача решается быстро, день-неделя-две-три, но этих задач набирается уйма!

А потом приходим к более-менее законченному варианту, прогулявшись попутно по множеству граблей, и понимаем, что к своей CMS нет плагинов-модулей, или всего несколько, которые написались в процессе разработки. К тому же макссайту уже за 60 плагинов, а всё равно на очереди ещё минимум три крупных, и минимум две-три серьёзных переделки-доделки в админке.

Короче, писать свою CMS имеет смысл только если охота посвятить этому делу несколько лет и иметь на неё виды. Например, Макс очень много на своём движке ставит сайтов. И т.п.

Капча — так и задумано. На одной и той же странице в течении одной и той же сессии — одна и та же капча. Для удобства посетителей. Лень искать ссылку, где Максим объяснял, почему так.

8 Александр Купреев 25-05-2009 12:43

Абсолютно согласен со многимим вашими тезисами, Wave. Действительно, разработка ЦМС это длительный и непростой процесс (респект Максу за то, что решился на этот шаг!). Одному делать все действительно долго и сложно (именно поэтому я и хотел бы присоединиться к уже существующему проекту). В этом отношении MaxSite вправду представляется интересным вариантом, таковым я ее считаю и сейчас.

Но есть два НО:

1) CodeIgniter, который вызывает отторжение после знакомства с Коханой (чего стоят одни многочисленные @, разбросанные по коду и потенциально могущие служить источником проблем)

2) некоторые проблемы в архитектуре MaxSite, связанные, в первую очередь, с недостаточной модульностью. Оговорюсь сразу, что система хорошая и красивая (диферамбы вполне уместны), насколько могу судить, но она все же ИМХО для продвинутого юзера, а не для разработчика. То есть плагины могут многое, но не "почти все", а сердце девелопера жаждет именно этого smile. Чтоб не быть голословным, свежий пример: пишу возможность оставлять комментарии по OpenID. И натыкаюсь да досадную штуку: плагином этого не сделать, потому что процедура логина жестко "вшита" в workflow системы, надо переписывать чуть ли ни в ядро. А если бы, скажем, она вызывалась по хуку, стало бы немного проще: перехватил хук и вперед!

Собственно, одно время я даже думал портировать MaxSite на Kohana, но поглядев на такие штуки, решил что проще написать с нуля (с учетом достижений предшественников, естественно smile

ЗЫ. S7N в отношении кода ядра вполне себе ничего так

9 Wave 25-05-2009 17:16

У Hanami в svn 101 ревизия с июня по декабрь прошлого года.

Т.е. уже должна быть развитая, но, возможно, заброшенная система.

YurikoCMS — кто бы мне подсказал, как скачивать из git-репозитория посредством svn. Но на сайте сказано, что система молодая.

s7ncms — 400 коммитов с ноября 2007. Т.е. выглядит наиболее разрабатываемой и с самой длинной историей. И в этом отношении вариант привлекательный.

10 Александр Купреев 26-05-2009 12:28

YurikoCMS — кто бы мне подсказал, как скачивать из git-репозитория посредством svn.

Боюсь что никак smile Проще скачать архивом с гитхаба (http://github.com/Zeelot/yuriko_cms/tree/master)

Кстати, гит это здорово smile

11 Бурцев 30-05-2009 18:41

Согласен с вами, после знакомства с коханой, кодигнитер ставновится каким то ущербным =)

Коль уж вы уже пилите напильничком, расскажите первые впечатления от этой CMS. Я вот начал свой двиг писать на кохане, тока геморно плучается.

12 Александр Купреев 01-06-2009 01:16

К сожалению, прямо счас сижу на модеме на плохой связи, поэтому развернуто ответить не могу :( Постараюсь в ближайшем будущем написать обзор на тему.

13 Влад 08-06-2009 17:22

Читаю и удивляюсь, как будто кто мои мысли читает. Все те же мытарства и поиски: CodeIgniter->MaxSiteCMS->Kohana->s7ncms. Хотел было MaxSite докручивать, но устал от функционального программирования, от этого бардака с функциями...захотелось модульности, загляделся на kohana - после MaxSiteCMS как-будто свежего воздуха глотнул - код чистый, красивый, понятный, все по полочкам все чинно и порядочно. Надо общими усилиями развивать kohana и стимулировать Броткина Ивана на создание CMS grin

Может перелопатить ту же s7ncms под наши отечественные нужды и развивать её далее?

14 Александр Купреев 08-06-2009 18:11

Коль уж привередничать, то по-крупному smile

S7N тоже, на мой взгляд, недостаточно модульна и гибка. Простейший пример -- работа с облаком тэгов. Ну не нашел я, как управлять им из веб-интерфейса, возможно, плохо искал. Конечно, система еще развивается, но от "корней" всегда непросто отойти.

Систему Ивана я не смотрел пока.

В идеале хотелось бы в плане ЦМС что-то подобное самой Kohana, только на более высоком интерфейсном уровне. То бишь маленькое ядро, обеспечивающее прием и маршрутизацию запросов + легкую стыковку модулей. А дальше -- модули, модули везде. Возможно такая радикальность необоснована и даже вредна, тут думать надо. Полагаю, что просто сесть и написать код не получится, надо порисовать, помозговать. А времени нету счас :(

15 Sezarin 05-08-2009 11:26

Полагаю, что просто сесть и написать код не получится...

Совершенно верно, Александр.

Кроме того, считаю, что разработка CMS на базе фреймворка VMC-структуры, не блоговой, не новостной, а более-менее универсальной, ну хотя бы как EE, например, - идея, можно сказать утопичная.

Я не беру в расчет те кустарные "одноразовые" экземпляры, которые то и дело появляются и исчезают. PHP фреймворков - десятки, развиваются годами, но дальше ручного, штучного использования дело не доходит. И этому есть свои причины...

И дело здесь не в недостаточности мощности или гибкости той или иной исходной структуры. Проблема в отсутствии простого, легкого шаблонизатора, использование которого позволило бы легко организовать логику html шаблона без програмного кода. Ну хотябы, как у VIVVO CMS.

И забудьте про ставший уже традиционным подход - сначала покромсать все на мелкие кусочки, а затем програмно сгенерировать, а хуже того - сгенерировать html абстрактно! Время доказало несостоятельность такого подхода. Да, конечно, каждый программист вправе делать под себя все, на что он способен и как ему удобно, но не нужно это переносить в массы...

А фактически, будь то крупная, мелкая веб дизайн студия или просто, фриленцер - все ини предпочитают одно: возможность сверстать html шаблон, подогнать под браузеры, а затем легко, без лишней php-мороки посадить его на движок. Да, они готовы платить за это деньги. Возможно, этим и объясняется невероятно высокая популярность системы ExpressionEngine.

Но вот, как только дело дошло до пересадки его на CE - пауза, вот уже второй год, с момента объявления. А ведь у них уже был немалый опыт разработки коммерческого продукта, уникальная система шаблонизации, а главное, ихний-же CodeIgniter позиционируется как оболочка для быстрой разработки приложений. Так-что, думай - не думай, а...

16 Александр Купреев 05-08-2009 12:00

Спасибо за такой развернутый комментарий, Sezarin, было очень интересно читать.

Знаете, я наверное даже соглашусь с тем, что единый шаблон это Почти Абсолютное Благо, хотя до этого такая мысль меня не посещала (я просто программер во много раз больше, чем верстальщик).

И тут, конечно, есть определенное противоречие (я рискнул бы назвать его заумным словом «онтологическое»): с одной стороны, идеальным шаблоном была бы статическая разметка страницы, но с другой стороны, современный сайт динамичен, что автоматически делает невозможным создание полностью статичного шаблона. И все современные подходы, по сути, пытаются обойти это противоречие. Одни обходят его ближе к верстальщику — используют систему шаблонизаторов. Другие ближе к программисту-разработчику — и появляются «лоскутные» системы.

Не знаю, разрешимо ли такое противоречие в принципе — скорее нет, чем да. Но давайте задумаемся вот над чем: а надо ли его разрешать в принципе? Для того, чтобы штамповать сайты сплошным потоком, только «натягивая» дизайн, достаточно легко создать систему. Но она, разумеется, и не будет претендовать на универсальность и легкую расширяемость. То есть ширпотреб по малой цене. Ну а если появляются какие-то уникальные бизнес-требования, то и дизайн уже может быть создан уникальный, и прописан вручную. Естественно, это увеличит стоимость работы, но ведь уникальный, оптимизированный под нужды заказчика продукт и должен быть дороже, не так ли?

17 Александр Купреев 05-08-2009 12:03

Кстати, о популярности ЕЕ можно говорить, наверное, только среди тех, кто ею пользуется. Говорю это не с целью как-то унизить систему, просто больше разработчиков, наверное, предпочитают полностью открытые или изначально более популярные ЦМС. См., например, показательные графики http://www.indeed.com/jobtrends?q=drupal%2C+joomla%2C+wordpress%2C+expression+engine%2C+typo&l=

18 Sezarin 05-08-2009 13:11

Кстати, о популярности ЕЕ можно говорить, наверное, только среди тех, кто ею пользуется...

Ну естественно, тем более, что большинство пользователей EE используют (благодаря старым наработкам) и другие системы.

У меня, например, расклад примерно такой:

- Joomla 4-5% (сайт-визитка+бизнес);

- Wordpress 10-15% (сайт-визитка, новостной, блог);

- Drupal (отказался от использования с выходом joomla1.6 и появлением массы коммерческих расширений к ней);

- ExpressionEngine 40-50%, но благодаря своей невероятной гибкости привлекае все больше и больше. Тут легко решается практически все, и дешевый ширпотреб и бизнес-требования, как Вы говорили выше, и все примерно с одними и теми же затратами smile Во многих случаях использование EE сдерживает наличие ранее наработанных решений под другие системы...

- Остальное - ручная работа. В поисках чего-то более совершенного протестировал фреймворки, но все чаще заглядываюсь на VIVVO CMS.

Тоже фреймворк, правда платный, но, чего стоят одни только возможности html-верстки со встроенной логикой, например:


19 Александр Купреев 05-08-2009 13:28

Спасибо, гляну VIVVO CMS, раньше о такой не слыхал :( Отпишу свое мнение об удобстве/неудобстве.

Надеюсь, ЕЕ 2 тоже скоро появится

20 wordwild 10-08-2009 00:12

Рекомендую еще посмотреть в Sapid (sapid.sf.net) реализацию View.

21 Александр Купреев 10-08-2009 13:26

Я раньше интересовался SAPID, действительно, там неплохая реализация отображений. Сам проект, к сожалению, уже давно не развивается.

22 Sezarin 24-08-2009 00:14

Надеюсь, ЕЕ 2 тоже скоро появится

Я уже писал ранее, что EE2 пытаются построить на старой рухляди под названием "Codeigniter", поэтому, думаю, Вы, Александр, скорее заставите работать "Kohana" по шаблонно-компонентной схеме, чем мы с Вами увидим первый релиз EE2!..

23 Александр Купреев 24-08-2009 12:00

так уже вроде бы дали тестерам первый превью беты

http://expressionengine.com/blog/entry/uva_uvam_vivendo_varia_fit/

24 Sezarin 15-09-2009 12:19

Ранее я писал:

...Кроме того, считаю, что разработка CMS на базе фреймворка VMC-структуры, не блоговой, не новостной, а более-менее универсальной, ну хотя бы как EE, например, - идея, можно сказать утопичная...

Так вот, оказывается - не все так плохо, потому что недавно появилась новая оболочка под названием DooPHP (doophp.com)!

Во фреймворке есть практически все базовые функции, ставшие уже традиционными для малых систем: от ACL до CRUD с довольно мощной ORM, а самое главное - собственный Template Engine, использование которого (параллельно - есть, кстати, и альтернатива на php with html) позволит разрабатывать как простые так и продвинутые CMS для

массового использования {не под себя smile}.

Кое-кто из PHP-велосипедистов в своих публикациях высказывал мнение, что производить вызов данных из шаблона считается плохим тоном и признаком безграмотности. Разработчик данного фреймворка пошел именно по этому пути, и я думаю - не зря. Стоит лишь взглянуть на фрагмент html-шаблона, чтобы прочувствовать ту мощь, которая заложена в механизм ядра шаблонизатора.

К ч-рту искуственные HMVC - вызываем объекты прямо из html-шабблона:

# A simple object
Doo::loadModel('SomeModel');
$obj = new SomeModel;
$obj->fullname = 'My Cool Name';
$obj->SomeObject->weight = 88
$data['obj'] = $obj;
{{obj.@fullname}}
{{upper(obj.@fullname)}}
{{obj.@SomeObject.@weight}}
# Looping an array of Object
    
        Name:   {{users' value.@fullname}}
        Gender: {{users' value.@gender}}
        Weight: {{users' v.@Physical.@weight}}
        Height: {{l' v.@Physical.@height}}

25 Александр Купреев 15-09-2009 13:55

Sezarin вы разрываете мне душу smile Я просто не смогу проигнорировать этот фреймворк, придется обзирать еще и его

26 аноним 22-11-2009 02:23

Sezarin, ну че там, как Вам дуу?

27 Аноним 23-11-2009 14:20

Sezarin, да, как вам дуу по сравнению с другими фреймами?

28 Sezarin 27-11-2009 01:00

как вам дуу по сравнению с другими фреймами?

Сыроват еще, хотя перспективы, думаю, есть.

Очень хорошо построен ORM - простой, быстрый, легкий в использовании.

Но, главное, что меня убивает в системах подобного рода - ручная загрузка классов.

Как говорит Joshua Davey - разработчик PHP-фреймворка Madeam, кто хоть раз попробует работать с автозагрузкой классов, подобной ZF - никогда не сможет отказаться от этого...

Так вот ZF - дело прошлое, с которым не часто, да и не сказать, что-бы с охотой приходится иногда работать, а вот малоизвестный Madeam задел меня пару месяцев тому назад серьезно.

Сам по себе фреймворк небольшой, легкий и очень быстрый, но при этом - легко расширяем сторонними библиотеками.

Сначала попробовал вклеить туда библиотеку Flourish - неудачно. Затем подумал - а почему-бы не адаптировать классы Kohana3? Пришлось потратить пару дней на это, зато какая прелесть...

Жаль в то время вышла последняя бета EE2, и мне всерьез пришлось заняться ее анатомией...

Как-никак, EE - мой основной инструмент smile

29 Сергей 05-10-2010 16:38

Писать или не писать свою CMS - вопрос многогранный. Когда-то просто необходимо ее написать, а иногда можно использовать уже готовое. Свой взгляд я изложил в статье, если кому интересно http://blog.samarko.ru/2010/02/use-standard-free-cms-or-make-your-own.html

30 Антон 10-08-2012 12:25

Наткнулся на CMS на кохана

http://gleezcms.org/

Что скажете? Стоит ли взять ее и дописывать для себя функционал?

31 Александр Купреев 11-08-2012 02:08

Когда я смотрел ее сразу после анонса на форуме Коханы, показалась еще сыроватой для коробочного использования. На изучение внутренностей времени не было, увы.

Оставьте комментарий!


Используйте нормальные имена.

     

  

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

MaxSiteAuth. Войти через loginza

(обязательно)