Загрузка данных
 
Логин:   Пароль:      
Регистрация   Забыли пароль?

15 горячих:

Закрыть
Загрузить:
Указать:
Выравнивание:
Альт

Состоялся следующий релиз событийно-ориентированного фрэймворка PHP_Application

PHP_Application — это платформа для разработки событийно-ориентированных приложений, в которой реализованы два механизма передачи событий для двух уровней абстракции соответственно. Первый уровень — это объекты и их события, второй — приложение и его события. Механизм передачи событий приложения поддерживает передачу направленных и широковещательных событий, а также обеспечивает синхронную или асинхронную обработку событий.

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

Подробнее о событиях PHP_Application можно прочитать в статье Событийно-ориентированные приложения в PHP

В новой версии: включена библиотека LightOrm — одна из самых быстрых ОРМ для PHP. Реализовано много новых классов, таких как Registry и классы на его основе, мощный SqlQuery билдер с поддержкой маппинга (на его основе работает LightOrm), и др. Исправлено много багов.

Теперь PHP_Application можно получить с PEAR канала, для этого нужно подключить канал channel.anter.com.ua:

1. $> pear channel-discover channel.anter.com.ua
2. $> pear config-set preferred_state beta
3. $> pear install anter/papple

P.S. PEAR канал обновляется чаще, так как он активно используется в разработке проектов, как способ дистрибуции кода.
KievMan 4 марта 2009 14:23 комментариев: 41
:) 2,16 :(

Комментарии:
витаю :)
п.с. пеар походу переживает второе рождение, я например еще год назад был уверен шо усе — ушел в историю, ан нет все так активно стали его юзать… аж страшно
standov   5 марта 2009 22:23 Комментировать может только авторизованный пользователь
:) 0 :( #
PEAR installer довольно таки полезная штука, жаль, что ещё не доведенная до ума.
KievMan   6 марта 2009 10:50 Комментировать может только авторизованный пользователь
:) 0 :( #
да именно про это и говорю, все массово подсели на инсталлер — надеюсь инсталлером ограничимся :) к нему, например, притензий не имею, когда еще после 5.3 появится phar будет «пачти Жава»
standov   11 марта 2009 14:54 Комментировать может только авторизованный пользователь
:) 0 :( #
кстати, относительно орм'а — сейчас доточил пропел до отложенных выборок — аля джанга, супер — вместе с кешированием шаблонов — бомба, подумай.
standov   5 марта 2009 22:25 Комментировать может только авторизованный пользователь
:) 0 :( #
А что тут думать, LightOrm однозначно лучше :). В пропеле нет автоматического освобождения памяти от ненужных объектов, и PHP 5.3 ему (и доктрине) в этом не поможет. Так что лучше уж вы к нам :). Тем более, что уже присоединился ещё один разработчик и сделал CollectionFactory для упрощения инициализации коллекций, причём сделал лучше, чем я собирался. Готовлюсь скоро сделать релиз.

И что такое «кешированием шаблонов»
KievMan   6 марта 2009 10:58 Комментировать может только авторизованный пользователь
:) 0 :( #
освобождение есть — если вы считаете что нужно освободить — освобождаете, про кеширование и подход отложенных выборок вот тут кое-что накрапал habrahabr.ru/sandbox/852/

Вообще хороших ОРМов в пыхе крайне мало, реально два — с твоим будет три :)
standov   11 марта 2009 14:52 Комментировать может только авторизованный пользователь
:) 0 :( #
если вы считаете что нужно освободить — освобождаете
а я ж говорил про автоматическое освобождение, а не ручное ;)

реально два — с твоим будет три :)
и на этом спасибо :)
KievMan   11 марта 2009 15:02 Комментировать может только авторизованный пользователь
:) 0 :( #
И в пропеле ты не сможешь написать:
$collectionFactory
->get('BulletinCategory')
->getItemByPK(Request:: get('categoryId'))
->getAncestor()->id

и ещё много чего в таком духе, аля jQuery
KievMan   6 марта 2009 11:03 Комментировать может только авторизованный пользователь
:) 0 :( #
могу ;) и пишу, более того запрос выполняется уже в шаблоне, сила пропела в кастомизации.
standov   11 марта 2009 14:47 Комментировать может только авторизованный пользователь
:) 0 :( #
сила пропела в кастомизации.
Твои бы силы да в полезное русло :), тем более, что авторы Пропела уже отказались от него.

