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 — я его банально не знаю.
Потому что не всегда хочется использовать этот $classMap. Более правильный подход передавать только нужные зависимости а не весь Builder. Тогда можно прописывать свои методы строители.
Пикся старается не привьязывать пользователей к какой-то одной архитектуре.
В чем заключается «более правильность»? Я честно не вижу в этом ни правильности, ни удобства.
Dependency Injection vs Service Location
Путем создания дополнительной работы? Оно мне надо?
Зависит уже от вашего уровня. Зачем вам фреймворк совсем? Поставьте Wordpress п программируйте формы мышкой =)
Я вот не могу понять, для вас прописать строчку в файле это реально лишняя работа? В таком случае вы всегда можете перегрузить 1 метод в 3 строки чтобы сделать поиск классов по папкам и неймспейсам, могу в чате показать как =)
Я просто считаю что проще что-то прикрутить в 3 строчки чем потом откручивать =)
Я же не могу за всех угадать кому какая автоматизация надо, кто-то захочет по неймспейсу грузить процессоры, кто-то по папке. А что если папки две или больше итд.
Если бы там много надо было прописывать я бы еще понял, но реально в 3 строчки можно сделать подгрузку по неймспейсу.
Новый быстрый старт с PHPixie: строим цитатник коммит за коммитом