Компания
13,21
рейтинг
5 февраля 2014 в 12:00

Разработка → Boolive — гибкая cms для смелых проектов

В этой статье мы расскажем о невероятно гибкой системе управления сайтом – Boolive, сочетающей в себе мощь и простоту.

Система для создания и управления сайтами Boolive объединяет лучшие качества модульности, универсальности и гибкости. Программистов избавит от рутинных операций, сосредоточит на полезном программировании. Средствами раздела администрирования позволит создать любую структуру данных, настроить правила работы, создать сайт в точном соответствии с требованиями. Чтобы вы не делали, всё доступно для повторного использования. Для менеджеров, администраторов, редакторов, программистов сайта – для всех система старается быть простой с интуитивно понятным красивым интерфейсом.

Фундамент гибкости – две иерархии


Идея проекта Boolive обретала чёткие очертания на протяжении нескольких лет в экспериментах, из практических применений и в увлекательных дискуссиях с разносторонними личностями.

Главное желание – свобода создания любых структур данных и логики с любым назначением. Система не должна накладывать искусственные ограничения, не связанные с безопасностью или целостностью, а позволять создавать просто, гибко, не ограничивая в творчестве.

За основу взята иерархия. Весь сайт представляет собой одну большую иерархию объектов. Насколько она большая зависит от уровня детализации предметной области и целесообразности детализации. Чем больше детализация, тем больше гибкости. В иерархии все сведения о сайте, все его объекты – содержимое, интерфейс, пользователи. Ко всему единый подход.



Объект – это совокупность данных и логики. У каждого объекта есть своё имя, значение и логика. Сами по себе объекты примитивны. Но у них могут быть подчиненные объекты, которыми образуется иерархия. Подчинённые объекты используются как свойства родительского объекта или просто для образования вложенной структуры.



Так как объекты выстраиваются в иерархию, у них появляется адрес – URI. Фактически как путь к файлу. Адрес используется для обращения к объекту, в том числе и в строке браузера. Адрес – основной идентификатор объекта.

Свобода и легкость создания новых объектов приведет к дублированию уже ранее созданных объектов. Утомительно повторять однотипные операции создания сложных объектов – состоящих из нескольких подчиненных. Вручную нужно соблюдать единство структуры, именования, логики однотипных объектов. Для разрешения этой утомительной сложности применяется прототипирование. Это самая главная особенность системы. Новые объекты создаются на основе существующих. Иными словами один объект наследует значение, логику и структуру другого объекта. При этом может переопределять себе значение, логику и иметь новых подчиненных или удалять унаследованных. Прототипирование оптимизирует создание сложных объектов, даёт возможность повторного использования. Кроме того, любой объект можно доработать под свои задачи без порчи существующих объектов, ориентированных на иные задачи, сохраняя обратную связь для обновлений. Объекты сохраняют связь со своим прототипом.



Каждый объект одновременно находится в двух иерархиях – в иерархии структуры и в иерархии наследования. Всего две иерархии образуют удивительную гибкость для создания сложных структур данных. Если нужно связать один объект с другим, например, статью связать с пользователем, то используется прототипирование. В подчинение добавляется новый объект, прототипом для него будет тот объект, с которым нужна связь.



Возможность создания новых объектов на основе существующих подсказывает о существовании библиотеки объектов. Это ветвь иерархии сайта, в которой хранятся объекты для повторного применения. Повторно применить можно любой объект, где бы он не находился, но библиотека – это коллекция разнообразных заготовок и полностью готовых объектов для создания из них сайта. Можно формировать свою библиотеку или пакет с объектами под конкретный проект. Свои эталоны публикаций, товара, пользователя, виджеты, готовые сайты и всё, что угодно.

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

Гибкость в деле


Необычная админка

Знакомство начнём с раздела администрирования (админки). Основная задача админки – предоставить доступ к любому объекту сайта с учётом прав пользователя и выполнить необходимые операции с объектом – создать, изменить, удалить. Смысл в админке в удобном графическом интерфейсе, в оптимизации работы над сайтом. Для неопытных пользователей нужно показать привычные элементы интерфейса. Для продвинутых раскрыть всю гибкость системы.



Работа в админке начинается с перехода к нужному объекту, например, к странице для последующего её редактирования. В центральной области отображается текущий объект с его подчиненным, можно зайти внутрь них. Сверху имеется меню пути (адреса) текущего объекта для быстрых возвратов назад. В левой части отображаются закладки для быстрых переходов к часто используемым объектам. Закладку можно добавить в любой момент на любой объект.

Так как сведений об объекте достаточно много, чтобы поместить их на один экран, в нижнем меню выбирается, что именно об объекте нас интересует. Чаще всего – это структура объекта или его свойства. Для продвинутых пользователей полезны будут логика, значение объекта, а также просмотр прототипов и наследников объекта. При обращении к объекту по умолчанию отображается структура.