В LightOrm появился ещё один разработчик, который минимальными усилиями (благодаря хорошей архитектуре LightOrm :) ) сделал на нём для себя деревья. Представляю сколько ты мог бы улучшений сделать…
KievMan   11 марта 2009 15:07 Комментировать может только авторизованный пользователь
:) 0 :( #
откуда инфа про отказались? транк регулярно обновляется :) да 2.0 затянулся, дык зачем — я имею отличные деревья трех типов в пропеле — которые тоже вроде добавили сторонние разработчики (не буду туверждать точно не уверен), а про автоматическую очистку — дык суть в том что связанные данные в 90% случаев «пригаживаются» позже и автоматически их вычищать не разумно ИМХО… про русло, я великолепно юзаю пропел уже несколько лет, дописал кучу лабуды своей, в проектах «аж гудит» — по моему в очень полезном русле нахожусь :) а главное пропел с генерацией мне дает 1 очень важное преимущество, без которого я не смог ужиться с Doctrine и Django — автодополнение в IDE.

П.С. по моему мы трошки загадили пост — может гоу в форум? :)) как в старые добрые времена
standov   11 марта 2009 16:14 Комментировать может только авторизованный пользователь
:) 0 :( #
откуда инфа про отказались?
вроде как отсюда — propel.tigris.org/ds/viewMessage.do?dsForumId=1093&dsMessageId=88191

Вообще, это бесконечный разговор. Я всё равно останусь недовольным Пропелом за его костлявость (где ты там увидел хорошую кастомизацию...), а ты всё равно будешь жалеть силы затраченные на его доработку.
KievMan   11 марта 2009 16:40 Комментировать может только авторизованный пользователь
:) 0 :( #
я фсе не осилил, но также и не нашел про отказались… ткни носом плиз, эм я потратил не на доработку (он и из коробки отличен — хоть убей не понимаю про костлявость) а на расширение и удобное сопряжение с своим фреймворком
standov   11 марта 2009 16:47 Комментировать может только авторизованный пользователь
:) 0 :( #
И много сайтов среднего уровня с нагрузкой более 10,000 было запущено на PHP Application?
GeeK GeeK   6 марта 2009 11:18 Комментировать может только авторизованный пользователь
:) 0 :( #
С такой нагрузкой небыло.
KievMan   6 марта 2009 12:06 Комментировать может только авторизованный пользователь
:) 0 :( #
Есть ли какая нибудь выгода использовать PHP Application, вместо ZF, Cake или Symphony?
На какие приложения рассчитан фреймворк?
GeeK GeeK   6 марта 2009 13:14 Комментировать может только авторизованный пользователь
:) 0 :( #
Есть. PHP_Application — это один из немногих событийно-ориентированных фрэймворков, и наиболее гибкий из них. Рассказывать здесь о преимуществах событийно-ориентированного программирования неуместно.

Фрэймворк рассчитан на сложные интерактивные приложения, такие как бэкенд. Во фронтенде он даёт большое преимущество в приложениях со сложной бизнес логикой отображения. Для простых сайтов он не лучше чем другие фрэймворки.
KievMan   6 марта 2009 13:38 Комментировать может только авторизованный пользователь
:) 0 :( #
«Рассказывать здесь о преимуществах событийно-ориентированного программирования неуместно» а вот зря, вот не проникся… написали-б например простой блог на EventDriven с начала и до конца, и статью сюда с пошаговым описанием, тогда было-б что-то видно, может и я подтянулся со свои комбайном, так сказать «Ринг».
standov   11 марта 2009 14:57 Комментировать может только авторизованный пользователь
:) 0 :( #
написали-б например простой блог на EventDriven с начала и до конца, и статью сюда с пошаговым описанием
Я имел ввиду, что в комментариях не место рассказывать о событийно-оирентированном программировании, а статьи писать — сам понимаешь, рук не хватает. Ответить на вопросы могу.
KievMan   11 марта 2009 15:09 Комментировать может только авторизованный пользователь
:) 0 :( #
думаю маленький пример «из жизни» помог бы сильно, ну вот хоть убей не вижу преимуществ в скорости разработки веб-приложений от использования EventDriven — я ведь правильно понимаю — основная наша цель создавать хорошие проекты с минимальными усилиями, для этого мы юзаем фреймворки?
standov   11 марта 2009 16:17 Комментировать может только авторизованный пользователь
:) 0 :( #
ну вот хоть убей не вижу преимуществ в скорости разработки веб-приложений от использования EventDriven
За счёт большего коэффициента повторного используемого кода. Пишешь компонент, определяешь в нём события, и потом только вешаешь обработчики на события, если нужно. Можно, конечно, как в Симфони, лазить по конфигам и включать/выключать настройки. Как я уже приводил аналогию, конструктор и ящик с регулировками, соответственно.

И не забываем про сопровождение. Событийно ориентированный код можно сделать более структурированным и наглядным, а значит более простым в сопровождении.
KievMan   11 марта 2009 16:46 Комментировать может только авторизованный пользователь
:) 0 :( #
ты знаешь, ты удивишься но у меня есть свой MVC фреймворк, там все как хочу я :)) и супер эффективное повторное использование кода, кстати эти дыбильные конфиги я тоже терпеть не могу, к фреймворку нужно иметь томик по его конфигам и ни дай бог нет чего-то что нельзя законфигурить… :) поэтому у меня, например не конфигов «совсем».

