Pull to refresh

Comments 67

А есть демо? хочется посмотреть, а ставить себе на сервак пока желания нету.
С демо решаем сейчас, уж больно много свободы в админке, а с ограничениями не интересно получается ) Если не терпится, обращайтесь в личку
Эм. Это мне сильно напоминает drupal. Можно про какие-то приемущества по сравнению с ним привести?
Друпал хороший, используйте его, преодоление его порога вхождения дорого стоит. Мы не стремились сделать лучше чем в другой cms, а реализовывали свои идеи для эффективной разработки сайтов, их поддержке, возможности отходить от типовых решений, удовлетворяя фантазии клиентов да и возможность свои проекты быстро реализовывать, наслаждаясь процессом и результатом. Все похожести случайны из-за схожести решаемых задач.
UFO landed and left these words here
А при чем здесь, собственно, Drupal? Прям обидно :-) Криворукий программист найдет, как накосячить в другом месте, если шаблонизатор отрубит все попытки лезть в базу.
Эм в друпале давненько что такую фигню не делать есть view.
При установке на 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» необязательно даже А (из амр)
Апач должен стоять даже у верстальщиков ИМХО, так как некоторые фичи не работают из под file://
Откройте локальный HTML файл в хроме и посмотрите на адресную строку
Это был риторический вопрос, я вообще про то что в PHP есть встроенный HTTP сервер, там нет никаких file://.
Мы с Вами начали уже про разные вещи говорить. Сойдемся на том что я солидарен с Вами )
а чем плох денвер? И чем же так прекрасен wamp?
хотя бы даже предустановленным php 5.3 вместо 5,5, да и куча настроек сервера вшиты в денвер, не гибкий он.
Тем что он через одно место сделан каким-то редкостным извращенцем.

Выше писали про сервер для тестов в самом php, но кроме этого есть куча вариантов от более-менее вменяемого XAMPP, который ставится «далее-далее-далее» (или из архива), до виртуалок.
UFO landed and left these words here
Вы меня оскорбить пытаетесь? О_о
Нет, что Вы, я просто хотел Вам напомнить, что если инструмент Вам кажется неудобным, то это совсем не повод так отзываться о его авторе.
Да, возможно я слишком резок, но… Если инструмент нравится, то автор молодец, а если не нравится — молчи, так что ли? =)
Да и… не уж-то вы ни разу не вспоминали авторов того или иного изделия добрым словом? =)

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

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

Я не переубеждаю, просто хочу сказать что большинство таких проблем надуманы как раз из-за лени, как Вы сами и подчеркнули.
UFO landed and left these words here
UFO landed and left these words here
Главная особенность – повторное использование всего, что создаётся. Заботиться о создании «модулей» не нужно. Любой объект проекта всегда готов для повторного использования, для улучшения, подстройки под другие задачи.
исключительно на мой взгляд, повторное использование чего либо напрямую зависит от спроектированного дизайна и верстки проекта, а на уровне CMS уже давно есть компонентно-ориентированная система в том же Битриксе.