Третий вид навигации – функции, выполняемые над объектами. Меню функций расположено в правой части админки. Основные функции – просмотр объекта, добавление новых, удаление и смена признаков. Доступные функции зависят от выделенного объекта, от выбранных сведений и некоторых других состояний в админке, например, сколько объектов одновременно выделено в списке, в том числе и от прав доступа. Набор функций легко расширяется. Можно добавлять свои обозреватели, редакторы объектов, назначая их на определённые типы объектов или другие условия работы. С их помощью админка наделяется более специфичными функциями, затачивается под удобства конкретного проекта. Можно провести аналогию: раздел администрирования как операционная система, объекты сайта как файлы, а функции как программы.

Выходит, если нам нужно отредактировать существующую страницу, мы переходим в содержимое, находим там страницу, переходим в неё и редактируем её. Должно быть просто!

Содержимое – предметная область проекта

К содержимому относится всё, что предполагается публиковать на сайте. Например: статьи, новости, разделы, товар, фотографии или специфичный для проекта тип содержимого. Обычно, мы имеем дело со страницами и разделами. В иерархии сайта есть специальный раздел «Содержимое» для хранения публикаций. Но это не значит, что только в нём можно хранить страницы сайта. Раздел заранее сделан только для удобства и оптимизации, чтобы не выполнять поиск по всей иерархии.

Чтобы добавить новую страницу, нужно для начала перейти в раздел «Содержимое». Можно перейти в страницу или подраздел, если новую страницу нужно добавить внутри них. После перехода в правом меню выбираем функцию «Добавить». В списке быстрого выбора уже предлагается страница. Но мы можем выбрать любой другой объект сайта. После добавления страница оказывается с признаком «Черновик». Рекомендуется сначала отредактировать страницу – полностью подготовить её для публикации, только потом убрать признак черновик.



Теперь пощупаем гибкость. К странице добавим ещё одно свойство текста. Находясь в редакторе страницы, для примера добавляем «Из библиотеки» из пакета «Простые» объект «HTML Текст». При нажатии на «Добавить» появится окно выбор объекта. Для выбора доступны все объекты сайта, но нам нужен текст, который есть в библиотеке.



Новый текст появится в редакторе и отобразится на странице сайта в соответствии со своим порядком.



В данном примере дополнительное свойство «текст» добавлено только одной странице. Если нужно всем страницам сайта иметь дополнительное свойство, то проще изменить прототип или создать свой и использовать его.

Под проект лучше создавать пакет в библиотеке, и коллекционировать в нём прототипы со спецификой проекта. Например, для сайта салона автомобилей создать объект «автомобиль», сразу определив все необходимые свойства автомобиля, а перед этим создать прототипы «Тип кузова», «Производитель» и многие другие, чтобы использовать их в самом автомобиле. Таким способом создаются прототипы под предметную область проекта. В раздел «Содержимое» уже добавляются непосредственно автомобили салона, списки производителей и так далее. Заметьте, что к «автомобилю» мы можем добавлять не только простые свойства – «текст», «число», но и сложные – любые объекты сайта и образовывать сложные структуры! Свойства, которые помечены как обязательные, сразу появляются у новых объектов. Если свойство необязательное, то оно доступно в качестве дополнения, т.е. его можно добавить позже при желании.

Виджеты отобразят всё

Для отображения сайта в браузере используются виджеты. Виджет – это объект с функцией отображения, возвращающей HTML код. Виджет может сам по себе что-то отобразить, какую-то статическую информацию, быть элементом оформления, отобразить определенный объект, например, новость, а также отобразить внутри себя подчиненные виджеты.

Из виджетов выстраивается ветвь иерархии в разделе «Интерфейс». Виджетами полностью определяется представление и динамика сайта в браузере. Корневым виджетом выводится базовая структура HTML документа. В область body вставляется результат отображения его подчиненного виджета, им задаётся разметка сайта, например шапка, боковые панели, подвал, центр. В каждую область вставляются подчиненные виджеты, и так далее. Это типовая структура, возможны разные варианты, можно одним виджетом показать весь сайт, но знайте – гибкость в детализации.



У виджетов есть функция условия работы, если она возвращает true, то виджет работает, иначе нет. В функции проверяются входящих данные, настройки или состояние системы. Виджет можно настроить на работу по определенному адресу, например, админка работает, если адрес начинается с /admin. Виджет не будет работать, если он в черновике или нет доступа к нему. Можно запрограммировать любое условие, например, работать только в ночное время, проверять тип отображаемого объекта, сверять параметры запроса. Большинство условий можно задать правилом на входящие данные.

