Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 67
А есть демо? хочется посмотреть, а ставить себе на сервак пока желания нету.
Эм. Это мне сильно напоминает drupal. Можно про какие-то приемущества по сравнению с ним привести?
Ну как же, «свой велосипед» :)
Друпал хороший, используйте его, преодоление его порога вхождения дорого стоит. Мы не стремились сделать лучше чем в другой cms, а реализовывали свои идеи для эффективной разработки сайтов, их поддержке, возможности отходить от типовых решений, удовлетворяя фантазии клиентов да и возможность свои проекты быстро реализовывать, наслаждаясь процессом и результатом. Все похожести случайны из-за схожести решаемых задач.
При установке на 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} ()
Упс, поспешили. Исправили
кто-то еще пользуется денвером? О_о
судя по всему не все могут нагуглить установку LAMP, или хотя бы AMP под Win
Думаю, вопрос выше был связан с тем, что у php теперь есть собственный сервер. Для «потестить cms» необязательно даже А (из амр)
а чем плох денвер? И чем же так прекрасен wamp?
хотя бы даже предустановленным php 5.3 вместо 5,5, да и куча настроек сервера вшиты в денвер, не гибкий он.
Тем что он через одно место сделан каким-то редкостным извращенцем.
Выше писали про сервер для тестов в самом php, но кроме этого есть куча вариантов от более-менее вменяемого XAMPP, который ставится «далее-далее-далее» (или из архива), до виртуалок.
Выше писали про сервер для тестов в самом php, но кроме этого есть куча вариантов от более-менее вменяемого XAMPP, который ставится «далее-далее-далее» (или из архива), до виртуалок.
Вы меня оскорбить пытаетесь? О_о
Нет, что Вы, я просто хотел Вам напомнить, что если инструмент Вам кажется неудобным, то это совсем не повод так отзываться о его авторе.
Т.е. по вашему выходит, если мне надо глянуть мельком каккую-либо CMS, то мне надо ставить LAMP\WAMP? Вместо того, что б за 2 минуты на практически любом компьютере развернуть денвер?
А мне всегда лень было ставить и настраивать каждый домен. Но денвер стал тормозным и под win я теперь юзаю Open Server.
напишите скрипт на php / bat / python / с который запрашивает данные и редактирует хост файл =) вы же разработчик
Главная особенность – повторное использование всего, что создаётся. Заботиться о создании «модулей» не нужно. Любой объект проекта всегда готов для повторного использования, для улучшения, подстройки под другие задачи.
исключительно на мой взгляд, повторное использование чего либо напрямую зависит от спроектированного дизайна и верстки проекта, а на уровне CMS уже давно есть компонентно-ориентированная система в том же Битриксе.
Однако, направление в котором вы мыслите мне нравится
Однако, направление в котором вы мыслите мне нравится
Ну в теории-то оно у всех так. А по факту практика досказывает высокую связанность модулей и не готовность «всегда быть готовым для использования». С кастомизацией под задачи плохо у всех. Поэтому спрошу так. Сколько проектов уже крутиться на движке? Сколько времени в человеко-часах нужно что бы натянуть новый дизайн? Специалисты какого рода для этого нужны? Квалификация (градации: джуниор, мидл, сениор)?
Натягивание дизайна сводится к нарезанию html на виджеты. Если это простейший сайт, можно обойтись одним виджетом — всю верстку сделать в его шаблоне. Минут 5 хватит. Если проект сложный, то потребуется больше знаний, опыта. Движок не пытается заменить специалистов на домохозяек, но делает их работу эффективней.
Готовность «всегда быть готовым» для использования заложено в архитектуре движка, какая бы связанность не была. Вся связанность на уровне структуры данных. Если нужны новые связи, не нужны существующие — они изменяются. Обратите внимание на повторное использование прототипированием — это создание нового с последующей возможностью подстроить под свои нужды. Сохранится связь для обновлений, не нужно копипастить и не портится оригинальный модуль (объект).
Какой отвратительный визивиг :(
Каждому своё и в этом движок не отказывает, хоть десять разных визивиков поставьте. В обще, если детализировать текст на абзацы, то можно получить редактор текста с уникальными особенностями — в сам текст добавлять любые объекты, связывать абзацы между разными статьями, чтобы не дублировать их. Мы над таким редактором работали, получался своеобразный гугл.докс. Релиз редактора отложен на будущее ))
А чем вам CKEditor не нравится? =)
Какие есть предложения адекватные?
Какие есть предложения адекватные?
Разрешите мне ответить на ваш вопрос.
CKEditor — бажное создание, с кривым API и не менее кривым кодом. Что там сейчас с документацией, дописали? Предложений нет.
CKEditor — бажное создание, с кривым API и не менее кривым кодом. Что там сейчас с документацией, дописали? Предложений нет.
В том и дело, что предложений нет, а CKE меньшее зло из возможных.
Да, есть какие-то редакторы, где всего 1.5 функции и не менее кривое API.
Сам недавно прикручивал новый CKE, в общем-то из коробки работает то что нужно, единственная проблема была с отсутствием бесплатного нормального файлменеджера для картинок, но благо он легко делается там.
Да, есть какие-то редакторы, где всего 1.5 функции и не менее кривое API.
Сам недавно прикручивал новый CKE, в общем-то из коробки работает то что нужно, единственная проблема была с отсутствием бесплатного нормального файлменеджера для картинок, но благо он легко делается там.
Основной вопрос который нужно задать себе при разработке CMS: "кто будет пользоваться админкой". Потому что разработчику в админ панели нужен один функционал, простому веб мастеру сайта совершенной другой, авторизованному посетителю третий. Если об этом не задуматься, то получается каша. В ней неудобно работать всем сразу. Мне кажется, что именно такая каша у вас и получилась. Объективности ради замечу, что у остальных популярных CMS общего назначения проблемы абсолютно теже.
Функции админки настраиваются под разные категории пользователей, добавляются или срываются специфичные функции. В статье кратко, может от этого незаметно, сказано, что под особенности проекта добавляются узкоспециализированные функции редактирования. На вопрос, кто будет ею пользоваться — сперва отвечу Я! ) Но вам, спасибо, вы заставляете ещё раз возвращаться к интерфейсу админки, для нас работа над ней оказалась одной из самой сложной.
Т.е. из коробки набора готовых админок для разного рода юзеров нет?
Сейчас движок — это инструмент для создания сайта. Понятия коробки ещё нет, даётся удобство для создания своей коробки, для создания функций в точном соответствии с требованиями проекта или деятельности вебстудии. Конечно, мы планируем выпустить «коробки» под конкретные категории проектов/пользователей.
Очень интересно, давно думал об гибких CMS, по итогу сделал модуль для фреймворка который админку собирает по структуре таблиц.
Чем вас пугают короткие теги?
Все же стоит обратить внимание на то что:
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
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
Что же выбрать? Не использовать короткие теги, делая шаблоны раздутыми (вместо
<?= писать <?php echo ). Ограничиться версией php 5.4 и новее, не требуя короткие теги <?. Или оставить требование и возможность использовать php 5.3?Вообще короткие теги не рекомендованы к использованию были с давних пор, но вот в 5.4 решили вернуть <?= для вьюх, в частности для .phtml файлов, но при этом никто не предлагает использовать <? в других местах, так что решение очевидно:
в шаблонах использовать <?= для вывода и <?php для конструкций, в требованиях писать PHP 5.4 и выше, или 5.3 + включенные короткие теги.
Хотя я лично не использую <?=, везде пишу <?php echo.
в шаблонах использовать <?= для вывода и <?php для конструкций, в требованиях писать PHP 5.4 и выше, или 5.3 + включенные короткие теги.
Хотя я лично не использую <?=, везде пишу <?php echo.
Несколько комментариев и вопросов:
Во-первых, хочу поздравить с выполненной работой. Это всегда очень волнующе выпускать свой продукт на растерзание публики.
Во-вторых, хочу отметить, что ваши рассуждения, терминология и вообще то как у вас все построено, как ни крути, вызывает ощущение, что это очередной продукт «девелоперов для девелоперов». В связи с этим хотелось бы узнать как выпланируете «популяризировать» ваш продукт среди обычных потребителей CMS?
В-третьих, не могли бы вы кратко рассказать как все это многообразие объектов и связей хранится в вашей базе, напримере реляционной MySQL.
И последнее, что насчет производительности? Известно, что при повышении гибкости, как правило, страдает производительность. А судя по вашему описанию, у вас гибкость просто зашкаливает. Особое внимание уделите пожалуйста хранению и извлечению данных, а также вот этим фишкам типа «поочередно вызывает все объекты, пока один из них не сработает и т.п.
Еще большое пожелание- сделайте демо. Интерес вы приалекли, несмотря на слог статьи. Но вс же, разворачивать у себя будет не каждый. Спасибо!
Во-первых, хочу поздравить с выполненной работой. Это всегда очень волнующе выпускать свой продукт на растерзание публики.
Во-вторых, хочу отметить, что ваши рассуждения, терминология и вообще то как у вас все построено, как ни крути, вызывает ощущение, что это очередной продукт «девелоперов для девелоперов». В связи с этим хотелось бы узнать как выпланируете «популяризировать» ваш продукт среди обычных потребителей CMS?
В-третьих, не могли бы вы кратко рассказать как все это многообразие объектов и связей хранится в вашей базе, напримере реляционной MySQL.
И последнее, что насчет производительности? Известно, что при повышении гибкости, как правило, страдает производительность. А судя по вашему описанию, у вас гибкость просто зашкаливает. Особое внимание уделите пожалуйста хранению и извлечению данных, а также вот этим фишкам типа «поочередно вызывает все объекты, пока один из них не сработает и т.п.
Еще большое пожелание- сделайте демо. Интерес вы приалекли, несмотря на слог статьи. Но вс же, разворачивать у себя будет не каждый. Спасибо!
На текущий момент Boolive — это инструмент для разработчиков. Ещё отсутствует многообразие готовых «модулей» на разные случаи, их нужно создавать, поэтому первостепенное внимание уделено эффективности разработки. (примечание: под модулями подразумеваются любые объекты). Применяя систему в конкретных проектах, сформируется коллекция готовых решений для обычных пользователей. Документация, видеоролики и другого рода материал подготовим для разных категорий пользователей.
По поводу хранения в mysql. Вариантов перепробовали множество, у всех свои минусы и плюсы. Иерархические отношения хранятся в отдельной таблице, реализуется метод «материализованный путь», разложенный на строки (http://habrahabr.ru/post/138947/). Для самих объектов используется две таблицы, одна для идентификации uri, в другой атрибуты объекта. Одна строка – один объект.Ещё есть таблица для больших текстов с поддержкой полнотекстового поиска. Фактически все объекты в одной таблице. В этом и есть компромисс – получаем довольно простые запросы на сложные выборки с иерархическими условиями –всё работает по целочисленным индексам очень быстро. Но, конечно, остаётся вопрос оптимальности хранить всё в одной таблице, он постоянно обсуждается. Для масштабирования предлагается секционировать таблицу. Но ещё сам движок позволяет использовать несколько хранилищ – мы можем слабосвязанные ветви иерархи хранить в отдельных базах. И да, мы всегда можем внедрит новый тип хранилища на другой субд, главное поддерживать API сохранения, удаления и выборки объектов. Есть где развернуться.
Гибкость у системы разного плана – это не только возможность создавать желаемые структуры, но и свобода выбора, создавать ли сложные, супер детальные структуры или же обойтись простым вариантом? Запускать по очереди виджеты или же напрямую их вызывать? Какое хранилище использовать? Поэтому тут выбор от задач проекта, от его приоритетов и ресурсов.
По поводу хранения в mysql. Вариантов перепробовали множество, у всех свои минусы и плюсы. Иерархические отношения хранятся в отдельной таблице, реализуется метод «материализованный путь», разложенный на строки (http://habrahabr.ru/post/138947/). Для самих объектов используется две таблицы, одна для идентификации uri, в другой атрибуты объекта. Одна строка – один объект.Ещё есть таблица для больших текстов с поддержкой полнотекстового поиска. Фактически все объекты в одной таблице. В этом и есть компромисс – получаем довольно простые запросы на сложные выборки с иерархическими условиями –всё работает по целочисленным индексам очень быстро. Но, конечно, остаётся вопрос оптимальности хранить всё в одной таблице, он постоянно обсуждается. Для масштабирования предлагается секционировать таблицу. Но ещё сам движок позволяет использовать несколько хранилищ – мы можем слабосвязанные ветви иерархи хранить в отдельных базах. И да, мы всегда можем внедрит новый тип хранилища на другой субд, главное поддерживать API сохранения, удаления и выборки объектов. Есть где развернуться.
Гибкость у системы разного плана – это не только возможность создавать желаемые структуры, но и свобода выбора, создавать ли сложные, супер детальные структуры или же обойтись простым вариантом? Запускать по очереди виджеты или же напрямую их вызывать? Какое хранилище использовать? Поэтому тут выбор от задач проекта, от его приоритетов и ресурсов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Гибкая cms для смелых проектов