Долго думал о том, стоит пробовать писать на Хабр или не стоит. До этого наблюдал негативный опыт взаимодействия знакомого разработчика CMS с аудиторией Хабрахабра. Видимо, тематика избита и не очень интересна. Но я всё же попробую.
Написать собственную CMS меня подтолкнули 10 лет работы над сайтами. Работать приходилось в местечковой Joomla-подобной системе, т.е. всё приходилось делать руками, для малейшего изменения структуры надо было лезть в СУБД и обновлять шаблоны вывода через FTP. Думаю, с подобным сталкиваются многие разработчики и по сей день.
Вот несколько мыслей, которые подвели меня к разработке своего велосипеда:
— Простые операции над сайтами требуют довольно сложной и трудоёмкой работы;
— Разработчик крайне редко имеет возможность использовать повторно свои наработки;
— Клиент имеет весьма скудные возможности по управлению контентом;
— Модернизацией функционала может заниматься только профессионал, даже если это тривиальная задача.
Каждый раз сталкиваясь с рутиной в голове крутились вопросы:
«Почему эти процессы нельзя оптимизировать? Почему нельзя представить все возможные данные и их обработчики как единую структуру?»
К тому времени я успел немного ознакомиться с Drupal, ProcessWire, SiteBuilder и Bitrix. Где-то хорошо реализован конструктор данных, где-то хорошо организована работа с шаблонами, но всё в итоге скатывалось к написанию обработчиков данных с использованием довольно нетривиального API. В итоге, опыт работы с этими CMS подтвердил мои мысли, которые можно выразить в одну — избыточная сложность разработки.
Как к этому относятся разработчики? Для кого-то это рутина, для кого-то это хлеб. Многих разработчиков нанимают не потому, что работа сложная, а потому, что клиенту просто невозможно её самостоятельно выполнить. Невозможность выполнения тривиальных задач обуславливается не тем, что клиент попросту не готов к этой работе, а банальным отсутствием инструментов.
Что из себя представляет модуль в обычной CMS? Как правило это папка с файлами, которые содержат набор сценариев для работы с данными. Кроме этого, модуль содержит описание структур данных, с которыми ему предстоит работать. В момент установки модуля эти структуры создаются в БД.
В моём решении модуль полностью виртуализирован и хранится как объект в базе данных (я слышал, что за это на Хабре съедают заживо). Кроме того, он может быть связан с другими модулями системы. Скажем, «статьи» могут использовать «фото-галереи» и «отзывы» под свои нужды.
Первое, что даёт нам такой подход это экземплярность модулей. Мы можем создать новый экземпляр модуля не создавая дополнительных таблиц в БД. Одни и те же структуры данных, одни и те же обработчики, но данные другие. Пример эксплуатации: на одном сайте можно разместить несколько лент статей, несколько каталогов товаров.
Дальше больше — вложенная экземплярность. Как я уже писал выше, мы можем связать данные из разных модулей, например, добавить в статьи фото-галерею и отзывы. Таким образом, каждая статья будет своего рода экземпляром для модуля фото-галереи и отзывов. Вложенность модулей не ограничена, можно обеспечить рекурсивность (например, если вложить в фото-галереи статьи).
Ещё одним плюсом можно назвать возможность переносить данные между экземплярами.
Каждый модуль позволяет разместить в себе множество таблиц данных.
Таблица содержит в себе строки, которые являются основными объектами данных (страницы, статьи, фотографии).
Таблица определяет набор полей, которые могут содержать её строки (заголовок, текст, url). Поля могут хранить информацию непосредственно в себе, либо ссылаться на строки из других таблиц.
Таблицы можно вкладывать друг в друга, а также делать их иерархичными (с неограниченной вложенностью элементов). Например, вы можете создать таблицу «Категории» и расположить в ней таблицу «Товары».
Как я уже писал выше, основная головная боль возникает не при разработке структуры данных, а при её выводе, т.е. при написании обработчиков/шаблонов.
Хотелось чего-то простого. Если разработчик создал таблицу «Страницы» с полями «url», «Заголовок» и «Текст», то в обработчике вывода страницы хотелось бы писать просто что-то вроде:
В системе обработчики могут быть связаны с таблицами и участвовать в автоматическом URL разборе. Скажем, у таблицы «Страницы» есть поле «url», которое отвечает за url-разбор. Связанный обработчик будет использовать это поле для поиска подходящей страницы для отображения. При этом, он работает с учётом иерархичности таблицы и её возможной вложенности в другие модули.
По сути, разработчику не надо греть голову над URL-разбором. Достаточно просто определить ключевое поле в таблице и связать с ней нужный обработчик. В системе имеется большое количество настроек для кастомизации url-разбора.
При редактировании обработчика, система знает с какой таблицей он связан (например, он должен отображать статью) и сразу выдаёт все имеющиеся поля. Достаточно просто расставить поля по шаблону отображения.
Можно ещё много тем поднять (мультисайтовость, зональность, права доступа, язык шаблонизатора), и мне было бы интересно поговорить обо всём этом, поведать возможности системы, но я не хочу уводить читателя от темы.
Мои попытки найти решение для упрощения разработки веб-проектов, обернулись созданием собственной CMS.
Она позволяет пользователям без опыта в разработке самостоятельно дорабатывать структуры данных и их отображение, а также создавать модули «с нуля». Т.е. пользователь сам может выполнить тривиальную задачу без помощи специалиста. Для сложных задач существует API из более чем 1000 команд, которые встроены в специальный редактор и позволяют поэтапно осуществлять их внедрение (например, пользователь выбрал вывод поле «текст», система предлагает ему набор возможных операций для текста и т.д.).
Огромную порцию мотивации я получаю после общения с клиентами, которые удивлённо говорят: «и так можно? и вот это сюда можно перенести? так просто? уже готово?», но самое главное это то, что CMS помогает мне быстрее справляться с рутиной и решать сложные задачи не прибегая к написанию лишнего кода.
Надеюсь, после выпуска система поможет многим разработчикам избавиться от рутины, а владельцам компаний экономить средства на доработку сайтов и веб-приложений.
Если вас заинтересовал проект, можете ознакомиться с обзорными видеороликами.
Суть проблемы
Написать собственную CMS меня подтолкнули 10 лет работы над сайтами. Работать приходилось в местечковой Joomla-подобной системе, т.е. всё приходилось делать руками, для малейшего изменения структуры надо было лезть в СУБД и обновлять шаблоны вывода через FTP. Думаю, с подобным сталкиваются многие разработчики и по сей день.
Вот несколько мыслей, которые подвели меня к разработке своего велосипеда:
— Простые операции над сайтами требуют довольно сложной и трудоёмкой работы;
— Разработчик крайне редко имеет возможность использовать повторно свои наработки;
— Клиент имеет весьма скудные возможности по управлению контентом;
— Модернизацией функционала может заниматься только профессионал, даже если это тривиальная задача.
Каждый раз сталкиваясь с рутиной в голове крутились вопросы:
«Почему эти процессы нельзя оптимизировать? Почему нельзя представить все возможные данные и их обработчики как единую структуру?»
К тому времени я успел немного ознакомиться с Drupal, ProcessWire, SiteBuilder и Bitrix. Где-то хорошо реализован конструктор данных, где-то хорошо организована работа с шаблонами, но всё в итоге скатывалось к написанию обработчиков данных с использованием довольно нетривиального API. В итоге, опыт работы с этими CMS подтвердил мои мысли, которые можно выразить в одну — избыточная сложность разработки.
Как к этому относятся разработчики? Для кого-то это рутина, для кого-то это хлеб. Многих разработчиков нанимают не потому, что работа сложная, а потому, что клиенту просто невозможно её самостоятельно выполнить. Невозможность выполнения тривиальных задач обуславливается не тем, что клиент попросту не готов к этой работе, а банальным отсутствием инструментов.
Что из себя представляет модуль в обычной CMS? Как правило это папка с файлами, которые содержат набор сценариев для работы с данными. Кроме этого, модуль содержит описание структур данных, с которыми ему предстоит работать. В момент установки модуля эти структуры создаются в БД.
Моё решение
1. Виртуализация модуля
В моём решении модуль полностью виртуализирован и хранится как объект в базе данных (я слышал, что за это на Хабре съедают заживо). Кроме того, он может быть связан с другими модулями системы. Скажем, «статьи» могут использовать «фото-галереи» и «отзывы» под свои нужды.
Первое, что даёт нам такой подход это экземплярность модулей. Мы можем создать новый экземпляр модуля не создавая дополнительных таблиц в БД. Одни и те же структуры данных, одни и те же обработчики, но данные другие. Пример эксплуатации: на одном сайте можно разместить несколько лент статей, несколько каталогов товаров.
Дальше больше — вложенная экземплярность. Как я уже писал выше, мы можем связать данные из разных модулей, например, добавить в статьи фото-галерею и отзывы. Таким образом, каждая статья будет своего рода экземпляром для модуля фото-галереи и отзывов. Вложенность модулей не ограничена, можно обеспечить рекурсивность (например, если вложить в фото-галереи статьи).
Ещё одним плюсом можно назвать возможность переносить данные между экземплярами.
2. Хранение данных
Каждый модуль позволяет разместить в себе множество таблиц данных.
Таблица содержит в себе строки, которые являются основными объектами данных (страницы, статьи, фотографии).
Таблица определяет набор полей, которые могут содержать её строки (заголовок, текст, url). Поля могут хранить информацию непосредственно в себе, либо ссылаться на строки из других таблиц.
Таблицы можно вкладывать друг в друга, а также делать их иерархичными (с неограниченной вложенностью элементов). Например, вы можете создать таблицу «Категории» и расположить в ней таблицу «Товары».
3. Обработчики данных, шаблоны
Как я уже писал выше, основная головная боль возникает не при разработке структуры данных, а при её выводе, т.е. при написании обработчиков/шаблонов.
Хотелось чего-то простого. Если разработчик создал таблицу «Страницы» с полями «url», «Заголовок» и «Текст», то в обработчике вывода страницы хотелось бы писать просто что-то вроде:
[Заголовок]
[Текст] В системе обработчики могут быть связаны с таблицами и участвовать в автоматическом URL разборе. Скажем, у таблицы «Страницы» есть поле «url», которое отвечает за url-разбор. Связанный обработчик будет использовать это поле для поиска подходящей страницы для отображения. При этом, он работает с учётом иерархичности таблицы и её возможной вложенности в другие модули.
По сути, разработчику не надо греть голову над URL-разбором. Достаточно просто определить ключевое поле в таблице и связать с ней нужный обработчик. В системе имеется большое количество настроек для кастомизации url-разбора.
При редактировании обработчика, система знает с какой таблицей он связан (например, он должен отображать статью) и сразу выдаёт все имеющиеся поля. Достаточно просто расставить поля по шаблону отображения.
Итоги
Можно ещё много тем поднять (мультисайтовость, зональность, права доступа, язык шаблонизатора), и мне было бы интересно поговорить обо всём этом, поведать возможности системы, но я не хочу уводить читателя от темы.
Мои попытки найти решение для упрощения разработки веб-проектов, обернулись созданием собственной CMS.
Она позволяет пользователям без опыта в разработке самостоятельно дорабатывать структуры данных и их отображение, а также создавать модули «с нуля». Т.е. пользователь сам может выполнить тривиальную задачу без помощи специалиста. Для сложных задач существует API из более чем 1000 команд, которые встроены в специальный редактор и позволяют поэтапно осуществлять их внедрение (например, пользователь выбрал вывод поле «текст», система предлагает ему набор возможных операций для текста и т.д.).
Огромную порцию мотивации я получаю после общения с клиентами, которые удивлённо говорят: «и так можно? и вот это сюда можно перенести? так просто? уже готово?», но самое главное это то, что CMS помогает мне быстрее справляться с рутиной и решать сложные задачи не прибегая к написанию лишнего кода.
Надеюсь, после выпуска система поможет многим разработчикам избавиться от рутины, а владельцам компаний экономить средства на доработку сайтов и веб-приложений.
Если вас заинтересовал проект, можете ознакомиться с обзорными видеороликами.