Comments 34
Ну почему не заюзать нормальный DI с явной инъекцией нужных объектов, а не таскать каштаны голой рукой из огня.
Никто не мешает, прошлый гайд показывал как передавать кастомные параметры конструктору вместо использования $builder повсюду, все это дальше работает и даже DI контейнер есть. Но в этот раз целевая аудитория более широка и хотелось сделать как можно проще.
Если вы хотите передать кастомные параметры процессору достаточно создать метод типа:
namespace Project\App;
class HTTP
{
// ...
public function buildSomeProcessor()
{
return new HTTP\Some(...);
}
}вместо того чтобы прописывать его в $classMap, этот $classMap это шорткат для новичков и совсем не обязательный. Фреймворк общается с бандлом по интерфейсу, так что никакой магии нет и можно менять все что вздумается.
Так тема с феечками уже давно пропала в принцыпе. Осталось только лого и то вполне абстрактное. Вы же не жалуетесь что на гитхабе тема с октокотом )
Черт много, так через комму написать трудно, заходите в чат расскажем )
> Черт много, так через комму написать трудно, заходите в чат расскажем
Ну как так. Давайте главные ТРИ отличительные черты, киллер-фичи (и похожие слова). Я во всех живых пхп фреймворках могу выделить подобное, в «феечках» не знаю о чём и зачем.
ну ок.
ОРМка которая поддержывает связи даже между разными типами бащ данных (можно связать таблицу мускула с коллекцией в монге). Возможность оперирования запросами хитрее (можно сразу одним запросом связать 20 постов к 40 тегам (суммарно 800 связей)) не прибегая к кастрмным запросам все на уровне ОРМ. ОРМ в отличии от елоквента например разделяет понятия репозитория, сущности и заппоса как доктрина. Поддержка Nested Sets с оптимизацией какая описана тут в отдельной статье. Словом в ОРМке фич много.
Система иерархии процессоров, котроая пощволяет настроить мидлвари хитро и качтомно и намного гибче стандартых контроллеров.
Плагабельна система автризации которая держится на интерфейсах.
Отсуствие статики и прочих антипаттернов а также инкапсуляция рантайма в контекст позволяет запустить пикси на ReactPHP практически из коробки.
Действительно независимые компоненты которые легко использовать без фреймворка.
Самый продвинутый из шаблонизаторов которые используют чистый PHP с поддержкой прикручивания своих синтаксов ( например за 2 минуты можно сделать маркдаун, хамл итд темплейтинг.
Отдельная независимая библиотека для базы данных, когда ОРМ недостаточно.
Красивая ровная архитектура.
- Много тестов, почти повсюду полный кавередж, разве кроме последних комплнентов к которым руки ещн не дошли.
Карочн заходите в чат. Многое, типа ровной архитектуры трудно доказать в комментарии.
и всё таки, расскажите про:
- Отдельная независимая библиотека для базы данных, когда ОРМ недостаточно.
Все таки это query builder, да видно, что вы заворочались на его функционале, это хорошо, но мне проще будет использовать чистый sql, чем выучить весь доступный ООП в вашем подходе.
У меня о вашем фреймворке сложилось мнение: сделаем функционально, соблюдем стандарты и обложим тестами. Подход правильный, желаю удачи в развитии. Но мне, всё же, чего-то не хватает.
На текущий момент, в работе и для личного использования я использую phalcon, laravel, django. Везде меня что-то не устраивает. Создать свой фреймворк? :)
Спасибо за ответ.
- Ничего не откомментирую, надо посмотреть/почитать о чём речь.
- Не понял, что тут написано.
- Посмотрю в документации, но от себя скажу (субъективно), что мне не нравится, как раз готовые реализации для авторизации/аутентификации в фреймворках, будь-то yii со свои rdac или laravel с тем, что они сделали в последних версиях, благо можно всё сделать по своему. Я за свободу, как в phalcon или symfony (>2)
- Про антипаттерны — это холливар, то что сделано в laravel, сделано красиво, как надстройка над избыточностью symfony. Мне кажется, что ругать статические вызовы, это больше от непонимания вопроса, что это и зачем.
ReactPHP мне на практике не приходилось использовать, поэтому оценить тут не могу. Тут я phalcon рассматриваю, как некий аналог. - А в симфони они не "действительно" независимые?
- Вот, это как раз, то что при первом взгляде (на самом деле при втором, первый — феечки :) ) на PhpPixie и оттолкнуло, не нравится мне php как шаблонизатор (субъективно).
- Дайте ссылку, где почитать, о чём речь.
- Это спорно. Мне красиво смотреть, как выглядят статические вызовы в laravel, но это как раз и совсем не всем нравится.
- Это хорошо и правильно, но не аргумент. Так как тесты все должны писать, если делают продукт для использования другими.
1) Фреймворк который можно изучить целиком. Лезть в дебри ларавела или Yii желания никогда не возникало, а ситуации когда фреймворк есть смысл «подточить» под проект случаются.
2) Пикси не заставляет вас следовать своим правилам. Можно писать как рекомендуют авторы, а можно и собственное видение использовать, самое главное что фреймворк этому не помешает никоим образом.
3) Когда вы пользуетесь фв-мастодонтом, есть ощущение что вы пишете на какой-то надстройке над PHP, и когда изучаете кажется что учите новый язык. В коде пикси фреймворка не видно вообще.
4) Он очень шустрый.
5) Встроенная ОРМ. Из легких орм-ок для пхп я не видел ничего лучше
Спасибо, вашу точку зрения принял, вопросы:
1) Про дебри фреймворков это вопрос спорный, по мне так дебри ларавеля вполне себе приятные, но вот тут поподробнее: "а ситуации когда фреймворк есть смысл «подточить» под проект случаются" — к примеру, какие такие ситуации? И что вы под себя меняете?
2) Свои правила не всегда хорошо, благодаря тому, что огромное число разработчиков руководствуются своими правилами язык php и получил такую дурную славу.
3) Следует из пункта два, фреймворк зачастую указывает на правила, как должно писаться приложение и да, эти правила надо учить, если конечно проект рассчитан на то, что его будут видеть другие программисты.
4) Вот это не понятный пункт, а где вам производительности не хватало или что-то тормозило? У меня был опыт делать очень производительное многопоточное приложение на yii1. Средств увеличить производительность куча. Сейчас много работаю с phalcon-ом и да, вижу как люди могут опустить производительность в десятки раз кривым кодом, стиль которого не менялся с времен php4.
5) Тут не знаю, субъективно это.
Ну и еще вопрос от меня, где вы используете этот фреймворк, в профессиональной сфере или для своих проектов? Что это за проект?
Я не ругаю pixie — я его банально не знаю.
Важно: не забываем прописать его в /bundles/app/src/HTTP.php
Важно: не забываем зарегистрировать эти классы в /bundles/app/src/ORM.php
Не забываем прописать их в классе Project\App\Console
В целом, пример не понравился. Сделать тоже самое на любом другом фреймворке — чуть-ли не 1-в-1 кода (возможно в каких-то даже поменьше будет).
Потому что не всегда хочется использовать этот $classMap. Более правильный подход передавать только нужные зависимости а не весь Builder. Тогда можно прописывать свои методы строители.
Пикся старается не привьязывать пользователей к какой-то одной архитектуре.
Более правильный подход передавать только нужные зависимости а не весь Builder.
В чем заключается «более правильность»? Я честно не вижу в этом ни правильности, ни удобства.
Пикся старается не привьязывать пользователей к какой-то одной архитектуре.
Путем создания дополнительной работы? Оно мне надо?
В чем заключается «более правильность»? Я честно не вижу в этом ни правильности, ни удобства.
Dependency Injection vs Service Location
Путем создания дополнительной работы? Оно мне надо?
Зависит уже от вашего уровня. Зачем вам фреймворк совсем? Поставьте Wordpress п программируйте формы мышкой =)
Dependency Injection vs Service Location
Ну да, ну да… Их использование без лишней работы невозможно, правильно я понял?
Зависит уже от вашего уровня. Зачем вам фреймворк совсем? Поставьте Wordpress п программируйте формы мышкой =)
Именно так и сделаю, если потребуется простенький блог, например. А фреймворки использую для других задач. Троллинг, как способ привлечения пользователя — интересный способ, но не действенный. Уж лучше останусь на Phalcon/Zend, в таком случае. Всего доброго.
Я вот не могу понять, для вас прописать строчку в файле это реально лишняя работа? В таком случае вы всегда можете перегрузить 1 метод в 3 строки чтобы сделать поиск классов по папкам и неймспейсам, могу в чате показать как =)
Абсолютно не важно, сколько строк надо добавить — одну или пару сотен. Важен факт того, что это можно (и, имхо, необходимо) автоматизировать. Фреймворки я использую для того, чтобы избавиться от рутинных операций. Думаю, большинство также. В данном случае фреймворк заставляет (и это именно так) думать не про решение задачи, а про использование самого фреймворка.
вы всегда можете перегрузить 1 метод в 3 строки
Да, конечно могу. Как и многое другое. Но, как и любой нормальный программист, я не люблю делать что-то рутинное и не относящееся к решению конкретной задачи. Если для использования какой-то библиотеки или фреймворка мне необходимо делать «лишние» (читайте — не относящиеся к решению задачи) действия — скорее всего библиотека или фреймворк не подходят для текущей задачи.
Далее… Подход, при котором разработчик чуть-ли не в ручную контролирует подключение каждого файла подходит для энтерпрайза, когда каждый дополнительный элемент должен быть одобрен каждым из десятка начальников и только после этого может быть подключен к основному коду. Но «фея» из другой области. Она не может тягаться с симфони или зендом, она для мелких и средне-мелких задач — для них жизнено необходима автоматизация всего, что только возможно. Ни один человек в здравом уме не будет писать блог на микросервисной архитектуре, верно? Так и тут — не надо навязывать принципы из другой области, имхо.
Ну вот как-то так…
Я просто считаю что проще что-то прикрутить в 3 строчки чем потом откручивать =)
Я же не могу за всех угадать кому какая автоматизация надо, кто-то захочет по неймспейсу грузить процессоры, кто-то по папке. А что если папки две или больше итд.
Если бы там много надо было прописывать я бы еще понял, но реально в 3 строчки можно сделать подгрузку по неймспейсу.
Новый быстрый старт с PHPixie: строим цитатник коммит за коммитом