Что должна уметь правильная CMS?
сентября 23, 2011 | Published in CMS, Новости | 9 Comments
Я уже писал о том, что работаю над QuasarCMS — CMS’кой на Rails. После нескольких недель разработки зашел в тупик. То, что я сделал нельзя назвать CMS, это скорее приложение на Rails реализующее функционал блога + несколько различных плюшек, которым я хочу заменить нынешний движек RubyDev — WordPress.
Вы уже заметили, что я начал псать о RSpec и обещал написать большую статью по Git. Все это длятого, чтобы новички могли присоединиться к проекту и поучаствовать в нем набираясь опыта. Хочется побыстрее довести работу до некоторой кондиции, когда можно уже пригласить людей для совместной разработки. Скоро, все желающие смогут поучаствовать в разработке CMS. Причинами того, что все так затянуто является мой поиск работы, учеба, иногда, просто лень, и то, что я стаю на распутьи выбора того, какой должна быть CMS. Поэтому хочу задать читателям несколько вопросов:
1. Что должна уметь CMS при работе из коробки?
2. Как лучше сделать расширения: в виде gem’ов или в виде какого-то собственного формата.
3. Что лучше использовать для конфигураций? Сейчас конфиги реализованы на основе yaml, в будущем планирую использовать json (говорят с ним будет значительно быстрее, чем с yaml), но опять не знаю правильный ли это выбор. В директории с конфигами хранится файл base.yml в котором хранятся настройки примерно в таком формате:
property:
description:
ru: бла-бла-бла
en: blah-blah-blah
value:
default: true
type: string
и так для каждого свойства. type используется для построения формы (string — text input, text — textarea, file — file input, list — select и т.д.). Для каждого расширения предполагается использование такого файла, например my_ext.yml. Каждое расширение состоит из набора файлов + генератора, который из расбрасывает в нужные директории. Все это мне кажется сильно громоздким (следует упомянуть, что у меня фобия низкой производительности). В общем жду совета как все это организовать. Основное требование чтобы настройки грузились только один раз, а не при каждом запросе.
4. Представление страницы. Сдесь я вообще извратился, код еще не написал, но перепортил тону бумаги на проектирование того как и что должно работать. Остановился на концепции потоков. Что это? — Эту тему я сам придумал, но возможно она уже где-то или везде=) применяется, но под другим названием. Суть заключается вот в чем:
Весь контент помещается в общий поток main.
Поток main может делиться на множество других потоков:
main |-head |-content | |-article | |-rightbar |-column1 |-column2
Таким образом любой поток — это ветвящаяся структура — хэш в которой кроме hash key имеется целочисленный ключ обозначающий порядок. Рассмотрим например ветку rightbar, она состоит из веток column1 и column2, это означает, что будет использоваться 3-х колоночная тема. В column1 могут содержаться, например: категории(1), последние статьи(2), форма входа(3). В column2, например: рекламный блок(1), теги(2). Настройка потока происходит, разумеется в настройках темы. То есть нельзя будет с одной темы перейти на другую без необходимости заново распределять блоки контента, или как стало модным называть их — виджеты. Здесь опять воспрос: стоит ли использовать такую схему или нет. Предлагайте свои варианты.
5. Пользователи, какими они должны быть? Использовать роли (admin, moderator, user, guest) или что-то еще?
6. Вам хочется чтобы CMS работала без необходимости лезть в код при этом была очень страшной и огромной с сотнями настроек или такой, чтобы можно было легко открыть код и что не устраивает — подправить в ручную. Как тогда реализовать обновление?
7. Вообще интересуют любые пожелания.
сентября 23, 2011 at 11:43 (#)
Если бы я хотел, чтобы моя CMS была хоть немного популярна, я бы делал её максимально простой для обычного пользователя.
Система должна устанавливаться в пару кликов, полностью настраиваться из панели управления(без правки файлов-конфигов), плагины должны скачиваться и устанавливаться сами из репозитория. Система шаблонов должна быть простой(чтобы незнакомый с программированием верстальщик смог натянуть верстку на движок), но, в то же время, достаточно гибкой, чтобы можно было делать не стандартные по структуре сайты(имиджевые визитки).
Главной проблемой распространения любой CMS на RoR я считаю сложность деплоя на хостинг. Нормальных хостингов с RoR и RVM я не видел, а те что есть очень дороги. А для настройки виртуального сервера рядовому пользователю не хватит знаний.
сентября 23, 2011 at 14:02 (#)
1. Я думаю для начала CMS сделать простой для наполнения базы данными… а потом голосованием добавлять фичи.
2-й и 3-й вопросы точно не к новичку :) но yaml по-моему красивее, хотя и во втором разобраться просто.
сентября 23, 2011 at 15:03 (#)
JonNIBravo, для CMS на Rails хостинги — совсем не то если сайт имеет посещаемость от 1000 пользователей. Мне кажется, что такие CMS — удел крупных сайтов, которые хостятся не на хостингах за $4, а на VDS, хотя бы за $15 c 256 оперативы и т.д.
dinamon, JSON достаточно читабельный формат, хотя и устпает в этом YAML’у. Зато JSON можно хорошо сжать, а вот с YAML этого не выйдет. Кроме того, сам конвертер YAML в Ruby хэш более медленный, чем для JSON. Тут однозначно выигрыш в производительности. Нужно просто подумать, о других способах хранения конфигов, например о хранении их в БД, однако, на сколько я понимаю. их тогда нужно будет загружать при каждом запросе, что не есть хорошо. В любом случае о том, чтобы использовать CMS в продакшене после первого релиза речи не идет, нужно будет однозначно много чего задачивать, от многого отказываться.
сентября 23, 2011 at 15:27 (#)
ну так json по версии википедии является подмножеством yaml-a,
и по возможностям yaml более мощный, ну это так моё мнение, по поводу git-a, если кто-то уже более-имение освоился, хоть посмотреть что, да как?
сентября 24, 2011 at 12:12 (#)
По поводу 6го пункта. Я считаю, что CMS на рельсах просто не суждено стать популярной и народной в ближайшем будущем. По разным причинам это и сложность деплоя, но в основном из-за популярности php, к которой руби еще очень не скоро приблизится если вообще когда-нибудь приблизится. У руби своя ниша и с php он не сильно и соперничает.
Поэтому имхо cms на рельсах нужно делать ориентируясь на программистов или хотя бы на людей которые могут сами что-то делать, а не просто тыкать мышкой на кнопки. Имхо не стоит делать такую же простую в обращении cms как вордпресс или джумла т.к. времени и сил потратишь на это очень много а толка мало будет. Простые люди все равно врятли обратят на нее внимание.
А вот сделать удобную cms для более продвинутых людей идея хорошая.
сентября 24, 2011 at 14:41 (#)
Tankard, это да, затачивать под Васю «SuperWebMaster», который в локалке хочет сайт о любимом коте сделать никто не собирается. Первым делом хочу чтобы CMS была удобна для разработчиков. Разработчик берет CMS, настраивает как хочет, дописывает, переписывает, создает расширения и т.д. А патом конечный пользователь вогнан в рамки того, что сделал разработчик. Если что-то нужно — он снова платит разработчику деньги или сам на свой страх и риск лезет в код. Т.е. управление сайтом заточена под пользователя, а разработка под разработчика, но здесь есть проблема в том, что эти области пересекаются и нужно найти какой-то разумный баланс.
октября 4, 2011 at 04:05 (#)
Наследование блоков, например на главной странице есть блоки: меню, баннеры, форма авторизации, последни 10 новостей и вывод контент. Тогда внутренняя страница наследуе главную, заменяет своим layout’ом и подменяет например блоки баннеров и последние 10 новостей удаляя их.
Побольше модулей с возможностью легкой установки, без разницы будут ли это gems, engines или просто заливаемые через админку файлы.
Такую систему я писал и работаю с ней, правда на PHP. Может в будущем перенесу на Rails
Вот описывал: и тут продолжение
декабря 14, 2011 at 09:24 (#)
— самый классный движок на php вот такой бы для rails и цены cms не будет… И рельсы мне нравятся больше php, так что перспектив много…
декабря 14, 2011 at 19:24 (#)
Да, давай делать свой двигатель как было с php fusion, собрался народ и сделали все как надо