Дык пример можно? «Событийно ориентированный код можно сделать более структурированным и наглядным» ну ты-ж понимаешь что это не разговор, можно сделать все, вопрос как… можешь где-то выложить код какого-нить проекта не представляющего коммерческой ценности?
standov   11 марта 2009 16:53 Комментировать может только авторизованный пользователь
:) 0 :( #
ты сможешь добиться «супер эффективное повторное использование кода» без использования классов и функций?
KievMan   11 марта 2009 17:01 Комментировать может только авторизованный пользователь
:) 0 :( #
ммм… а зачем? если они вроде созданы для этого? эффективное применение паттернов программирования (не фанатичное как в Limb например а достаточно-эффективное) позволяет добиться очень эффективного повторного использования кода… чтобы не быть голословным webmaniacs.org.ua/ (10кб шаблонов, 10кб кода) — остальное реюз и/или генерация (в т.ч. реюз шаблонов — пока нигде в других разработках не встречал) — имеем мультиязычное приложение, модель в бд 10 таблиц, кеширование, админка, авторизация, средства миграции и отладки, под «ключ» написано за выходные из которых много была потрачено на верстку (я не верстальщик и плохо умею)
standov   11 марта 2009 17:10 Комментировать может только авторизованный пользователь
:) 0 :( #
а зачем? если они вроде созданы для этого?
т.е. ты понимаешь значение таких абстракций как «функция» и «класс» для повышения повторного использования кода.

Так вот, такая абстракция как «события», это следующий шаг к повышению повторного использования кода, при том, что сохраняется большая гибкость кода и кастомизация. Я когда-то целую статью писал по этому поводу, и ты читал её.
KievMan   11 марта 2009 17:20 Комментировать может только авторизованный пользователь
:) 0 :( #
ага, т.е. конечно не в метафизическом смысле а как результат практического подхода
standov   11 марта 2009 18:57 Комментировать может только авторизованный пользователь
:) 0 :( #
Кстати, вот ты пишешь в статье (по ссылке сверху):
Нужен базовый ORM в каком-либо виде, все что от него требуется это на все сущности, на сохранение и удаление повесить определенные события

Так к чему все эти разговоры. Ты прекрасно представляешь что и к чему :)
KievMan   11 марта 2009 17:45 Комментировать может только авторизованный пользователь
:) 0 :( #
кхе… ты знаешь я знаю что такое велосипед, я люблю велосипед но если ты мне будешь доказывать что нем классно ездить в турцию — я иак-же удивлюсь, уточню я не догоняю практическую пользу от обработки case HTTP-запрос -> HTTP-ответ событийным фреймворком да еще и однопоточным (ну суть такая у HTTP однопоточная) — я понимаю что так можно делать, я пытаюсь понять что это дает.
standov   11 марта 2009 19:01 Комментировать может только авторизованный пользователь
:) 0 :( #
я пытаюсь понять что это дает.
Ну так написано ж «для повышения повторного использования кода», и какая разница однопоточный или нет.

Во вторых, это ведь ты написал «повесить определенные события», вот и ответь, почему ты предложил именно такой вариант. А потом подумай, почему бы не расширить эту практику, на другие случаи.
KievMan   11 марта 2009 21:07 Комментировать может только авторизованный пользователь
:) 0 :( #
ну например!
я не вижу как можно еще повысить повторное использование кода по сравнению с продвинутым MVC каким-нить (я не по свой, а вообще)

да я написал, я привык есть ложкой суп а вилкой макароны, кстати там не события, там нет никакого уведомления или еще чего, есть просто класс (тег) экземпляр которого созданный с одинаковыми параметрами (конструктор) ведет себя одинаково будучи созданный в любом месте (питоновский подход где если что-то крякает то это утка) — это оказалось проще и я не понимаю какие события могут наступать при HTTP-запросе кроме события «HTTP-запрос», кстати, в частном случае (одно событие) есть паттерн filter-chain который очень эффективен действительно в web-фреймворках (в рудиментарном состоянии реализован в Symfony, Django лучше в Limb и, я считаю, наилучшим образом у меня) — там инициализируется псевдо событие и проталкивается по дереву фильтров, фильтр может либо передать его ниже — либо вытолкнуть — имхо это все, больше не требуется.
standov   11 марта 2009 22:15 Комментировать может только авторизованный пользователь
:) 0 :( #
кстати там не события, там нет никакого уведомления или еще чего
либо у тебя некорректное понимание события, либо ты сам себе противоречишь

про filter chain я здесь высказался forum.limb-project.com/viewtopic.php?t=1785&highlight=fiter+chain, это недоделанная модель событий, прими это как есть :)
KievMan   11 марта 2009 22:24 Комментировать может только авторизованный пользователь
:) 0 :( #
:) смотри, ты говоришь о событии в терминах EventDriven а я в терминах житейских, поэтому я и написал «кстати там не события» но тот факт что я вешаюсь на сохранение и удаление позволяет мне говорить о событиях в житейском смысле… это события, в моем житейском понимании, и это факт с которым я живу 27 лет :)

