Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 37
Большое спасибо за ваш труд. Очень приятно, что фреймворк развивается, видимо феи и вправду волшебные.
Спасибки! Кстати у нас теперь есть наклейки: twitter.com/dracony_gimp/status/625388999809585153
Попробую их как-то доставить к пользователям. В Германию могу почтой передать, в Украину в принципе тоже. А вот в Россию хз, дорого ведь =(
Могу скинуть рисунком =)
Попробую их как-то доставить к пользователям. В Германию могу почтой передать, в Украину в принципе тоже. А вот в Россию хз, дорого ведь =(
Могу скинуть рисунком =)
А в каких, по вашему мнению, серьезных проектах ныне используется PHPixie? Кроме плюсов, могли бы привести минусы вашего фреймворка?
Мне если честно никто не пишет письма «мы использовали пиксю здесь» (а жаль), но можете например поискать на Гитхабе среди опенсорсных. Точно знаю что я использовал в серьезных, но не могу ссылки дать по NDA. Кстати хорошая идея сделать шоукейс на сайте.
Насчет минусов думаю самый важный в том что во второй версии не было бандлов, и как следствие код внутри коммюнити не распространялся. Для той же самой Ларавел можно с пакетов неплохой сайт собрать с минимум кода. Еще я бы сказал что порог входа все же выше чем в Ларавел, так как я старался делать «правильно» и в Пикси например нет статических «фасадов», как результат надо больше времени приделять архитектуре, параметрам конструктора итд. «По быстрому на коленке» конечно тоже можно, но не так как например в Слим. Если на Слиме можно даже без знаний ООП писать, то в Пиксе даже вот быстрый старт предполагает что пользователь понимает «чем абстрактный класс отличается от интерфейса».
Насчет минусов думаю самый важный в том что во второй версии не было бандлов, и как следствие код внутри коммюнити не распространялся. Для той же самой Ларавел можно с пакетов неплохой сайт собрать с минимум кода. Еще я бы сказал что порог входа все же выше чем в Ларавел, так как я старался делать «правильно» и в Пикси например нет статических «фасадов», как результат надо больше времени приделять архитектуре, параметрам конструктора итд. «По быстрому на коленке» конечно тоже можно, но не так как например в Слим. Если на Слиме можно даже без знаний ООП писать, то в Пиксе даже вот быстрый старт предполагает что пользователь понимает «чем абстрактный класс отличается от интерфейса».
Спасибо за развернутый ответ, не примите мой предидущий вопрос за троллинг, я давно наблюдаю за вашей разработкой, но меня не покидает ощущение что проект существует в первую очередь для себя, решения своих насущных проблем, развития в себе навыка программирования. Отасти из-за того, что нет примеров повсеместного применения другими большими компаниями, обсуждения программистами. На том же тостере всего 2 вопроса о PHPixie.
Ну думаю компании отсеивались дизайном сильно. Насчет популярности то на самом деле все хорошо: Результаты опроса популярности PHP фреймворков от Sitepoint.
Мы делали проект на PHPixie v2. Ему уже почти 2 года. Всё это время продолжает развиваться.
После перехода с xslt на twig- или php-шаблоны, очень хочется иметь в шаблонизаторе поиск, хотя бы близкий к функциональности xpath, чтобы ловко жонглировать данными и не думать о их красивой подготовке на стороне модели/контроллера. Есть что-то такое в вашем шаблонизаторе?
Хм, тут может помочь библиотека используема в конфигах, то есть 'phpixie/slice':
Например если вы делаете $data->get('users.pixie.name', 'defaultValue'); и какого-то ключа по дороге не встретилось, то получите назад свое 'defaultValue'. А с $data->slice('user'); удобно передавать параметр кусочек данных в подшаблон например. Таким образом подшаблону будет все равно на полный путь к сегменту 'user'. Но таких хитростей какие можно проедать в xpath к сожалению нет. Хотя можно сделать свое расширение для поиска, могу помочь =) Что например вам бы хотелось?
$data = $sliceComponent->arrayData($someArray);
//Providing a default value
$data->get('name', 'Trixie');
//Throw an exception if 'name' is missing
$data->getRequired('name');
//Accessing a nested field
$data->get('users.pixie.name');
//You can also 'slice' the data to avoid long paths
$pixie = $data->slice('users.pixie');
$pixie->get('name');
//Getting data as array
$data->get();
//Getting all set keys
$data->keys();
Например если вы делаете $data->get('users.pixie.name', 'defaultValue'); и какого-то ключа по дороге не встретилось, то получите назад свое 'defaultValue'. А с $data->slice('user'); удобно передавать параметр кусочек данных в подшаблон например. Таким образом подшаблону будет все равно на полный путь к сегменту 'user'. Но таких хитростей какие можно проедать в xpath к сожалению нет. Хотя можно сделать свое расширение для поиска, могу помочь =) Что например вам бы хотелось?
С сильным запозданием я осознал, что хотелось бы анаг с синтаксисом xpath, но для поиска по php-массиву. Наиболее приближенный найденный функционал — jsonpath -http://goessner.net/articles/JsonPath/. Ведь массивы php и json в принципе идентичные типы хранения данных (однозначно представляют друг друга). Костылем можно было бы использовать сам jsonpath, в аргументы ему передавая json_encode от данных шаблона.
И логотип приличный сделали
Респект за труд. Пусть будет больше фреймворков, хороших и разных!
Но. Я не могу обойтись без «но». Не сочтите за занудство.
Если вы до сих пор поддерживаете 5.3 — для меня это повод закрыть страничку проекта и никогда больше не открывать. Скажите — я ошибаюсь и вы ориентируетесь на свежие версии PHP?
Не понял? Один и тот же метод? И как различать данные из GET и POST? Или есть метод ->post('name')? Но это же ужасно!
Тоже непонятно. Если «find» — тогда "$project". Если уж "$projects" — тогда наверное должно быть «findAll». Как различаются методы, возвращающие одну запись и коллекцию записей? И есть ли вообще коллекции?
Почему не Project::class или Task::class? Как сёрфить по таким строковым литералам в IDE?
Но. Я не могу обойтись без «но». Не сочтите за занудство.
array(...)
Если вы до сих пор поддерживаете 5.3 — для меня это повод закрыть страничку проекта и никогда больше не открывать. Скажите — я ошибаюсь и вы ориентируетесь на свежие версии PHP?
//$_GET['name']
$request->query()->get('name');
//$_POST['name']
$request->data()->get('name');
Не понял? Один и тот же метод? И как различать данные из GET и POST? Или есть метод ->post('name')? Но это же ужасно!
$projects = $orm->query('project')->find();
Тоже непонятно. Если «find» — тогда "$project". Если уж "$projects" — тогда наверное должно быть «findAll». Как различаются методы, возвращающие одну запись и коллекцию записей? И есть ли вообще коллекции?
'owner' => 'project',
'items' => 'task',
Почему не Project::class или Task::class? Как сёрфить по таким строковым литералам в IDE?
Все полностью работает на 5.3 — 7 + hhvm. А что в этом собственно плохого? Вам никто не мешает использовать фишки той версии какой вам нравится, пишите '[]' сколько хотите. Я просто не видел причины урезать аудиторию ради короткого синтаксис массивов в коде.
Вы наверное не заметили:
$request->query()->get('name'); и $request->data()->get('name');. query() -> $_GET, data() -> параметры из тела запроса ( например $_POST, но также и если это JSON запрос то тоже будет распарсено).
Потому что во-первых совсем не обязательно создавать классы моделей для которых ничего не надо перегружать, во-вторых нет вообще такого понятия как класс модели. Есть класс репозитория, класс сущности и класс запроса. Конечно никто не запрещает вам сделать себе классовые константы с именами моделей и по ним серфить.
find() -> коллекция, а findOne() -> одна сущность
И как различать данные из GET и POST?
Вы наверное не заметили:
$request->query()->get('name'); и $request->data()->get('name');. query() -> $_GET, data() -> параметры из тела запроса ( например $_POST, но также и если это JSON запрос то тоже будет распарсено).
Почему не Project::class или Task::class?
Потому что во-первых совсем не обязательно создавать классы моделей для которых ничего не надо перегружать, во-вторых нет вообще такого понятия как класс модели. Есть класс репозитория, класс сущности и класс запроса. Конечно никто не запрещает вам сделать себе классовые константы с именами моделей и по ним серфить.
find() -> коллекция, а findOne() -> одна сущность
Вы наверное не заметили:
Да, не заметил, извините.
Но всё равно имена выбраны чудовищно несемантично. Почему я должен помнить, что query — это get, а data — это post или, внезапно, распарсенный JSON, причем это методы?
Ну например «Query» параметры $_GET называет и PSR-7 стандарт и HTTP RFC.
$_POST они называют Parsed Body, но так как это длинно слишком я заменил на data.
Проблема в том что ПХП неверно назвала эти массивы именами HTTP методов. Теперь когда все больше упора делается на REST это сильно заметно. Например делая HTTP PUT запрос, как то странно плучать данные с $_POST. Куда более странно при POST запросе читать что-то с $_GET.
Я мог бы назвать get() и post(), но это давно не стандарт, взгляньте например на Symfony2.
$_POST они называют Parsed Body, но так как это длинно слишком я заменил на data.
Проблема в том что ПХП неверно назвала эти массивы именами HTTP методов. Теперь когда все больше упора делается на REST это сильно заметно. Например делая HTTP PUT запрос, как то странно плучать данные с $_POST. Куда более странно при POST запросе читать что-то с $_GET.
Я мог бы назвать get() и post(), но это давно не стандарт, взгляньте например на Symfony2.
Все компоненты могут использоваться без фреймворка
Это точно? Я как-то решил заюзать библиотеку Image из версии 2, где тоже декларировалось, что компоненты могут без фреймфорка использоваться. Но оказалось, что без ядра (класса \PHPixie\Pixie) это хозяйство не работает.
Во второй версии в ядре была либа чтения конфигов, это все что было нужно этой библиотеке. То есть вы могли бы запустить Image в любом другом фреймворке, просто передав ему в параметр «new \PHPixie\Pixie». Совсем не обязательно было это ядро «запускать» методом handle_http_request(). Но мне \то почти сразу не нравилось, поэтому у третьей версии ядра нет =)
Вот например первый раздел в доках по ОРМ как раз о том как запустить без фреймворка: phpixie.com/components/orm.html
Этот коммент — ответ к habrahabr.ru/post/263551/#comment_8516543, случайно нажал не ту кнопку
Вот например первый раздел в доках по ОРМ как раз о том как запустить без фреймворка: phpixie.com/components/orm.html
Этот коммент — ответ к habrahabr.ru/post/263551/#comment_8516543, случайно нажал не ту кнопку
Да я понял, зачем там нужно было ядро, но т.к. тянуть ради этого код ядра не хотелось, то сварганил небольшой костылик, который притворялся ядром и отдавал либе конфиги. Мне интересно было, как это в новой версии реализовано (как раз в сторону ORM смотрю). Похоже, сейчас можно будет без костылей обойтись :)
Все довольно просто, во второй версии \PHPixie\Pixie также являлся DI контейнером в котором лежали все компоненты. Сейчас же компоненты принимаю зависимости строго через конструктор и не зависят совсем от контейнера. В примере с ОРМ, вы передаете ему инстанс компонента базы данных, настройки и класс со врапперами. То есть о никаком фреймворке он не знает в принцыпе и кто построил ему зависимости ему тоже не интересно =)
Несколько месяцев назад искал микрофреймворк для небольшого проекта и в итоге остановился на PHPixie. Старт с ним мне показался самым быстрым. Но на тот момент 3-я ветка была в активных коммитах, а 2-ая видимо уже вне поддержки. Решил не эксперементировать и оставить до лучших времен. При возможности попробую еще раз!
В целом выглядит симпатично. Кроме шаблонизатора. Хотя конечно в нём важнее быстродействие. Есть только пару вопросиков:
— ORM поддерживает ли вложенные запросы, транзакции? (после Phalcon, о наболевшем)
— Чем обусловлен выбор наименований в $request для работы с $_POST, $_GET?
query() — понятно,
data() — почему не post?
attributes() — почему не parameters()? В комментариях вы сами написали «параметры»…
— ORM поддерживает ли вложенные запросы, транзакции? (после Phalcon, о наболевшем)
— Чем обусловлен выбор наименований в $request для работы с $_POST, $_GET?
query() — понятно,
data() — почему не post?
attributes() — почему не parameters()? В комментариях вы сами написали «параметры»…
data() — почему не post?
Наверное потому что data бывает не только у post запросов, это может быть результат парсинга тела PUT запросов. В symfony/http-foundation оно именуется request вообще.
attributes() — почему не parameters()?
Наверное потому что это все же атрибуты а не параметры. Параметры приходят от пользователя (и по сути это query), атрибуты могут добавлять мидлвэры, парам конвертеры всякие и т.д.
Транзакции есть конечно, и даже вложенные с сейвпойнтами: github.com/phpixie/database#transactions
Вложенные запросы это больше по части базы данных а не ОРМ, они тоже тут: github.com/phpixie/database#tables-subqueries-and-joins
А чем вам не понравился шаблонизатор?
Вложенные запросы это больше по части базы данных а не ОРМ, они тоже тут: github.com/phpixie/database#tables-subqueries-and-joins
А чем вам не понравился шаблонизатор?
А почему ваш ORM не ORM а QueryBuilder?
Ммм? Я просто ссылку скинул на модуль базы данных, ОРМ в другом репозитории =)
Я про
Это как бы не ORM, это QueryBuilder. Возможно QueryBuilder + мэппер на объекты. Но я так понимаю что если я сделаю что-то типа этого:
то так оно работать не будет.
$projects = $orm->query('project')->find();
Это как бы не ORM, это QueryBuilder. Возможно QueryBuilder + мэппер на объекты. Но я так понимаю что если я сделаю что-то типа этого:
$a = $orm->query('project')->find(1);
$b = $orm->query('project')->find(1);
assert($a === $b, 'ORM должен это разруливать);
то так оно работать не будет.
Эээ, это где сказано то что ОРМ такое должен разруливать? Такое разруливают только ОРМ в которых есть ентити менеджер (который жрет память потому что должен хранить все инстансы сущностей в памяти), в ПХП насколько я знаю только доктрина так делает.
ОРМ = мапит данные к объектам и мапит связи типа один-ко-многим. QueryBuilder это если просто использовать Database компонент, там нет сущностей, просто строки с БД, нет связей и т.д.
ОРМ = мапит данные к объектам и мапит связи типа один-ко-многим. QueryBuilder это если просто использовать Database компонент, там нет сущностей, просто строки с БД, нет связей и т.д.
Работать не будет, согласен, вы одинарную кавычку пропустили.
2015, Карл
Автор — очень занимательный персонаж. Он постоянно висит в чате русского сообщества Laravel и неустанно повторяет транслитом:
и так далее… ну взрослый же человек…
Да хоть десять раз говно. Выйди ты из чата и не мучайся. То ли зависть к большому коммьюнити душит, то ли еще какие причины — мне не ведомо. Но подобное поведение для человека, который пытается продвинуть свой продукт, и по сути является лицом своего продукта — как минимум, некрасиво.
routing v vashem laravel govno
arhitectura vashego laravel govno
и так далее… ну взрослый же человек…
Да хоть десять раз говно. Выйди ты из чата и не мучайся. То ли зависть к большому коммьюнити душит, то ли еще какие причины — мне не ведомо. Но подобное поведение для человека, который пытается продвинуть свой продукт, и по сути является лицом своего продукта — как минимум, некрасиво.
Как бы я не любил Laravel (роутинг там к слову норм ибо симфони) — но поделка автора похуже будет.
Я с вами там ибо у вас самый живой русский РНР чат. В последнее время толкаю об архитектуре только когда меня спрашивают + с аргументами, а то если почитать ваш коммент, то я получается сижу и троллинг копи-пасчу =)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Быстрый старт с PHPixie 3