Гугление вряд ли бы помогло.
Первый комит шаблонизатора: 12 Sep 2010
Первый комит фреймворка: 20 Sep 2010
Ну и сомневаюсь, что кто-то захочет подключать шаблонизатор на Ruby к фреймворку на php
К примеру если по коду надо найти строку function. Если просто набрать, то в выборке будет много function, которые относятся к описанию функций. Т.о. проще искать 'function, но, т.к. вариантов кавычек может быть два, надо не забыть поискать и по "function
От to*() функций ожидаешь, что они любой треш преобразуют в соответствующий тип. Поэтому возвращение null мне кажется странным. Теряется смысл этих функций, потому что придется каждый раз дополнительно делать проверку на null. Тогда уж кидать TypeError, по аналогии с https://wiki.php.net/rfc/consistent_type_errors
Там теперь достаточно подключить профиль к GitHub и дать соответствующие права. Если
вы авторизовались через GitHub давно, как я, то надо просто разлогиниться и войти снова, тогда вам предложат доставить разрешения. После этого все библиотеки будут обновляться автоматически
Я к тому, что зачем обновлять зависимости на сервере?
Во-первых, вы можете нарваться на обновление, которое поломает приложение. Подразумевается обновление зависимостей на машине разработчика, коммит composer.lock и уже выполнение composer install на сервере. Т.о. вендоры будут идентичными.
Во-вторых, это может отожрать много памяти, что даже ini_set("memory_limit", -1); не поможет, т.к. ее не хватит физически (мы же все-таки о бесплатном хостинге говорим)
Note: This feature has severe technical limitations, as the composer.json metadata will still be read from the branch name you specify before the hash. You should therefore only use this as a temporary solution during development to remediate transient issues, until you can switch to tagged releases. The Composer team does not actively support this feature and will not accept bug reports related to it.
Отчасти это послужило «пинком под зад» в расстановке semver-тегов для своих внутренних компонтентов
Прототип он в том смысле, что обычно для продакшена после этих действий нужны всякие мелкие доработки — валидация, интерфейс, дополнительные действия в логике.
Если потом придет задача, к примеру:
раскрашивать строку таблицы цветом в зависимости от статуса заказа
выводить не таблицей, а списком
какие-то даты выводить в формате php:Y-m-d, какие-то в intl:yyyy-MMMM-dd
...
Не проще в таком случае выкинуть виджет и сделать все обычным foreach?
Да, вижу, что у него много опций и, скорее всего, они покрывают все юзкейсы, но в итоге получается все такой же "километровый конфиг".
Ну я бы не назвал это «немного») Сколько здесь вручную написанных функций и классов, да еще и магические аннотации. Это ведь все код, который надо поддерживать. И сколько неявного кода надо учитывать, который выполняется «где-то там».
Не так много:
OrderController — и там и там он был частично сгенерирован
Сущности — и там и там, только у вас migration-first, у меня наоборот, создаются модели, а миграции генерируются
Модель для поиска — и там и там (да, у вас она сгенерировалась, но по факту код был полностью изменен и добавлены те же публичные поля, что и у меня)
Форма для поиска — и там и там (только у меня через класс, у вас через шаблон)
Логика поиска — у меня в репозитории, у вас в модели (по количеству кода — ± одинаково)
Забавно, что в итоге "кода, который нужно поддерживать"
(git ls-tree -r master --name-only | wc -l)
в Symfony — 63 файлов
в Yii — 173
да еще и магические аннотации
Тоже так думал вначале, но сейчас понимаю, что это очень удобно, тем более что поддержка аннотаций в PhpStorm есть
Пример
За счет того, аннотации находятся рядом с кодом, который они конфигурируют,
получается меньше переключений контекста: не надо переходить в другой файл, чтобы описать то или иное правило.
За счет высокой связанности в Yii 2 такого нет, посмотрим что будет в третьей версии, когда код разобьют на компоненты.
Challenge accepted =) Получилось, немного посложнее, чем у вас, но надо сказать, что это уже не прототип, а вполне себе рабочий вариант.
При этом не заметил каких-то ограничений, которые накладывает Doctrine
Хотелось бы увидеть код. Основной вопрос: как быть с условиями? К примеру, если валидация прошла успешно, то создаем пользователя и редиректим на страницу просмотра, если нет — то рендерим форму с ошибками. В ваших примерах все линейно: 'UserModel > UserViewModel > view, hello'
тем более, что они автоматом ставятся в любой проект, который использует Symfony 4
Речь идет о новых проектах, использующих flex. Если кто-то обновил свое приложение с 3.4 до 4 и захочет поставить ваш бандл, он очень не обрадуется появившемуся flex, который внезапно переопределит все конфиги :)
а вот sensio/framework-extra-bundle тут действительно нужен. Он необходим для роутинга через аннотации.
Не рекомендуется использовать такого рода "магию" в бандлах. Равно как и использование автовайринга и автоконфигрирования: Best Practices for Reusable Bundles
Services should not use autowiring or autoconfiguration. Instead, all services should be defined explicitly.
Раздел с созданием скелета бандла — спорный. Гораздо проще использовать стандартный composer init, т.к. в вашем случае удалить придется гораздо больше, чем создать. К тому же вы добавляете лишние зависимости (по сути бандл должен зависеть только от symfony/framework-bundle, как минимум symfony/flex, sensio/framework-extra-bundle и symfony/lts — лишние)
Ну а в остальном создание ничем не отличается от других версий Symfony
Основная проблема — dev-зависимости на проде. В случае, если используется assetic, придется ставить java, для webpack — node.js.
Мы эту проблему решили в рамках `Capistrano`
task :webpack_build do
run_locally do
execute "./node_modules/.bin/encore production"
end
end
и
task :upload do
release_path = fetch(:release_path)
web_path = fetch(:web_path)
on roles(:web) do
execute :mkdir, "-pv", "#{release_path}/#{web_path}/build"
upload! "#{web_path}/build", "#{release_path}/#{web_path}", :recursive => true
end
end
Гугление вряд ли бы помогло.
Первый комит шаблонизатора:
12 Sep 2010
Первый комит фреймворка:
20 Sep 2010
Ну и сомневаюсь, что кто-то захочет подключать шаблонизатор на Ruby к фреймворку на php
К примеру если по коду надо найти строку
function
. Если просто набрать, то в выборке будет многоfunction
, которые относятся к описанию функций. Т.о. проще искать'function
, но, т.к. вариантов кавычек может быть два, надо не забыть поискать и по"function
Вам нужен
tagged cache
:https://laravel.com/docs/5.8/cache#storing-tagged-cache-items
https://symfony.com/blog/new-in-symfony-3-2-tagged-cache
От
to*()
функций ожидаешь, что они любой треш преобразуют в соответствующий тип. Поэтому возвращениеnull
мне кажется странным. Теряется смысл этих функций, потому что придется каждый раз дополнительно делать проверку наnull
. Тогда уж кидатьTypeError
, по аналогии с https://wiki.php.net/rfc/consistent_type_errorsТам теперь достаточно подключить профиль к GitHub и дать соответствующие права. Если
вы авторизовались через GitHub давно, как я, то надо просто разлогиниться и войти снова, тогда вам предложат доставить разрешения. После этого все библиотеки будут обновляться автоматически
Я к тому, что зачем обновлять зависимости на сервере?
Во-первых, вы можете нарваться на обновление, которое поломает приложение. Подразумевается обновление зависимостей на машине разработчика, коммит
composer.lock
и уже выполнениеcomposer install
на сервере. Т.о. вендоры будут идентичными.Во-вторых, это может отожрать много памяти, что даже
ini_set("memory_limit", -1);
не поможет, т.к. ее не хватит физически (мы же все-таки о бесплатном хостинге говорим)А зачем на хостинге запускать
composer update
?Отчасти это послужило «пинком под зад» в расстановке semver-тегов для своих внутренних компонтентов
Если потом придет задача, к примеру:
Не проще в таком случае выкинуть виджет и сделать все обычным
foreach
?Да, вижу, что у него много опций и, скорее всего, они покрывают все юзкейсы, но в итоге получается все такой же "километровый конфиг".
Не так много:
OrderController
— и там и там он был частично сгенерированСущности
— и там и там, только у вас migration-first, у меня наоборот, создаются модели, а миграции генерируютсяМодель для поиска
— и там и там (да, у вас она сгенерировалась, но по факту код был полностью изменен и добавлены те же публичные поля, что и у меня)Форма для поиска
— и там и там (только у меня через класс, у вас через шаблон)Логика поиска
— у меня в репозитории, у вас в модели (по количеству кода — ± одинаково)Забавно, что в итоге "кода, который нужно поддерживать"
(
git ls-tree -r master --name-only | wc -l
)в Symfony — 63 файлов
в Yii — 173
Тоже так думал вначале, но сейчас понимаю, что это очень удобно, тем более что поддержка аннотаций в PhpStorm есть
За счет того, аннотации находятся рядом с кодом, который они конфигурируют,
получается меньше переключений контекста: не надо переходить в другой файл, чтобы описать то или иное правило.
За счет высокой связанности в Yii 2 такого нет, посмотрим что будет в третьей версии, когда код разобьют на компоненты.
Получилось, немного посложнее, чем у вас, но надо сказать, что это уже не прототип, а вполне себе рабочий вариант.
При этом не заметил каких-то ограничений, которые накладывает Doctrine
Не эксперт в прототипировании, но мне кажется плюс-минус одинаково?
Хотелось бы увидеть код. Основной вопрос: как быть с условиями? К примеру, если валидация прошла успешно, то создаем пользователя и редиректим на страницу просмотра, если нет — то рендерим форму с ошибками. В ваших примерах все линейно:
'UserModel > UserViewModel > view, hello'
Речь идет о новых проектах, использующих
flex
. Если кто-то обновил свое приложение с3.4
до4
и захочет поставить ваш бандл, он очень не обрадуется появившемусяflex
, который внезапно переопределит все конфиги :)Не рекомендуется использовать такого рода "магию" в бандлах. Равно как и использование автовайринга и автоконфигрирования: Best Practices for Reusable Bundles
Раздел с созданием скелета бандла — спорный. Гораздо проще использовать стандартный
composer init
, т.к. в вашем случае удалить придется гораздо больше, чем создать. К тому же вы добавляете лишние зависимости (по сути бандл должен зависеть только отsymfony/framework-bundle
, как минимумsymfony/flex
,sensio/framework-extra-bundle
иsymfony/lts
— лишние)Ну а в остальном создание ничем не отличается от других версий Symfony
А можете пример привести? По-моему конечного пользователя все эти абстракции не касаются
А ответ на самую интересную часть так и не дали:
Как передавать зависимости, которые необходимы для обработки зависимостей, которые, в случае передачи уже сконфигурированных данных не нужны?
Основная проблема — dev-зависимости на проде. В случае, если используется
assetic
, придется ставитьjava
, дляwebpack
—node.js
.и