Однако, направление в котором вы мыслите мне нравится
Ну в теории-то оно у всех так. А по факту практика досказывает высокую связанность модулей и не готовность «всегда быть готовым для использования». С кастомизацией под задачи плохо у всех. Поэтому спрошу так. Сколько проектов уже крутиться на движке? Сколько времени в человеко-часах нужно что бы натянуть новый дизайн? Специалисты какого рода для этого нужны? Квалификация (градации: джуниор, мидл, сениор)?
Натягивание дизайна сводится к нарезанию html на виджеты. Если это простейший сайт, можно обойтись одним виджетом — всю верстку сделать в его шаблоне. Минут 5 хватит. Если проект сложный, то потребуется больше знаний, опыта. Движок не пытается заменить специалистов на домохозяек, но делает их работу эффективней.
Готовность «всегда быть готовым» для использования заложено в архитектуре движка, какая бы связанность не была. Вся связанность на уровне структуры данных. Если нужны новые связи, не нужны существующие — они изменяются. Обратите внимание на повторное использование прототипированием — это создание нового с последующей возможностью подстроить под свои нужды. Сохранится связь для обновлений, не нужно копипастить и не портится оригинальный модуль (объект).
Каждому своё и в этом движок не отказывает, хоть десять разных визивиков поставьте. В обще, если детализировать текст на абзацы, то можно получить редактор текста с уникальными особенностями — в сам текст добавлять любые объекты, связывать абзацы между разными статьями, чтобы не дублировать их. Мы над таким редактором работали, получался своеобразный гугл.докс. Релиз редактора отложен на будущее ))
UFO landed and left these words here
А чем вам CKEditor не нравится? =)
Какие есть предложения адекватные?
Разрешите мне ответить на ваш вопрос.
CKEditor — бажное создание, с кривым API и не менее кривым кодом. Что там сейчас с документацией, дописали? Предложений нет.
В том и дело, что предложений нет, а CKE меньшее зло из возможных.
Да, есть какие-то редакторы, где всего 1.5 функции и не менее кривое API.
Сам недавно прикручивал новый CKE, в общем-то из коробки работает то что нужно, единственная проблема была с отсутствием бесплатного нормального файлменеджера для картинок, но благо он легко делается там.
Основной вопрос который нужно задать себе при разработке CMS: "кто будет пользоваться админкой". Потому что разработчику в админ панели нужен один функционал, простому веб мастеру сайта совершенной другой, авторизованному посетителю третий. Если об этом не задуматься, то получается каша. В ней неудобно работать всем сразу. Мне кажется, что именно такая каша у вас и получилась. Объективности ради замечу, что у остальных популярных CMS общего назначения проблемы абсолютно теже.
Функции админки настраиваются под разные категории пользователей, добавляются или срываются специфичные функции. В статье кратко, может от этого незаметно, сказано, что под особенности проекта добавляются узкоспециализированные функции редактирования. На вопрос, кто будет ею пользоваться — сперва отвечу Я! ) Но вам, спасибо, вы заставляете ещё раз возвращаться к интерфейсу админки, для нас работа над ней оказалась одной из самой сложной.
Т.е. из коробки набора готовых админок для разного рода юзеров нет?
Сейчас движок — это инструмент для создания сайта. Понятия коробки ещё нет, даётся удобство для создания своей коробки, для создания функций в точном соответствии с требованиями проекта или деятельности вебстудии. Конечно, мы планируем выпустить «коробки» под конкретные категории проектов/пользователей.
Очень интересно, давно думал об гибких CMS, по итогу сделал модуль для фреймворка который админку собирает по структуре таблиц.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Все же стоит обратить внимание на то что:

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.
Ок, оставили требование только для версии ниже 5.4
UFO landed and left these words here
Почему не используете composer? Зачем такое большое количество велосипедов(Auth.php, Cache, DB.php, Mail.php и так далее...)? И никаких тестов?
Необходимость подтвердится, приделаем. Классы ядра являются «мостами» к модулям системы и (или) реализуют функционал в точном соответствии с архитектурными нуждами. Претензии обоснованы только к Mail, который является временным решением.
Несколько комментариев и вопросов:
Во-первых, хочу поздравить с выполненной работой. Это всегда очень волнующе выпускать свой продукт на растерзание публики.
Во-вторых, хочу отметить, что ваши рассуждения, терминология и вообще то как у вас все построено, как ни крути, вызывает ощущение, что это очередной продукт «девелоперов для девелоперов». В связи с этим хотелось бы узнать как выпланируете «популяризировать» ваш продукт среди обычных потребителей CMS?
В-третьих, не могли бы вы кратко рассказать как все это многообразие объектов и связей хранится в вашей базе, напримере реляционной MySQL.
И последнее, что насчет производительности? Известно, что при повышении гибкости, как правило, страдает производительность. А судя по вашему описанию, у вас гибкость просто зашкаливает. Особое внимание уделите пожалуйста хранению и извлечению данных, а также вот этим фишкам типа «поочередно вызывает все объекты, пока один из них не сработает и т.п.

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

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

Гибкость у системы разного плана – это не только возможность создавать желаемые структуры, но и свобода выбора, создавать ли сложные, супер детальные структуры или же обойтись простым вариантом? Запускать по очереди виджеты или же напрямую их вызывать? Какое хранилище использовать? Поэтому тут выбор от задач проекта, от его приоритетов и ресурсов.
Only those users with full accounts are able to leave comments. Log in, please.