посмотри в vendor/composer/autoload_psr4.php

посмотри в vendor/composer/autoload_psr4.php

не - тут нету

ну то есть есть если я делаю как на последнем скрине

ё9

ну то есть есть если я делаю как на последнем скрине

ты через composer install ставил свой пакет?

или просто закинул в папку с vendor?

ты через composer install ставил свой пакет?

конечно

он ставится

нормально подключается к репу - клонирует его и т.п.

даже несмотря на то что доступ по ssh-ключу

я думал с этим основной гемор может быть... а сел с автолоадером:(

не юзай merge. никогда

а почему? чем это вредно?

https://github.com/Limenius/symfony-react-sandbox#server-side-rendering-modes наткнулся на такой вариант

когда симфони отдает ноде часть рендеринга и забирает потом обратно

не знаю, как там сейчас дела, но полгода назад было сыро

совсем плохо?

а зачем?

рендеринг же

можно же реакт поднять с каким нить nats и кидать ему мессаги на рендеринг если симфа на фронте

а разница?

нативный рендер нодой

а не v8 php exteension

когда симфони отдает ноде часть рендеринга и забирает потом обратно

оно ж так и делает

v8 php медленный до безумия

в прод его они и рекомендуют

It is recommended to have V8Js installed, but you may want to have it installed in production and still be able to use PhpExecJs calling node as a subprocess during development

я еще поиграюсь с бенчмарками

Using an external node.js server (Example). It will use a dummy server, that knows nothing about your logic to render React for you. This is faster but introduces more operational complexity (you have to keep the node server running). For this reason it is more suited for production.

2 years ago)

хз напиши если потестишь интересно

просто поднимать целый фронтэнд на ноде это как-то слишком будет

учитывая что у нас щас твиг

а вы какие то куски твигом а какие то нодой хотите?

сейчас вообще рендерится почти все на твиге, а потом подхватывает фронт бекбоном

хотим полностью реактом рендерить

