Господа, дамы, вчера мой проект вошел в стадию "не стыдно показать и рассказать". Проект называется EasyBricks. Bricks - от англ кирпичиков Это своего рода конструктор для разработчика. И еще движок. И еще фреймворк. У него уже есть сайт с презентацией, описанием и возможностью поиграться в этот самый конструктор. Сайт закрытый, ибо, как показал первый приглашенный тестер (runcore, разумеется, как я и обещал), там есть, чем смутить случайного посетителя. Ввиду того, что для каждого генерируется собственная "песочница", подразумевается только личный вход. Ввиду того, что сайт закрыт от публики, вход по инвайтам. Инвайты именные. Прошу, всех, кто готов помочь в тестировании, если так можно это сейчас назвать, написать мне в лс, или тут в топике, чтобы я сгенерил Вам инвайт Адрес: http://easy-bricks.com Спасибо за помощь Все предложения и вопросы, если будут, задавайте прямо здесь. Дополнение: Уже не раз говорят, что при добавлении новых бриков, некоторые выглядят "криво". Объясняю - это совершенно нормально, потому что на них не действует CSS из-за отсутствия доп.классов в дефолтных конфигурациях. Нажмите в настройках кнопку "...поиск", выберите другой конфиг, увидите разницу
Ну пока только брики можно добавлять/удалять. А что дальше делать? Документации нет. Исходников нет. Фреймворк? А ORM и MVC есть?) С какими фреймворками вы работали раньше? Чем они не понравились? "новый вымудренный синтаксис" - да вроде бы фреймворки далеко от PHP не уходят. Это в шаблонизаторах свой синтаксис, ну так не используйте их.
И настраивать, да. При этом настройки шардятся между одноименными конфигурациями, независимо от того, на какой странице они находятся. Собсно лего такое лего. В FAQ сказано, почему. Будут, но позже Может вообще окажется, что нет смысла заморачиваться.. ORM нет, из-за мнения, что он на пхп не нужен. Есть API для работы с БД. MVC ненавязчивое. Оно рекомендуется для самих бриков, поддерживается по умолчанию при наследовании от класса brick, в котором происходит инициализация, подключение "паразитарного кода" и тд., но, при этом, система не обидится, если архитектура брика не будет соответствовать "канонической". Если Вы так решили, значит Вам так нужно, значит Вы правы, значит никто не будет заставлять. Далеко особо и не уйдешь. Надо будет переписать эту строку. Речь не столько о синтаксисе, сколько о жестких правилах работы с ФВ. ZF - монструозен; Joomla(да, она тоже как фреймворк может использоваться) - заморочена, избыточна, куча капитанства и просто оберток для уже существующих функций, но с буковкой J, чтобы было стильняво. PHP внутри PHP; YII - все норм, но сильно навязчивый; Вообще EasyBricks родился как вспомогательный инструментарий для проекта, который было решено писать на чистом PHP. Потом он стал приоритетнее. Сейчас разработка вернулась в прежнее русло, но на новом корабле З.Ы. Все важные вопросы и ответы будут постепенно добавляться в FAQ.
Я привык в ORM в Yii. Уже не отучить меня) Код (PHP): $message->user->avatar->getWidth() Не представляю себе как раньше без этого жил. Чистый PHP - ну да в молодости было интересно, по 10 запросов вручную писать/разбирать, но потом устал.
Как работает у меня: Код (Text): API::send_query(mixed $query,[$return_mode],[$by_transaction],[$keep_connection]); Функция возвращает массив, содержащий результат(ы) запроса(ы), включая ошибки; $query может быть строкой с запросом, может быть массивом запросов; $return_mode - вид возвращаемого массива: 0 - индексы 1 - ассоциативный 2 - оба Для удобства присутствуют соответственные константы. $by_transation - обернуть ли запросы в транзацкию. Если true, то также проверяет наличие ошибок и делает роллбэк, если что-то пошло не так; $keep_connection - оставлять ли коннекшен открытым. По умолчанию равен константе из конфига, отвечающей за поведение коннектов к базе. Но потом будет дока, где все будет описано, еств. Черт с ним, завтра займусь описанием API
+1 -------------------------------------- Fell-x27, конкретные вопросы: - EasyBricks - это система для кого? для опытного разработчика? или для конечного(неопытного) создателя сайта? - в чем конкретные плюсы EasyBricks для {ответ_на_первый_вопрос}? без рекламной шелухи. просто приведи пример простой распространенной задачи на построение веб приложения - и как EasyBricks позволяет эффективно и легко решить такую задачу. а то людям будет сложно сразу понять предназначение и границы использования EasyBricks...
посмотрел. если отбросить чисто маркетинговые тексты, остается едва начатая админка для построения шаблонов. без исходников большего сказать не могу.
Осторожно, простыня! Это не обязательный параметр, по умолчанию равный аналогичному в конфиге системы. При этом стоит в самом конце, чтобы не мешался. Нужен, если по какой-то причине поведение обработчика подключения нужно изменить, но чтобы это не затрагивало глобально систему. И для того и для того, при наличии достаточно количества нужных готовых бриков. Так как сейчас брики добываются методом "нужно - значит напишу", то неопытному создателю сайтов, ясное дело, пока нечего делать особо. Это вполне закономерный этап. Разработчик: Полностью модульная система, с контролируемой степенью связности. Если хочется, можно делать брики, использующие в своей работе другие брики и так далее, порождая цепь зависимостей. Поддержка разруливания зависимостей, кстати, планируется в разработку. Сама разработка бриков крайне проста - просто нужно в папке bricks создать папку, одноименную брику, в ней файл index.php(мб в дальнейшем поменяю умолчание), внутри него класс, унаследованный от brick и рядом xml-манифест. Опционально рядом view.php файл для представления. Из xml-манифеста система, при установке, узнает его название, версию, определит брик это, расширение для бриков или еще что, исполнит прилагаемые SQL-запросы, зарегистрирует точки входа в ajax-шлюзе, узнает, какие параметры брик готов принять в качестве входящих при инициализации. Первичная инициализация (как абстрактного брика), подключение вьюхи, подключение расширений, передача параметров, уникального идентификатора и тд происходят автоматически. При этом на плечи разрботчика ложится только вторичная инициализация - как конкретного брика. Код при этом, разумеется, остается чистым, потому что все служебные переменные и методы спрятаны в класс-родитель, но любая вменяемая IDE их без проблем подсветит. Способы установки, хранения, парсинга настроек, использованный по умолчанию - не абсолютны. Они так же работают за счет расширений, внешнего кода, не относящегося к ядру. Если нужно, можно все переопределить. Даже брик-менеджер, отвечающий за установку, ударение, включение и отключение компонентов, является обычным бриком и может сам себя удалить. Система является конструктором не только снаружи, но и внутри, если не лень, конечно, трогать то, что и так работает, пиля свой "дистрибутив". Кроме того, допустим, мы используем "сервисную архитектуру", как у вконтакте или фейсбука, когда система является полностью распределенной, а не монолитной и ее компоненты общаются между собой только с помощью некоего API, который можно дергать и для вдругих приложений. Каждый сервис может быть поднят на EasyBricks без сожалений о том, что это "использование боинга для полива грядок". Ту же джумлу заюзать как сервисное звено, которое обрабатывает только часть запроса - жаба задушит, вот лично меня точно. Система не подключит и не использует ничего, что ей не понадобилось бы в данный момент. Как говорил в других ветках, даже процедурное ядрно у нее не цельное, просто потому что нет смысла подгружать фрагмент, отвечающий, например, за базу, если к базе мы не обратимся, верно? Далее. Используется двуслойный API, который, в будущем, позволит обеспечивать максимальную совместимость между системой версии X и бриками, написанными для более ранней системы, в случае, если API станет вести себя иначе. Deprecated-mode, дающий время на обновление компонентов, а не просто "взять и обрезать - стройте экосистему с нуля". Тема действительно обширная. Шире будет описана в дальнейшем на сайте. 1) Ну..сайт не зря одноименный системе да еще и в зоне com. Без маркетингового "краткого изложения" в таких случаях не обойтись и это, думаю, очевидно. 2) Это не админка. И она не не доделана Тут немного другая парадигма. Как движок, EasyBricks, не навязывает какого-то определенного порядка обращения с собой, в том числе, админку, которую надо изучать. Это страница, полноценная страница. Я, как администратор, вижу так все страницы и могу править их и пересобирать, когда вы присутствуете на сайте. При этом, естественно, при обновлении странички вы тут же будете видеть изменения. Тут нет как таковых шаблонов, потому что каждая страница имеет собственную архитектуру, привязанную к типу используемых бриков. Однако, если нужно общее решение а-ля "позишны", в качестве таковых можно использовать плейсхолдеры. В итоге получаем чистый размеченный макет, в который можем на месте загружать что надо и на месте настраивать, сразу видя результат. Разумеется, его можно будет передавать. Хотя есть возможности сразу генерировать готовую "сборку". Она появилась как раз когда встала задача сгенерировать каждому тестеру собственную песочницу, в которой уже что-то есть. Но это, пока, экспериментальная фича и ее включение в "основной дистрибутив" под вопросом. Админки как таковой нет. Хотя есть административные брики, которые можно забросить на страницу, сделать нужно дело, и убрать с нее, "не отходя от кассы". Так же можно скорректировать брики с других страниц, прогрузив их брата-близнеца перед глазами, сделав что надо, сохранив изменения, и убив его. При этом все,что мы сделали, останется в "настоящих" бриках. По времени это быстрее, чем копаться в админках, поверьте. Но. Если хочется, или если требуется, никто не помешает собрать себе настоящую админку. 3) Да, есть проблема, что служебные компоненты не выпадают из верстки и "рвут страницу". Покуда демка делалась с целью "успеть до конца праздников", проблема решалась параллельным просмотром страницы от лица другого пользователя в другом браузере, либо отключением отображения .brick-controller через css после сборки страницы, когда требовалась именно доводка стилями. В дальнейшем служебная компонента будет идти вне потока верстки и будет отдельная кнопка "скрыть контроллеры". И да, спасибо огромное уже сейчас. Главное, что первоначальная реакция - какое-никакое а любопытство. Значит, есть стимул писать доки и, в дальнейшем, выкладывать дистрибутив. Авось кто и поковыряет на досуге.
Я не дурак, я понял что это и зачем и почему и чему равен. Это не меняет моего мнения. Т.к. этот параметр редко используется, я б вывел его в конфиг БД.
ну вот в запросе он не нужен. это редкое явление, когда надо чтобы его как-то меняли. в большинстве случаев, вся работа в бд в рамках одного сеанса пройдёт в одно парадигме. Т.е. на надо перегружать даже дефолтными вещами. Люди крайне чувствительны к такому. Тут немного, там чуток - голова уже перегрузилась. Ты можешь делать как хочешь. Я просто говорю исходя из моего знания людей.
кстати. опубликуй алгоритм замера времени выполнения, расхода памяти и т.д. как считаешь, в какие моменты измеряешь, что складываешь.... а то померить можно поразному) у тебя сейчас пример приложения, как ты пишешь, пока без использования запросов к БД. тоесть голое выполнение скриптов. меня смущают затраты памяти. многовато. у меня есть небольшой форум на мускуле. самописный. простой. там авторизация+вывод категорий, тем, постов... по памяти там: memory_get_peak_usage: 296`616 memory_get_usage : 185`920 измерения произвожу уже после отработки view обертки. перед смертью фронт-контроллера. а у тебя почти мег. вот интересно как меришь? что туда входит.
Все. Там же написано. Замеряю непосредственно перед выбросом буфера вывода. Начало замера - старт kernel.php. Замеряю не текущее значение, а пиковое. Из этого "почти метра" где-то 150кб уходят на парсинг и подцепление отладочкого сегмента ядра, чтобы выводить эту самую инфу. В нормальном режиме работы ничего подобного цепляться не будет. Еще 150 на API-прослойку. Обрати внимание на скорость выполнения - она тоже вносит корректуру в понятие расходов памяти. Если ты изымаешь метр на 0.008 секунды, то это, считай, скрипт отработал бесплатно. Это все без аккселератора, разумеется. С аккселератором будет веселее. Далее. При дальнейшем усложнении страницы рост памяти нелинеен. Еще тысяча бриков(годных, с логикой и блекджеком) сожрут не более 3-4 метров дополнительно, к примеру. Где-то на форуме даже скрин выкладывал. Из этих 3-4 метров 95% памяти окажется занятым под буфер вывода. Выхлоп разметки и всякого там JS. Да, следует учесть, что это расходы не в режиме администрирования. Так как там повышается нагрузка. Но ведь и основные посетители - не администраторы, верно? И да, от самого брика тоже зависит. Если там алгоритмы странные, то само собой, результат будет такой же. Другое дело, что по-хорошему, на странице едва ли нужно их больше десятка.
в общем не видя кода, сложно сказать чтото конкретное, и сравниить например со своими экспериментальными движками. скорость выполнения вполне адекватная(для голого скрипта, без обращения к БД например, там сразу на порядок увеличиться). насчет "отработки бесплатно" - это пока нет нагрузки. когда проц, память, io... будут нагружены посерьезнее(на реальных нагрузках) то цифры тоже не будут такими красивыми. брики бриками, но это же только контейнеры(как я понял). когда начинается работа с данными то их объем напрямую, а иногда и больше, будет мапиться в память, для хранения и обработки внутри алгоритмов. это я к тому, что реальная годность идеологии Бриков будет видна на реальном, нагруженном проекте-примере. где будет много посетителей(а это сразу авторизация, профили, аватары, лайки, персонализация...), солидная база с данными(запросы, связанные данные, сортировки и группировки), хоть какойто обработкой этих данных(проверка прав доступа, мультиязычность, обработка форм, кеширование, модели данных)... кол-во бриков будет расти. мы сейчас видим твой сайт, по которому ничего этого невидно. потому и выводы делать не можем. ни ЗА ни ПРОТИВ твоей идеи.
Не более чем на время коннекта. Сами-то запросы быстро работают. Но тут уж от меня ничего не зависит, это уж как есть. Другое дело, что самой EasyBricks для работы бд не нужна вовсе. Ни для чего. Это тоже часть мер по оптимизации. БД используется только тогда, когда она действительно нужна. Это шарохостинг, не впс. Так что, какая-то нагрузка там все равно имеется. Можешь пробить домены по IP, там около 20 сайтов висит рядышком. Хотя хз, насколько они посещабельные. Нет, не контейнеры. Это полноценные модули. Могут быть внешние, внутренние(в todo), расширяющие. Все это полностью автономные сущности. Контейнером по идеологии и принципу работы является только брик-плейсхолдер. А, ну еще демо-брики тоже как контейнеры работают, чтобы просто было видно иерархию. Но это не обязательное поведение. Это все определяет разработчик. Да, разумеется, это понятно. А вот рост количества не обязателен. Их не нужно, по-хорошему, больше пары десятков. И система не навязывает архитектуру самого приложения, это важно. Если спроектировать рояль, то он, само собой, не полетит. Тоже полностью согласен. Потому и говорил в начале треда, что это демо "если можно его пока так назвать". Это скорее личная веха проекта, точка невозврата, после которой уже жалко съезжать. Ну и набор тестеров, как-никак, тоже не лишний. Не зря же там аккаунты регаются именные Дальше будет больше. По крайней мере, по плану.
Допустим, нужно сделать блог, в котором есть посты (картинка+текст) и теги. Сколько бриков (и какие?) я должен создать? Как этим всем управлять?
А сколько логически обособленных элементов должно быть на странице блога? Меню навигации, отдельный блок категорий, логин/разлогин, контент, хедер, футер по вкусу. Каждый такой элемент можно выразить в качестве отдельного настраиваемого брика. Управление бриками децентрализованное - увидел, настроил. Если хочется централизацию - наздоровье! Соберите отдельные страницы(или все впихните на одну), где будет по экземпляру каждого брика(либо один плейсхолдер, в который можно загрузить любой брик), загрузите в него любую конфигурацию, поправьте ее, сохраните, все. Изменения тут же разойдутся по всем экземплярам, использующим такую же конфигурацию. Можете удалить брик со страницы - он больше не нужен. Добавление брика на страницу и загрузка конфигурации - простейшие действия, по одной кнопке на каждое. Зачем усложнять то, что можно сделать проще? Из коробки будут базовые брики для управления пользователями, для установки/удаления/включения/отключения бриков, брик-расширение, позволяющее собирать страницы в реалтайме, обзорщик собранных страниц в виде дерева, если надо кратко и по существу, а не скакать по ссылкам. Если нужна именно админка - никто не мешает ее себе собрать именно с теми возможностями, какие имеются. Брики по сути - это отдельные веб-приложения. Каждый делает что-то свое. Более того, если захотите(и осилите, разумеется), каждый брик может жить на отдельном сервере. Думаю, это можно реализовать через расширения. В любом случае, архитектура системы допускает такой вариант. Вот взять этот форум - вот я пишу в окошко ввода. Ему плевать на то, что вывел просмотрщик темы. Совершенно плевать. Его задача - проверить введенную инфу и закинуть в базу. А сборщику топика нужно вытащить данные из базы и показать их пользователю. Только в концепции EasyBricks это будут не дикие перемешанные макароны как phpBB, а четко разделенные условно независимые части системы. Условно независимые, потому что никто Вам не мешает, если надо, сделать брики жестко связанными между собой на уровне логики, порождая дерево зависимостей. Ваше право. Хотя по мне это не круто. Как именно будет построен Ваш проект- зависит от вашего представления его архитектуры. Готовых решений пока что нет по очевидным причинам.