Я разрабатываю свою CMS, хочу узнать мнение специалистов.
Для себя я вывел следующие критерии:
Для разработчиков:
1. Компонентная архитектура. Возможность просто подключить компонент в любом месте. Разделение логики и представления.
2. Гибкая настройка свойств какого либо элемента, либо раздела.
3. Модульное ядро, возможно вносить изменения в ядро, не затрагивая самого кода ядра.
4. Максимально возможное уменьшение связанности модулей системы.
Для администраторов:
1. "Режим правки" Возможность редактирования какого либо материала, не заходя в административную часть. Inline редактирование.
2. Максимально простая админка, такая что бы человек, который вообще не разбирается в программировании, мог легко понять как сделать нужную настройку.
Я хочу создать лучшее решение из всех возможных. Пишите что вам нравится в современных CMS, что не нравится.
4. Максимально возможное уменьшение связанности модулей системы.
Далеко не факт. Это не фреймворк, соответственно лучше оно работает проще и быстрее, чем будет иметь кучу абстракций как в фреймворке "как правильно академически".
Для администраторов:
1. "Режим правки" Возможность редактирования какого либо материала, не заходя в административную часть. Inline редактирование.
2. Максимально простая админка, такая что бы человек, который вообще не разбирается в программировании, мог легко понять как сделать нужную настройку.
Если администратор чайник - то да, а нормальному администратору HTML не страшен. Всё зависит от предполагаемой аудитории.
"Далеко не факт. Это не фреймворк, соответственно лучше оно работает проще и быстрее, чем будет иметь кучу абстракций как в фреймворке "как правильно академически"."
А если, допустим сделать урезанную версию фреймворка? Берем только то что нужно, например реализуем компоненты (веб формы, слайдеры и пр.) на основе паттерна HMVC. Весь API реализуем через один класс, модули (расширение функционала админки) будут работать раздельно и будут использовать общий класс для работы с системой.
Работать будет дольше, но расширять функционал системы будет проще, а проблему скорости можно решить за счет кеширования.
В угоду просте думаю можно пожертвовать скоростью.
"Если администратор чайник - то да, а нормальному администратору HTML не страшен. Всё зависит от предполагаемой аудитории."
Согласен. Аудитория будет разная, поэтому думаю может сделать 2 режима в админке, для "продвинутых" и для "чайников" ?
@FOGstudio Смотря что брать за основу. Если изначально вы взяли фреймворк - то будете следовать ему. Если у вас разработка начинается с нуля - тут сам себе решаешь что брать.
У меня тоже своя разработка - как пример могу привести одну не очень красивую ситуацию. Есть класс работы с пользователем, который по сути нужен всегда: для определения прав доступа, личных настроек и прочего. Есть класс для работы с разрешениями - создание, редактирование и прочее. Есть метод в классе пользователя, который проверяет что можно, а что нельзя пользователю. Красиво было бы, если бы этот метод работал с Классом, который отвечает за разрешения, но он сперва пытается залезть в кэш, и найти там нужные данные. Если они есть - берет оттуда.
Эта ситуация в коде, ясное дело, отдельно прокомментирована. Хотя это реально криво, зато на 99,99% страниц нет необходимости подключать класс работы с разрешениями, иначе он бы подключался всегда, вот такой компромисс.
В вашем случае аналогично - если CMS, то вероятность, что кто-то захочет полностью заменить подсистему работы с пользователями на свою, оставив всё остальное как есть мизерная. Поэтому, имхо, не стоит городить лишние абстракции, если заранее известно что и с чем будет работать.
Можно было бы не делать какую-нибудь "супер-универсальную" штуку, а сделать различные узко-специализированные версии движка. Например, для сайта визитки своя урезанная версия движка, для инет магазина своя версия, для портала своя и т.д.
Я планирую сделать так: из коробки будет возможно сделать сайт на уровне простого сайта каталога, далее все расширяется модулями. А для тех кому "лень" собирать всё из модулей - создать типовые сборки: для интернет магазина, портала и прочие.
Сложный