Помогите, плиз, не могу понять этот пример :( Как здесь получают метод getReadComments, если $user не является объектом класса User https://puu.sh/xTaFM/01ce17d512.png

Почему ты считаешь, что "$user не является объектом класса User" ?

Потому что здесь не было объявленно что $user является объектом класса User

А если указать new User, то обязательно надо делать persist, а это уже не то :(

Щито?

что по-твоему делает find?

Это да, но я все равно не могу связаться через find с этим классом

https://puu.sh/xTbau/12b6cc329d.png

исключение всё тебе сообщило... твоя переменная где ты дёргаешь comment() равно null

без кода можно только гадать

https://puu.sh/xTbeJ/fde8bd153d.png

$this->cooment?

https://puu.sh/xTbg0/78a3c1c49c.png

тебе даже IDE говорит что ты выдумываешь

$post->addComment($comment) обычно

Ах да ><

Очень туплю, спасибо

но всеравно :(

ну значит в БД нет поста с таким id. сделай dump($post);die;

посмотри что выведет

вангую что Null

и вообще, в симфонях есть отличная штука под названием ParamConverter. можно убрать $post = ... и поставить function comment(Post $id, Request $request) и дальше по коду у тебя уже будет объект Post, при условии что он существует... либо симфони вернёт 404

записи в бд нет с таким id

но она есть(

Пофиксил слаг, айди нашелся, комменты записываются, но post_id : NULL ><

доктрина меня сломала...( Пойду спать...

хз напиши если потестишь интересно

особо бенчмарки не гонял, взял чисто тот пример. рендерит он конечно нереально быстро через внешний сервер

ERROR: S client not available

мне аж понравился этот вариант

@fes0r вон глянь если интересно

он процесс ноды поднимает для этого? или всегда запущен?

ноду самому контролировать нужно, супервизорами или нодовой тулзой

https://habrahabr.ru/company/zfort/blog/339630/ Свежий PHP Дайджест подоспел

Всем привет. Такой вопрос возник. Например страница, состоящая из различных блоков. Виджеты там всякие. Нормально ли делать виджеты в виде отдельных экшенов и вызавать их из шаблонов? Просто до этого только api шки писал)

Всем привет. Такой вопрос возник. Например страница, состоящая из различных блоков. Виджеты там всякие. Нормально ли делать виджеты в виде отдельных экшенов и вызавать их из шаблонов? Просто до этого только api шки писал)

а переиспользование есть? можно вынести в отдельные шаблоны, миксины и т.п. Вызов отдельного экшена создает большой оверхэд и полезен например для esi.

Можно макрос написать, можно twig extension

Ну а если эти блоки у тебя только в лайоуте, то смысла нет

а переиспользование есть? можно вынести в отдельные шаблоны, миксины и т.п. Вызов отдельного экшена создает большой оверхэд и полезен например для esi.

Переиспользование есть. Ну да тот же сайдбар со всякими там последними материалами и т.д

а переиспользование есть? можно вынести в отдельные шаблоны, миксины и т.п. Вызов отдельного экшена создает большой оверхэд и полезен например для esi.

Что подразумеваешь под миксинами?

Что подразумеваешь под миксинами?

use вроде в твиге, примеси. Но вообще сайдбар проще всего просто в промежутночном layout шаблоне сделать

Что подразумеваешь под миксинами?

Хмм. Чет я подумал. Можно отдельно создавать компоненты, как сервисы, инжектить туда то что нужно (репозитории, сервисы) и отдавать отрендеренный результат

а код вызывать например из твиг экстеншена самописного.

ну вот это оно и есть

пишется экстеншен, там свои функции которые доступны в шаблонах. Это очень сильно дешевле чем "подзапрос" делать через контроллер

пишется экстеншен, там свои функции которые доступны в шаблонах. Это очень сильно дешевле чем "подзапрос" делать через контроллер

Спасибо за ответ)

Переиспользование есть. Ну да тот же сайдбар со всякими там последними материалами и т.д

эм не, надо делать субзапросы для такого

<div id="sidebar"> {{ render(controller( 'AppBundle:Article:recentArticles', { 'max': 3 } )) }} </div>

типа такого

https://symfony.com/doc/current/templating/embedding_controllers.html

https://symfony.com/doc/current/templating/embedding_controllers.html

Так это и есть подзапрос

Так это и есть подзапрос

Я уже после того как задал вопрос вспомнил, что раньше делал это через отдельные twig расширения, в которые инжектил через констурктор необходимые для виджета зависимости

если у вас в слушателях нет проверки на субзапросы, тогда встраивать контроллеры будет медленнее

если у вас в слушателях нет проверки на субзапросы, тогда встраивать контроллеры будет медленнее

Я не улавливаю, что ты хочешь донести? Зачем мне вешать слушатели на контроллеры, которые нужны только для вывода виджета и никогда не будут выводиться отдельно, если я могу создать просто сервис, который делает то что мне нужно?

Я не улавливаю, что ты хочешь донести? Зачем мне вешать слушатели на контроллеры, которые нужны только для вывода виджета и никогда не будут выводиться отдельно, если я могу создать просто сервис, который делает то что мне нужно?

слушатели в симфони идут общие на все контроллеры, и не важно они делают только вывод или вообще ничего не делают

сервис будет рендерить твиг?

сервис будет рендерить твиг?

Почему нет, если он нужен только для вывода виджета. Делать контроллер ради этого не вижу смысла. UI компонент. Не вижу в этом ничего плохого

Почему нет, если он нужен только для вывода виджета. Делать контроллер ради этого не вижу смысла. UI компонент. Не вижу в этом ничего плохого

тогда можно в и твиге делать запросы к базе, чего уж там

тогда можно в и твиге делать запросы к базе, чего уж там

Хмм. У меня UI компонент имеет лишь один метод, который возвращает то что нужно. Запросы к базе скрыты в репо, который инжектися внуть компонента. Что-тут не так? Ну то есть UI комонент можно рассматривать как invokable action

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

как вы у себя будете делать - мне как-то пофигу)