Да фильтер-чейн это недоделанная модель событий, я так и написал выше «частный случай», но ты не думал почему она не доделанная? да потому что больше не нужно — это частная модель на 100% покрывает потребности и плодить лишние сущности нет смысла имхо.

П.С. я понимаю что Events достаточно стройная теория, возможно самая стройная, она отлично работает во многих случаях но я не вижу никаких реальных достоинств в вебе кроме стройности, я один раз был на презентации Java Server Faces (JSF) там много и вкусно рассказывали, но 90% вопросов веб-разработчиков в конце было в стиле «а зачем это нам и что даст?» — ответа так вразумительного кроме это «современно» не последовало.
standov   12 марта 2009 09:38 Комментировать может только авторизованный пользователь
:) 0 :( #
но я не вижу никаких реальных достоинств в вебе кроме стройности
Используя только функции и классы ты получаешь код с древовидной зависимостью, от вызова какого-от общего метода или функции и к деталям.

Например, твоё приложение запускается методом Application:: run(), в этом методе ты должен явно прописать вызовы других методов, а те, в свою очередь, других и т.д. Возникают сложные древовидные зависимости в коде. Их слегка можно разрулить используя интерфейсы.

В моём методе Application:: run() из очереди событий достаётся событие и отправляется на обработку. Естественно, все компоненты приложения также должны реализовывать определённый интерфейс, состоящий из одного метода handleEvent(), а дальше алгоритм обработки ХТТП запроса зависит от очереди событий, ВНИМАНИЕ, которая создаётся в рантайме. Всё зависит от очереди событий.

При использовании событий получается меньше зависимостей в коде. Объекту, который генерирует событие не нужно ничего знать о том, кто и как обработает его событие. Соответственно, не нужно передавать в конструкторе или параметре ссылку на объект-обработчик. Прикладным программистам нет необходимости лезть в код класса или наследоваться от него, достаточно навесить свой обработчик нужного события.

В общем много чего ещё, но нет сейчас времени писать.
KievMan   12 марта 2009 13:56 Комментировать может только авторизованный пользователь
:) 0 :( #
у меня в «конфигураторе» создается дерево «фильтров-роутеров», в методе run создается объект контекста, содержащий запрос-ответ и стек параметров и этот контекст пропускается по дереву filter-chain и выплевывается в браузер… чет я не вижу всех тех недостатков которые ты описал и это без евентов.

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

standov   12 марта 2009 14:51 Комментировать может только авторизованный пользователь
:) 0 :( #
ну если так, тогда конечно…
KievMan   12 марта 2009 16:14 Комментировать может только авторизованный пользователь
:) 0 :( #
Кстати, хорошая идея, про кеширование… Я заюзаю…
KievMan   11 марта 2009 17:48 Комментировать может только авторизованный пользователь
:) 0 :( #
ты лучче заапрувь если на хабре зареган :)) мое это
standov   11 марта 2009 19:01 Комментировать может только авторизованный пользователь
:) 0 :( #
И MVC PHP Application не использует?
GeeK GeeK   6 марта 2009 13:17 Комментировать может только авторизованный пользователь
:) 0 :( #
в PHP_Application есть полное разделение логики от отображения, но основанное не на MVC парадигме. Реальные приложения имеют значительно больше уровней чем три уровня MVC. В PHP_Application, благодаря архитектуре, они легко разделяемы и сопровождаемы.
KievMan   6 марта 2009 13:42 Комментировать может только авторизованный пользователь
:) 0 :( #
Ссылка на LightOrm не совсем верная.
joker   10 марта 2009 09:06 Комментировать может только авторизованный пользователь
:) 0 :( #
Спасибо, поправил.
KievMan   10 марта 2009 09:24 Комментировать может только авторизованный пользователь
:) 0 :( #
Только зарегистрированные пользователи могут оставлять комментарии.
© 2008 | О сайте | Инструкции | Обратная связь
© Powered by BigStreet

Работа с БД:
 Время - 0.0035
 Запросов - 7
Работа с кэшем:
 Время - 0.0036
 Записей - 2
 Прочтений - 5
Общее время:
 0.0486