При работе с виджетом в админке полезными будут режимы «Логика» и «Значение» для редактирования соответственно логики виджета и его шаблона. Логика – это файл с php классом, как у всех объектов. Шаблон – это значение виджета в виде файла, от расширения файла зависит тип шаблона. Логика и шаблон также доступны для редактирования в любимой IDE. Система Boolive сама выполняет рутинные операции создания файлов, нужно только в админке указать, что объекту нужна своя логика или свой шаблон. Файл класса с заготовкой самого класса будет создан автоматически. Останется только дополнить функцию новой логикой или переопределить другие функции.



Для создания интерфейса сайта проще использовать готовые виджеты из библиотеки, немного изменяя их шаблон, логику и стили. В библиотеке имеются виджеты навигации, виджеты содержимого, слайдеры, формы и будут появляться новые. Благодаря прототипированию виджет можно добавить в разные области сайта и каждый экземпляр по-своему настроить. Не просто настроить, а изменить логику, шаблон, стили, скрипты. В библиотеке также есть готовые макеты, фактически готовые сайты. Если в большинстве CMS выбираются темы оформления под «стандартный» макет, то в Boolive одним выбором простейший сайт превращается в портал. Взяв за основу готовый макет из библиотеки, вы сможете доработать его, получить свой макет без порчи оригинального.

Там где нужна универсальность необходимо использовать универсальные виджеты. Одним из таких является виджет содержимого в центральной области сайта. У виджета содержимого в подчинении имеются различные виджеты под конкретные объекты – виджет страницы, раздела, товара, пользователя. По очереди запускается каждый виджет, пока один из них не сработает. У всех есть условие работы – проверка, наследует ли отображаемый объект конкретный объект. В итоге, страница отобразится виджетом страницы, раздел виджетом раздела. Можно сделать уникальное отображение для конкретной страницы.

Для отображения свойств объекта тоже применима автоматизация. Примерами являются виджеты страницы, раздела, меню, слайдер и многие другие, особенно в админке. Этими виджетами выбираются свойства объекта и для каждого свойства подбирается виджет из списка.

Благодаря универсальности мы можем в страницу вставить любой объект, даже виджет. Этому есть практическое применение – создание форм обратной связи, авторизации, калькуляторов. Сначала создаём виджет «Калькулятор», а потом вставляем его в текст любой страницы. Ещё интересный пример универсальности – отображение фотографий в слайдере (карусели). Вместо фотографии в список слайдов можно добавить страницу. Самое важное, что это не будет хаком, мы сохраняем удобства редактирования страницы в слайдах.

Обработка любого запроса

Система Boolive имеет единственную точку входа – файл index.php. С него начинается обработка всех запросов – запускается работа сайта. Выбирается корневой объект сайта и вызывается его функция start().Тот в свою очередь запускает объект Интерфейс, мы его видим при входе в админку. Интерфейс по очереди запускает всех своих подчиненных. Как в итоге будет обработан запрос, зависит от структуры Интерфейса.



В Интерфейсе, мы уже знаем, располагается иерархия виджетов (виджет HTML разметка). Большинство запросов именно она обрабатывает, возвращая клиенту HTML документ. Кроме виджетов в интерфейсе есть другие обработчики, каждый из них запускается при соблюдении своих условий работы. Например, обработчик RESTful сработает, если в заголовке запроса указан формат ответа – JSON. Обработчик форм сработает, если указан параметр адреса формы, которая принимает запрос. С легкостью можно добавить свой обработчик, например для интеграции с внешними системами. Интерфейс запускает по очереди всех своих подчиненных, но так как у всех свои условия работы – выполнится только один. Дальше процесс зависит от самих обработчиков.



Гибкая настройка прав пользователей и групп

Гибкость модели данных распространилась и на структурирование пользователей. Можно создавать группы пользователей, группы в группах, в них добавлять пользователей. Система не запретит пользователя добавить внутрь другого пользователя, если это вдруг нужно для уникальных функций сайта. Естественно, у пользователя могут быть любые свойства в его профиле. Администраторам сайта остается определиться, что запретить или разрешить пользователям.

У пользователей и групп есть свойство «Права доступа».



Для структурирования прав используются роли. В «Роль» добавляются объекты «действия», например, «чтение», «запись». Можно добавлять свои действия – это обычный объект, имя которого соответствует названию действия. Действия могут иметь вложенные действия, например, изменение значения объекта, логики объекта, исполнение функций объекта. Запретив запись, нельзя будет ни создавать, не изменять объект. В действия добавляются объекты условий. Их задача возвратить условие, при котором соответствующее действие можно или нельзя выполнять. Сейчас используются два вида условия – «Допуск» и «Запрет», соответственно, допуском определяется, на какие объекты есть право совершать действие, а запретом, на какие нет. Именно в условиях сосредоточена гибкость определения прав, так как условием может быть всё что угодно. Можно просто сверить идентификаторы объектов, входят ли они в список тех, что у объектов, которые в подчинении объекта допуска. Можно проверять наследование, родителей, подчиненных, авторство, просто сверить атрибуты, например, значения объектов. Можно в обще объекты не трогать, а определять допуск по состоянию системы, например по времени. В общем, объект условия возвращает условие на языке запросов к базе данных (о нём ниже)

