Состоялся следующий релиз событийно-ориентированного фрэймворка PHP_Application
PHP_Application — это платформа для разработки событийно-ориентированных приложений, в которой реализованы два механизма передачи событий для двух уровней абстракции соответственно. Первый уровень — это объекты и их события, второй — приложение и его события. Механизм передачи событий приложения поддерживает передачу направленных и широковещательных событий, а также обеспечивает синхронную или асинхронную обработку событий.
Структура приложения представляет собой иерархию объектов с различными уровнями абстракции. Функциональность приложения полностью определяется набором объектов, входящих в состав приложения, и взаимодействием между ними, т.е. потоком событий. Используемая структура приложения позволяет управлять потоком событий распространяющимся вниз по иерархии объектов.
В новой версии: включена библиотека LightOrm — одна из самых быстрых ОРМ для PHP. Реализовано много новых классов, таких как Registry и классы на его основе, мощный SqlQuery билдер с поддержкой маппинга (на его основе работает LightOrm), и др. Исправлено много багов.
Теперь PHP_Application можно получить с PEAR канала, для этого нужно подключить канал channel.anter.com.ua:
витаю :) п.с. пеар походу переживает второе рождение, я например еще год назад был уверен шо усе — ушел в историю, ан нет все так активно стали его юзать… аж страшно
да именно про это и говорю, все массово подсели на инсталлер — надеюсь инсталлером ограничимся :) к нему, например, притензий не имею, когда еще после 5.3 появится phar будет «пачти Жава»
А что тут думать, LightOrm однозначно лучше :). В пропеле нет автоматического освобождения памяти от ненужных объектов, и PHP 5.3 ему (и доктрине) в этом не поможет. Так что лучше уж вы к нам :). Тем более, что уже присоединился ещё один разработчик и сделал CollectionFactory для упрощения инициализации коллекций, причём сделал лучше, чем я собирался. Готовлюсь скоро сделать релиз.
освобождение есть — если вы считаете что нужно освободить — освобождаете, про кеширование и подход отложенных выборок вот тут кое-что накрапал habrahabr.ru/sandbox/852/
Вообще хороших ОРМов в пыхе крайне мало, реально два — с твоим будет три :)
сила пропела в кастомизации. Твои бы силы да в полезное русло :), тем более, что авторы Пропела уже отказались от него.
В LightOrm появился ещё один разработчик, который минимальными усилиями (благодаря хорошей архитектуре LightOrm :) ) сделал на нём для себя деревья. Представляю сколько ты мог бы улучшений сделать…
откуда инфа про отказались? транк регулярно обновляется :) да 2.0 затянулся, дык зачем — я имею отличные деревья трех типов в пропеле — которые тоже вроде добавили сторонние разработчики (не буду туверждать точно не уверен), а про автоматическую очистку — дык суть в том что связанные данные в 90% случаев «пригаживаются» позже и автоматически их вычищать не разумно ИМХО… про русло, я великолепно юзаю пропел уже несколько лет, дописал кучу лабуды своей, в проектах «аж гудит» — по моему в очень полезном русле нахожусь :) а главное пропел с генерацией мне дает 1 очень важное преимущество, без которого я не смог ужиться с Doctrine и Django — автодополнение в IDE.
П.С. по моему мы трошки загадили пост — может гоу в форум? :)) как в старые добрые времена
Вообще, это бесконечный разговор. Я всё равно останусь недовольным Пропелом за его костлявость (где ты там увидел хорошую кастомизацию...), а ты всё равно будешь жалеть силы затраченные на его доработку.
я фсе не осилил, но также и не нашел про отказались… ткни носом плиз, эм я потратил не на доработку (он и из коробки отличен — хоть убей не понимаю про костлявость) а на расширение и удобное сопряжение с своим фреймворком
Есть. PHP_Application — это один из немногих событийно-ориентированных фрэймворков, и наиболее гибкий из них. Рассказывать здесь о преимуществах событийно-ориентированного программирования неуместно.
Фрэймворк рассчитан на сложные интерактивные приложения, такие как бэкенд. Во фронтенде он даёт большое преимущество в приложениях со сложной бизнес логикой отображения. Для простых сайтов он не лучше чем другие фрэймворки.
«Рассказывать здесь о преимуществах событийно-ориентированного программирования неуместно» а вот зря, вот не проникся… написали-б например простой блог на EventDriven с начала и до конца, и статью сюда с пошаговым описанием, тогда было-б что-то видно, может и я подтянулся со свои комбайном, так сказать «Ринг».
написали-б например простой блог на EventDriven с начала и до конца, и статью сюда с пошаговым описанием Я имел ввиду, что в комментариях не место рассказывать о событийно-оирентированном программировании, а статьи писать — сам понимаешь, рук не хватает. Ответить на вопросы могу.
думаю маленький пример «из жизни» помог бы сильно, ну вот хоть убей не вижу преимуществ в скорости разработки веб-приложений от использования EventDriven — я ведь правильно понимаю — основная наша цель создавать хорошие проекты с минимальными усилиями, для этого мы юзаем фреймворки?
ну вот хоть убей не вижу преимуществ в скорости разработки веб-приложений от использования EventDriven За счёт большего коэффициента повторного используемого кода. Пишешь компонент, определяешь в нём события, и потом только вешаешь обработчики на события, если нужно. Можно, конечно, как в Симфони, лазить по конфигам и включать/выключать настройки. Как я уже приводил аналогию, конструктор и ящик с регулировками, соответственно.
И не забываем про сопровождение. Событийно ориентированный код можно сделать более структурированным и наглядным, а значит более простым в сопровождении.
ты знаешь, ты удивишься но у меня есть свой MVC фреймворк, там все как хочу я :)) и супер эффективное повторное использование кода, кстати эти дыбильные конфиги я тоже терпеть не могу, к фреймворку нужно иметь томик по его конфигам и ни дай бог нет чего-то что нельзя законфигурить… :) поэтому у меня, например не конфигов «совсем».
Дык пример можно? «Событийно ориентированный код можно сделать более структурированным и наглядным» ну ты-ж понимаешь что это не разговор, можно сделать все, вопрос как… можешь где-то выложить код какого-нить проекта не представляющего коммерческой ценности?
ммм… а зачем? если они вроде созданы для этого? эффективное применение паттернов программирования (не фанатичное как в Limb например а достаточно-эффективное) позволяет добиться очень эффективного повторного использования кода… чтобы не быть голословным webmaniacs.org.ua/ (10кб шаблонов, 10кб кода) — остальное реюз и/или генерация (в т.ч. реюз шаблонов — пока нигде в других разработках не встречал) — имеем мультиязычное приложение, модель в бд 10 таблиц, кеширование, админка, авторизация, средства миграции и отладки, под «ключ» написано за выходные из которых много была потрачено на верстку (я не верстальщик и плохо умею)
а зачем? если они вроде созданы для этого? т.е. ты понимаешь значение таких абстракций как «функция» и «класс» для повышения повторного использования кода.
Так вот, такая абстракция как «события», это следующий шаг к повышению повторного использования кода, при том, что сохраняется большая гибкость кода и кастомизация. Я когда-то целую статью писал по этому поводу, и ты читал её.
Кстати, вот ты пишешь в статье (по ссылке сверху): Нужен базовый ORM в каком-либо виде, все что от него требуется это на все сущности, на сохранение и удаление повесить определенные события
Так к чему все эти разговоры. Ты прекрасно представляешь что и к чему :)
кхе… ты знаешь я знаю что такое велосипед, я люблю велосипед но если ты мне будешь доказывать что нем классно ездить в турцию — я иак-же удивлюсь, уточню я не догоняю практическую пользу от обработки case HTTP-запрос -> HTTP-ответ событийным фреймворком да еще и однопоточным (ну суть такая у HTTP однопоточная) — я понимаю что так можно делать, я пытаюсь понять что это дает.
я пытаюсь понять что это дает. Ну так написано ж «для повышения повторного использования кода», и какая разница однопоточный или нет.
Во вторых, это ведь ты написал «повесить определенные события», вот и ответь, почему ты предложил именно такой вариант. А потом подумай, почему бы не расширить эту практику, на другие случаи.
ну например! я не вижу как можно еще повысить повторное использование кода по сравнению с продвинутым MVC каким-нить (я не по свой, а вообще)
да я написал, я привык есть ложкой суп а вилкой макароны, кстати там не события, там нет никакого уведомления или еще чего, есть просто класс (тег) экземпляр которого созданный с одинаковыми параметрами (конструктор) ведет себя одинаково будучи созданный в любом месте (питоновский подход где если что-то крякает то это утка) — это оказалось проще и я не понимаю какие события могут наступать при HTTP-запросе кроме события «HTTP-запрос», кстати, в частном случае (одно событие) есть паттерн filter-chain который очень эффективен действительно в web-фреймворках (в рудиментарном состоянии реализован в Symfony, Django лучше в Limb и, я считаю, наилучшим образом у меня) — там инициализируется псевдо событие и проталкивается по дереву фильтров, фильтр может либо передать его ниже — либо вытолкнуть — имхо это все, больше не требуется.
:) смотри, ты говоришь о событии в терминах EventDriven а я в терминах житейских, поэтому я и написал «кстати там не события» но тот факт что я вешаюсь на сохранение и удаление позволяет мне говорить о событиях в житейском смысле… это события, в моем житейском понимании, и это факт с которым я живу 27 лет :)
Да фильтер-чейн это недоделанная модель событий, я так и написал выше «частный случай», но ты не думал почему она не доделанная? да потому что больше не нужно — это частная модель на 100% покрывает потребности и плодить лишние сущности нет смысла имхо.
П.С. я понимаю что Events достаточно стройная теория, возможно самая стройная, она отлично работает во многих случаях но я не вижу никаких реальных достоинств в вебе кроме стройности, я один раз был на презентации Java Server Faces (JSF) там много и вкусно рассказывали, но 90% вопросов веб-разработчиков в конце было в стиле «а зачем это нам и что даст?» — ответа так вразумительного кроме это «современно» не последовало.
но я не вижу никаких реальных достоинств в вебе кроме стройности Используя только функции и классы ты получаешь код с древовидной зависимостью, от вызова какого-от общего метода или функции и к деталям.
Например, твоё приложение запускается методом Application:: run(), в этом методе ты должен явно прописать вызовы других методов, а те, в свою очередь, других и т.д. Возникают сложные древовидные зависимости в коде. Их слегка можно разрулить используя интерфейсы.
В моём методе Application:: run() из очереди событий достаётся событие и отправляется на обработку. Естественно, все компоненты приложения также должны реализовывать определённый интерфейс, состоящий из одного метода handleEvent(), а дальше алгоритм обработки ХТТП запроса зависит от очереди событий, ВНИМАНИЕ, которая создаётся в рантайме. Всё зависит от очереди событий.
При использовании событий получается меньше зависимостей в коде. Объекту, который генерирует событие не нужно ничего знать о том, кто и как обработает его событие. Соответственно, не нужно передавать в конструкторе или параметре ссылку на объект-обработчик. Прикладным программистам нет необходимости лезть в код класса или наследоваться от него, достаточно навесить свой обработчик нужного события.
В общем много чего ещё, но нет сейчас времени писать.
у меня в «конфигураторе» создается дерево «фильтров-роутеров», в методе run создается объект контекста, содержащий запрос-ответ и стек параметров и этот контекст пропускается по дереву filter-chain и выплевывается в браузер… чет я не вижу всех тех недостатков которые ты описал и это без евентов.
«Объекту, который генерирует событие не нужно ничего знать о том, кто и как обработает его событие» стопудова только это в основном заслуга нормальных паттернов «Соответственно, не нужно передавать в конструкторе или параметре ссылку на объект-обработчик» не понял «Прикладным программистам нет необходимости лезть в код класса или наследоваться от него, достаточно навесить свой обработчик нужного события» ну я так понимаю что им, в твоем случае необходимо знать про оперируемые события.
в PHP_Application есть полное разделение логики от отображения, но основанное не на MVC парадигме. Реальные приложения имеют значительно больше уровней чем три уровня MVC. В PHP_Application, благодаря архитектуре, они легко разделяемы и сопровождаемы.
п.с. пеар походу переживает второе рождение, я например еще год назад был уверен шо усе — ушел в историю, ан нет все так активно стали его юзать… аж страшно
И что такое «кешированием шаблонов»
Вообще хороших ОРМов в пыхе крайне мало, реально два — с твоим будет три :)
а я ж говорил про автоматическое освобождение, а не ручное ;)
реально два — с твоим будет три :)
и на этом спасибо :)
$collectionFactory
->get('BulletinCategory')
->getItemByPK(Request:: get('categoryId'))
->getAncestor()->id
и ещё много чего в таком духе, аля jQuery
Твои бы силы да в полезное русло :), тем более, что авторы Пропела уже отказались от него.
В LightOrm появился ещё один разработчик, который минимальными усилиями (благодаря хорошей архитектуре LightOrm :) ) сделал на нём для себя деревья. Представляю сколько ты мог бы улучшений сделать…
П.С. по моему мы трошки загадили пост — может гоу в форум? :)) как в старые добрые времена
вроде как отсюда — propel.tigris.org/ds/viewMessage.do?dsForumId=1093&dsMessageId=88191
Вообще, это бесконечный разговор. Я всё равно останусь недовольным Пропелом за его костлявость (где ты там увидел хорошую кастомизацию...), а ты всё равно будешь жалеть силы затраченные на его доработку.
На какие приложения рассчитан фреймворк?
Фрэймворк рассчитан на сложные интерактивные приложения, такие как бэкенд. Во фронтенде он даёт большое преимущество в приложениях со сложной бизнес логикой отображения. Для простых сайтов он не лучше чем другие фрэймворки.
Я имел ввиду, что в комментариях не место рассказывать о событийно-оирентированном программировании, а статьи писать — сам понимаешь, рук не хватает. Ответить на вопросы могу.
За счёт большего коэффициента повторного используемого кода. Пишешь компонент, определяешь в нём события, и потом только вешаешь обработчики на события, если нужно. Можно, конечно, как в Симфони, лазить по конфигам и включать/выключать настройки. Как я уже приводил аналогию, конструктор и ящик с регулировками, соответственно.
И не забываем про сопровождение. Событийно ориентированный код можно сделать более структурированным и наглядным, а значит более простым в сопровождении.
Дык пример можно? «Событийно ориентированный код можно сделать более структурированным и наглядным» ну ты-ж понимаешь что это не разговор, можно сделать все, вопрос как… можешь где-то выложить код какого-нить проекта не представляющего коммерческой ценности?
т.е. ты понимаешь значение таких абстракций как «функция» и «класс» для повышения повторного использования кода.
Так вот, такая абстракция как «события», это следующий шаг к повышению повторного использования кода, при том, что сохраняется большая гибкость кода и кастомизация. Я когда-то целую статью писал по этому поводу, и ты читал её.
Нужен базовый ORM в каком-либо виде, все что от него требуется это на все сущности, на сохранение и удаление повесить определенные события
Так к чему все эти разговоры. Ты прекрасно представляешь что и к чему :)
Ну так написано ж «для повышения повторного использования кода», и какая разница однопоточный или нет.
Во вторых, это ведь ты написал «повесить определенные события», вот и ответь, почему ты предложил именно такой вариант. А потом подумай, почему бы не расширить эту практику, на другие случаи.
я не вижу как можно еще повысить повторное использование кода по сравнению с продвинутым MVC каким-нить (я не по свой, а вообще)
да я написал, я привык есть ложкой суп а вилкой макароны, кстати там не события, там нет никакого уведомления или еще чего, есть просто класс (тег) экземпляр которого созданный с одинаковыми параметрами (конструктор) ведет себя одинаково будучи созданный в любом месте (питоновский подход где если что-то крякает то это утка) — это оказалось проще и я не понимаю какие события могут наступать при HTTP-запросе кроме события «HTTP-запрос», кстати, в частном случае (одно событие) есть паттерн filter-chain который очень эффективен действительно в web-фреймворках (в рудиментарном состоянии реализован в Symfony, Django лучше в Limb и, я считаю, наилучшим образом у меня) — там инициализируется псевдо событие и проталкивается по дереву фильтров, фильтр может либо передать его ниже — либо вытолкнуть — имхо это все, больше не требуется.
либо у тебя некорректное понимание события, либо ты сам себе противоречишь
про filter chain я здесь высказался forum.limb-project.com/viewtopic.php?t=1785&highlight=fiter+chain, это недоделанная модель событий, прими это как есть :)
Да фильтер-чейн это недоделанная модель событий, я так и написал выше «частный случай», но ты не думал почему она не доделанная? да потому что больше не нужно — это частная модель на 100% покрывает потребности и плодить лишние сущности нет смысла имхо.
П.С. я понимаю что Events достаточно стройная теория, возможно самая стройная, она отлично работает во многих случаях но я не вижу никаких реальных достоинств в вебе кроме стройности, я один раз был на презентации Java Server Faces (JSF) там много и вкусно рассказывали, но 90% вопросов веб-разработчиков в конце было в стиле «а зачем это нам и что даст?» — ответа так вразумительного кроме это «современно» не последовало.
Используя только функции и классы ты получаешь код с древовидной зависимостью, от вызова какого-от общего метода или функции и к деталям.
Например, твоё приложение запускается методом Application:: run(), в этом методе ты должен явно прописать вызовы других методов, а те, в свою очередь, других и т.д. Возникают сложные древовидные зависимости в коде. Их слегка можно разрулить используя интерфейсы.
В моём методе Application:: run() из очереди событий достаётся событие и отправляется на обработку. Естественно, все компоненты приложения также должны реализовывать определённый интерфейс, состоящий из одного метода handleEvent(), а дальше алгоритм обработки ХТТП запроса зависит от очереди событий, ВНИМАНИЕ, которая создаётся в рантайме. Всё зависит от очереди событий.
При использовании событий получается меньше зависимостей в коде. Объекту, который генерирует событие не нужно ничего знать о том, кто и как обработает его событие. Соответственно, не нужно передавать в конструкторе или параметре ссылку на объект-обработчик. Прикладным программистам нет необходимости лезть в код класса или наследоваться от него, достаточно навесить свой обработчик нужного события.
В общем много чего ещё, но нет сейчас времени писать.
«Объекту, который генерирует событие не нужно ничего знать о том, кто и как обработает его событие» стопудова только это в основном заслуга нормальных паттернов
«Соответственно, не нужно передавать в конструкторе или параметре ссылку на объект-обработчик» не понял
«Прикладным программистам нет необходимости лезть в код класса или наследоваться от него, достаточно навесить свой обработчик нужного события» ну я так понимаю что им, в твоем случае необходимо знать про оперируемые события.