Проверка в программном коде:

// Проверка доступа на изменение значения объекта
if ($object->isAccessible('write/change/value'){
    echo 'Доступ на изменение значения объекта имеется';
}
// Права пользователя – полное условие, которым можно 
// проверить объект или применить его для поиска объектов
$cond = $user->getAccessCond('write/change');

Права самого пользователя дополняются правами всех групп, в которых он состоит. Объединение прав – это объединение условий логическими операциями «И», «ИЛИ», так, чтобы права вложенной группы или пользователя имели приоритет над родительской группой. Корневой группе можно установить запрет на всё, а вложенным группам или пользователям указывать, что им разрешается. Допустимо наоборот, сначала все разрешить, потом точечно запрещать.

Где объекты? Везде! Хранилища данных

При работе с объектами на уровне программного кода – при сохранении, удалении или их поиске, мы не заботимся о том, где реально объекты хранится, в какой СУБД. Работа с объектами полностью абстрагирована от СУБД. Мы обращаемся к модулю данных, тот уже сам понимает по конфигурации, в каком хранилище должен быть объект и обращается к модулю соответствующего хранилища, например к MySQLStrore.php. Для хранения объектов сайта могут использоваться несколько хранилищ, причём разного типа. Хранилище определяется по URI объекта.

Мы проводили интересные эксперименты с внешним хранилищем HTTPStrore.php. Если URI объекта начинается с «http:», то работает именно оно. Выполняются HTTP REST запросы к другому сайту, и если сайт тоже на Boolive 2, то получаем желаемый результат. Да, система позволяет прототипировать объекты между сайтами!

Так как работа с данными абстрагирована от конкретной СУБД, да ещё и запросы на выборку могут ходить по сети, то использовать SQL мы просто напросто не можем. Нужен язык запросов, с одной стороны понятный и отвечающий особенностям прототипной модели данных, с другой стороны легко структурируемый, чтобы его можно было представить строкой в URL или в массивах PHP и быстро конвертировать между форматами.

Запрос на массивах

С помощью вложенных массивов запрос выглядит немного раздутым, но очень прост для программной обработки. В запросе указывается, откуда выбирать, глубина выборки, что выбирать, сортировка, ограничения и другие параметры. Условия выборки тоже структурируется.

$cond = array(
    'from' => '/Contents/news',                  // Выбор объектов из /Contents/news
    'depth' => 3,                                // Глубина выбора из from.
    'select' => 'children',                      // Что выбирать? self, children, tree, heirs, parents, protos
    'where' => array(                            // Условия выборки объединенные логическим AND
        array('attr', 'uri', '=', '?'),          // Сравнение атрибута
        array('not', array(                      // Отрицание всех условий
            array('attr', 'value', '=', '%?%')
        )),
        array('any', array(                      // Условия, объединенные логическим OR
            array('child', 'title', array(       // Условия на подчиненный объект title
                array('attr', 'value', '>', 10),
                array('attr', 'value', '<', 100),
            )),
            array('is', '/Library/basic/Number') // Кем объект является? Проверка прототипирования
        ))        
    ),
    'order' => array(                           // Сортировка
        array('uri', 'DESC'),                   // по атрибуту uri
        array('childname', 'value', 'ASC')      // по атрибуту value подчиненного с именем childname
    ),
    'limit' => array(10, 15),                   // Ограничение - выбирать с 10-го не более 15 объектов
    'key' => 'name',                            // Атрибут, который использовать для ключей массива результата
);

Запрос в URL формате

В URL формате параметр from сокращен – в итоге получается полноценный URL с указанием ресурса. Этот вариант полностью удовлетворяет RESTful и избавляет от придумывания его API для сложных выборок, хотя, об ограничениях тоже нужно думать.

$cond = "
   /Contents/news&
   depth=max&
   select=children&
   where=all(
       attr(uri,like,%25А%25)
       not(attr(value,eq,m))
       any(
           child(title,all(
               attr(value,gte,10)
               attr(value,lt,100)
           ))
           is(/Library/basic/Number)
       )       
   )&
   order=(uri,desc),(childname,value,asc)&
   limit=10,15
";

Работает так:

$result = Data::read($cond); // массив объектов
$result = Data::read("/Contents/news/news1"); // объект новости

На языке запроса описываются условия прав доступа пользователей, условия работы виджетов и другие условия. Проверить, соответствует ли выбранный ранее объект нужному условию можно программно без обращения к базе данных. А для хранилища не составляет труда структурированные условия конвертировать в свой язык, например в SQL.

Нет конфликтам в команде. Свои версии под своё дело

При установке системы или объектов сайта (читать модулей) не используются SQL дампы. Весь сайт со всеми данными экспортируется в *.info файлы JSON формата. Эти файлы используются при установке. Функция экспорта и установки объектов доступны в админке. В любой момент весь сайт можно экспортировать, перенести его файлы на другой сервер и установить. Это удобно для подготовки специальных версий систем для распространения или использования в студии под свои типовые проекты, но также для обмена модулями.

Использование info файлов решает проблему слияния баз данных от разных разработчиков при работе над сайтом или в командной разработке системы Boolive. Кроме того, данные в виде info файлов попадают в систему контроля версий и с её помощью разрешаются конфликты при объединении разных версий данных.



Если значением объекта является файл или у объекта своя логика или объект был экспортирован в info файл, то мы обнаружим папку под объект в файловой системе. Путь к папке совпадает с URI объекта. Структура папок в файловой системе совпадает со структурой данных сайта. Но не обязательно под каждый объект будет своя папка, даже если экспортирован весь сайт в info файлы. Потому что объекты-свойства не создают своего info файла, а компонуются в info файл своего родителя.

Итак, для установки системы, нужно перенести все её файлы на сервер и обратиться к сайту через браузер. В файле конфигурации config.php есть константа IS_INSTALL на случай, если вы захотите переустановить систему.

Ещё


Все технические решения будут раскрыты в документации, а самое интересное опубликовано на хабре в новых статьях. Проект Boolive развивается несколько лет, выполнено уйма работы, но чтобы система окрепла, без опаски использовалась и приносила пользу, предстоит сделать ещё несколько важных шагов. Окажите свою помощь объективной критикой, тестированием, непосредственным участием в разработке или любыми другими способами. Придайте дополнительное ускорение. Будем взаимны.

Если не терпится посмотреть систему в действии, и вы затрудняетесь самостоятельно установить её, то обращайтесь лично ко мне.

Гитхаб: https://github.com/Boolive/Boolive
Промо: http://boolive.ru
Автор: @boolive
Boolive
рейтинг 13,21
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Комментарии (67)

  • 0
    А есть демо? хочется посмотреть, а ставить себе на сервак пока желания нету.
    • 0
      С демо решаем сейчас, уж больно много свободы в админке, а с ограничениями не интересно получается ) Если не терпится, обращайтесь в личку
  • +5
    Эм. Это мне сильно напоминает drupal. Можно про какие-то приемущества по сравнению с ним привести?
    • +2
      Ну как же, «свой велосипед» :)
    • 0
      Друпал хороший, используйте его, преодоление его порога вхождения дорого стоит. Мы не стремились сделать лучше чем в другой cms, а реализовывали свои идеи для эффективной разработки сайтов, их поддержке, возможности отходить от типовых решений, удовлетворяя фантазии клиентов да и возможность свои проекты быстро реализовывать, наслаждаясь процессом и результатом. Все похожести случайны из-за схожести решаемых задач.
    • +1
      Эх, друпал, друпал… SQL-запросы в шаблонах. И чего только люди не напридумывают, лишь бы не программировать.
      • +1
        А при чем здесь, собственно, Drupal? Прям обидно :-) Криворукий программист найдет, как накосячить в другом месте, если шаблонизатор отрубит все попытки лезть в базу.
      • 0
        Эм в друпале давненько что такую фигню не делать есть view.
  • 0
    При установке на Denwer произошла ошибка (PHP Version 5.3.13)

    Ошибка
    # error
     {Boolive\errors\Error} -> {Exception}
        [code] => 'jquery.ui.SelectObject'
        [message] => 'Неверный объект'
        [file] => 'Z:\home\bo.local\www\Boolive\data\Entity.php'
        [line] => 1601
        [children] => {Array}
           ['_attribs'] => {Boolive\errors\Error} -> {Exception}
              [code] => '_attribs'
              [message] => 'Ошибки'
              [file] => 'Z:\home\bo.local\www\Boolive\errors\Error.php'
              [line] => 167
              [children] => {Array}
                 ['name'] => {Boolive\errors\Error} -> {Exception}
                    [code] => 'name'
                    [message] => 'Ошибки'
                    [file] => 'Z:\home\bo.local\www\Boolive\errors\Error.php'
                    [line] => 167
                    [children] => {Array}
                       ['regexp'] => {Boolive\errors\Error} -> {Exception}
                          [code] => 'regexp'
                          [message] => 'Некорректное регулярное выражение'
                          [file] => 'Z:\home\bo.local\www\Boolive\values\Check.php'
                          [line] => 715
                          [children] => {Array} ()
    

    • –1
      Упс, поспешили. Исправили
    • +18
      кто-то еще пользуется денвером? О_о
      • 0
        судя по всему не все могут нагуглить установку LAMP, или хотя бы AMP под Win
        • +2
          Думаю, вопрос выше был связан с тем, что у php теперь есть собственный сервер. Для «потестить cms» необязательно даже А (из амр)
          • 0
            Апач должен стоять даже у верстальщиков ИМХО, так как некоторые фичи не работают из под file://
            • 0
              Простите, какой file://?
              • 0
                Откройте локальный HTML файл в хроме и посмотрите на адресную строку
                • 0
                  Это был риторический вопрос, я вообще про то что в PHP есть встроенный HTTP сервер, там нет никаких file://.
                  • 0
                    Мы с Вами начали уже про разные вещи говорить. Сойдемся на том что я солидарен с Вами )
                    • 0
                      Ок =(
        • +3
          а чем плох денвер? И чем же так прекрасен wamp?
          • +4
            хотя бы даже предустановленным php 5.3 вместо 5,5, да и куча настроек сервера вшиты в денвер, не гибкий он.
          • +2
            Тем что он через одно место сделан каким-то редкостным извращенцем.

            Выше писали про сервер для тестов в самом php, но кроме этого есть куча вариантов от более-менее вменяемого XAMPP, который ставится «далее-далее-далее» (или из архива), до виртуалок.
            • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Редкостный извращенец — это DmitryKoterov (вики).
              Вы php не по его книге, случайно учили?
              • 0
                Вы меня оскорбить пытаетесь? О_о
                • +2
                  Нет, что Вы, я просто хотел Вам напомнить, что если инструмент Вам кажется неудобным, то это совсем не повод так отзываться о его авторе.
                  • +2
                    Да, возможно я слишком резок, но… Если инструмент нравится, то автор молодец, а если не нравится — молчи, так что ли? =)
                    Да и… не уж-то вы ни разу не вспоминали авторов того или иного изделия добрым словом? =)

                    Но думаю, лучше в личке продолжать, если хотите…
                    • +1
                      Если бы Вы сказали, что он сделан не удобно и пр. — я бы ничего Вам не ответил.
                      Но вы сказали не о продукте, а о его авторе.

                      А у Вас автор получился «редкостным извращенцем» только потому, что лично Вам его работа не понравилась.
                      • +1
                        просил же, в личку)
            • 0
              Т.е. по вашему выходит, если мне надо глянуть мельком каккую-либо CMS, то мне надо ставить LAMP\WAMP? Вместо того, что б за 2 минуты на практически любом компьютере развернуть денвер?
              • +1
                А Денвер не есть WAMP? Аббревиатура вроде бы по первым буквам включенных продуктов отличие лишь в Linux/Windows. Да и тот же XAMPP куда удачнее выглядит на фоне Денвера.
        • +1
          А мне всегда лень было ставить и настраивать каждый домен. Но денвер стал тормозным и под win я теперь юзаю Open Server.
          • –1
            напишите скрипт на php / bat / python / с который запрашивает данные и редактирует хост файл =) вы же разработчик
            • +1
              Зачем? Когда уже все есть? Зачем создавать свой велик, если он не будет лучше? Ну разве что интереса ради, любопытсва и практики, но интерес, любопытсво и практика, пока направлены на другое.
              • 0
                Одно дело готовая сборка, и совершенно другое — собственная настройка, которая так же может быть перенесена на удаленный сервер.

                Я не переубеждаю, просто хочу сказать что большинство таких проблем надуманы как раз из-за лени, как Вы сами и подчеркнули.
                • –1
                  Разрабатывать надо в той же среде, в которой приложение потом будет работать. Проще поставить виртуалку. Соответственно, можно ничего не писать на python/bat/bash и так далее. Если пользовать httpd.apache.org/docs/2.2/mod/mod_vhost_alias.html
  • +6
    Будьте добры, представьте, быть может, сравнение, быть может, просто, отличительные черты вашей CMS от других, более-менее популярных. Т.е. картинки и текст — понятно, круто, интересно. Но почему мы должны использовать именно вашу CMS?
    • –1
      Главная особенность – повторное использование всего, что создаётся. Заботиться о создании «модулей» не нужно. Любой объект проекта всегда готов для повторного использования, для улучшения, подстройки под другие задачи.
      • 0
        исключительно на мой взгляд, повторное использование чего либо напрямую зависит от спроектированного дизайна и верстки проекта, а на уровне CMS уже давно есть компонентно-ориентированная система в том же Битриксе.

        Однако, направление в котором вы мыслите мне нравится
      • +3
        Ну в теории-то оно у всех так. А по факту практика досказывает высокую связанность модулей и не готовность «всегда быть готовым для использования». С кастомизацией под задачи плохо у всех. Поэтому спрошу так. Сколько проектов уже крутиться на движке? Сколько времени в человеко-часах нужно что бы натянуть новый дизайн? Специалисты какого рода для этого нужны? Квалификация (градации: джуниор, мидл, сениор)?
        • 0
          Натягивание дизайна сводится к нарезанию html на виджеты. Если это простейший сайт, можно обойтись одним виджетом — всю верстку сделать в его шаблоне. Минут 5 хватит. Если проект сложный, то потребуется больше знаний, опыта. Движок не пытается заменить специалистов на домохозяек, но делает их работу эффективней.
        • 0
          Готовность «всегда быть готовым» для использования заложено в архитектуре движка, какая бы связанность не была. Вся связанность на уровне структуры данных. Если нужны новые связи, не нужны существующие — они изменяются. Обратите внимание на повторное использование прототипированием — это создание нового с последующей возможностью подстроить под свои нужды. Сохранится связь для обновлений, не нужно копипастить и не портится оригинальный модуль (объект).
  • 0
    Какой отвратительный визивиг :(
    • 0
      Каждому своё и в этом движок не отказывает, хоть десять разных визивиков поставьте. В обще, если детализировать текст на абзацы, то можно получить редактор текста с уникальными особенностями — в сам текст добавлять любые объекты, связывать абзацы между разными статьями, чтобы не дублировать их. Мы над таким редактором работали, получался своеобразный гугл.докс. Релиз редактора отложен на будущее ))
    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      А чем вам CKEditor не нравится? =)
      Какие есть предложения адекватные?
      • 0
        Разрешите мне ответить на ваш вопрос.
        CKEditor — бажное создание, с кривым API и не менее кривым кодом. Что там сейчас с документацией, дописали? Предложений нет.
        • 0
          В том и дело, что предложений нет, а CKE меньшее зло из возможных.
          Да, есть какие-то редакторы, где всего 1.5 функции и не менее кривое API.
          Сам недавно прикручивал новый CKE, в общем-то из коробки работает то что нужно, единственная проблема была с отсутствием бесплатного нормального файлменеджера для картинок, но благо он легко делается там.
  • +2
    Основной вопрос который нужно задать себе при разработке CMS: "кто будет пользоваться админкой". Потому что разработчику в админ панели нужен один функционал, простому веб мастеру сайта совершенной другой, авторизованному посетителю третий. Если об этом не задуматься, то получается каша. В ней неудобно работать всем сразу. Мне кажется, что именно такая каша у вас и получилась. Объективности ради замечу, что у остальных популярных CMS общего назначения проблемы абсолютно теже.
    • 0
      Функции админки настраиваются под разные категории пользователей, добавляются или срываются специфичные функции. В статье кратко, может от этого незаметно, сказано, что под особенности проекта добавляются узкоспециализированные функции редактирования. На вопрос, кто будет ею пользоваться — сперва отвечу Я! ) Но вам, спасибо, вы заставляете ещё раз возвращаться к интерфейсу админки, для нас работа над ней оказалась одной из самой сложной.
      • 0
        Т.е. из коробки набора готовых админок для разного рода юзеров нет?
        • 0
          Сейчас движок — это инструмент для создания сайта. Понятия коробки ещё нет, даётся удобство для создания своей коробки, для создания функций в точном соответствии с требованиями проекта или деятельности вебстудии. Конечно, мы планируем выпустить «коробки» под конкретные категории проектов/пользователей.
  • +1
    Очень интересно, давно думал об гибких CMS, по итогу сделал модуль для фреймворка который админку собирает по структуре таблиц.
    • +1
      Ба! Да вы изобрели скаффолдинг!
  • НЛО прилетело и опубликовало эту надпись здесь
  • –1
    Захотелось попробовать, скачал, залил на сервер, открыл браузером и…
    Увидел надпись: «В настройках PHP включите параметр «короткие теги» short_open_tag On»
    После этого всякое желание общаться с этой CMS отпало.
    • 0
      Чем вас пугают короткие теги?
      • 0
        Некошерно сие. Во-первых, не везде это можно сделать, во-вторых, ломает XML.
        • +1
          Все же стоит обратить внимание на то что:

          This directive also affected the shorthand <?= before PHP 5.4.0, which is identical to <? echo. Use of this shortcut required short_open_tag to be on. Since PHP 5.4.0, <?= is always available.

          Источник: www.php.net/manual/en/ini.core.php#ini.short-open-tag
          • 0
            Что же выбрать? Не использовать короткие теги, делая шаблоны раздутыми (вместо <?= писать <?php echo ). Ограничиться версией php 5.4 и новее, не требуя короткие теги <?. Или оставить требование и возможность использовать php 5.3?
            • +2
              Вообще короткие теги не рекомендованы к использованию были с давних пор, но вот в 5.4 решили вернуть <?= для вьюх, в частности для .phtml файлов, но при этом никто не предлагает использовать <? в других местах, так что решение очевидно:

              в шаблонах использовать <?= для вывода и <?php для конструкций, в требованиях писать PHP 5.4 и выше, или 5.3 + включенные короткие теги.

              Хотя я лично не использую <?=, везде пишу <?php echo.
              • 0
                Ок, оставили требование только для версии ниже 5.4
          • 0
            Да, я заметил. Это они правильно сделали, < ?= не ломает XML и не требует включения директивы в php.ini для PHP 5.4+.
            Так что разработчикам Boolive имеет смысл снять требование включения этой директивы для PHP 5.4+ – это, разумеется, если у них используется именно < ?=, а не просто короткие теги везде, где ни попадя.

            Кстати, ещё не очень понятно, для чего требование доступа на редактирование .htaccess…
  • +1
    Почему не используете composer? Зачем такое большое количество велосипедов(Auth.php, Cache, DB.php, Mail.php и так далее...)? И никаких тестов?
    • 0
      Необходимость подтвердится, приделаем. Классы ядра являются «мостами» к модулям системы и (или) реализуют функционал в точном соответствии с архитектурными нуждами. Претензии обоснованы только к Mail, который является временным решением.
  • 0
    Несколько комментариев и вопросов:
    Во-первых, хочу поздравить с выполненной работой. Это всегда очень волнующе выпускать свой продукт на растерзание публики.
    Во-вторых, хочу отметить, что ваши рассуждения, терминология и вообще то как у вас все построено, как ни крути, вызывает ощущение, что это очередной продукт «девелоперов для девелоперов». В связи с этим хотелось бы узнать как выпланируете «популяризировать» ваш продукт среди обычных потребителей CMS?
    В-третьих, не могли бы вы кратко рассказать как все это многообразие объектов и связей хранится в вашей базе, напримере реляционной MySQL.
    И последнее, что насчет производительности? Известно, что при повышении гибкости, как правило, страдает производительность. А судя по вашему описанию, у вас гибкость просто зашкаливает. Особое внимание уделите пожалуйста хранению и извлечению данных, а также вот этим фишкам типа «поочередно вызывает все объекты, пока один из них не сработает и т.п.

    Еще большое пожелание- сделайте демо. Интерес вы приалекли, несмотря на слог статьи. Но вс же, разворачивать у себя будет не каждый. Спасибо!
    • 0
      На текущий момент Boolive — это инструмент для разработчиков. Ещё отсутствует многообразие готовых «модулей» на разные случаи, их нужно создавать, поэтому первостепенное внимание уделено эффективности разработки. (примечание: под модулями подразумеваются любые объекты). Применяя систему в конкретных проектах, сформируется коллекция готовых решений для обычных пользователей. Документация, видеоролики и другого рода материал подготовим для разных категорий пользователей.

      По поводу хранения в mysql. Вариантов перепробовали множество, у всех свои минусы и плюсы. Иерархические отношения хранятся в отдельной таблице, реализуется метод «материализованный путь», разложенный на строки (http://habrahabr.ru/post/138947/). Для самих объектов используется две таблицы, одна для идентификации uri, в другой атрибуты объекта. Одна строка – один объект.Ещё есть таблица для больших текстов с поддержкой полнотекстового поиска. Фактически все объекты в одной таблице. В этом и есть компромисс – получаем довольно простые запросы на сложные выборки с иерархическими условиями –всё работает по целочисленным индексам очень быстро. Но, конечно, остаётся вопрос оптимальности хранить всё в одной таблице, он постоянно обсуждается. Для масштабирования предлагается секционировать таблицу. Но ещё сам движок позволяет использовать несколько хранилищ – мы можем слабосвязанные ветви иерархи хранить в отдельных базах. И да, мы всегда можем внедрит новый тип хранилища на другой субд, главное поддерживать API сохранения, удаления и выборки объектов. Есть где развернуться.

      Гибкость у системы разного плана – это не только возможность создавать желаемые структуры, но и свобода выбора, создавать ли сложные, супер детальные структуры или же обойтись простым вариантом? Запускать по очереди виджеты или же напрямую их вызывать? Какое хранилище использовать? Поэтому тут выбор от задач проекта, от его приоритетов и ресурсов.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка