Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 86
Спасибо за статью. Болью в сердце отзывается призыв писать тесты.
Если можно — вопрос: чего начать переход в Symfony 1.4 на Symfony 2? Не в конкретном проекте, а в разработке в целом?
Если можно — вопрос: чего начать переход в Symfony 1.4 на Symfony 2? Не в конкретном проекте, а в разработке в целом?
Попробуйте поработать над связкой twig + controller в одном бандле. Потом сервисы.
Бандл — это аналог плагина в Symfony 1?
Это может быть плагин, а может быть целый сайт.
Какая структура будет более удобная для вас, то и будет :)
Мы дробим на бандлы, но бывает много контроллеров в одном бандле.
Какая структура будет более удобная для вас, то и будет :)
Мы дробим на бандлы, но бывает много контроллеров в одном бандле.
Думаю, воспользуюсь вашим советом, спасибо.
Да, кому как больше нравится. В RadBundle к примеру используется общий неймспейс App rad.knplabs.com/, что как-по мне удобнее для небольших приложений. По идее о правильном распределнии функционала говорит тот факт, что Вы сможете удалить бандл потеряв часть функционала, но не потеряв работосопосбности остальной части приложения. Но у Вас всегда будет какой-нибудь CoreBundle, который Вы не сможете удалить.
Да, в общем-то, сложный вопрос. Я то не знаю, другие Ваши скилы, кроме symfony 1.4 :) Возможно, придется привыкать к неймспейсам или другим особенностям 5.3, 5.4.
Но в любом случае, я бы советовал начать с документации в таком порядке:
1. Qick tour symfony.com/doc/current/quick_tour
2. The book symfony.com/doc/current/book/index.html
3. Cookbook symfony.com/doc/current/cookbook/index.html
Советую также посмотреть скринкасты на knpuniversity.com/ и подписаться на Twitter топ-контрибьютеров Symfony github.com/symfony/symfony/contributors
Но в любом случае, я бы советовал начать с документации в таком порядке:
1. Qick tour symfony.com/doc/current/quick_tour
2. The book symfony.com/doc/current/book/index.html
3. Cookbook symfony.com/doc/current/cookbook/index.html
Советую также посмотреть скринкасты на knpuniversity.com/ и подписаться на Twitter топ-контрибьютеров Symfony github.com/symfony/symfony/contributors
Спасибо за ссылки. До нового года начинал просматривать информацию по Symfony 2, но сессия, прочее не дали. Тогда не было ничего уровня Jobeet для Symfony 1.4 — ничего не изменилось?
Да, Jobeet был великолепен. Что-то настолько же качетсвенно сделанное как Jobeet я не встречал. Есть кое-что, например: ipsum.knplabs.org/, sourceforge.net/p/p5chi-xshare/wiki/Home/ и www.ens.ro/2012/03/21/jobeet-tutorial-with-symfony2/. Но все же я рекомендую читать The book для начала, а потом касты на KnpUniversity но они, к сожалению, за денежку.
Расскажите, пожалуйста, как вы пришли к решению переходить с 1.4 на 2? Есть ли серьезные аргументы в пользу этого перехода (особенно с точки зрения бизнеса, а не разработчика)?
Мне только один небольшой проект довелось переводить с 1.4 на 2. Да и то, это было желание самого заказчика, который, к слову, тоже был программистом.
А если насчет аргументов, то самый серьезный, это то что 1.4 не поддерживается, если не ошибаюсь, примерно с сентября 2012.
А если насчет аргументов, то самый серьезный, это то что 1.4 не поддерживается, если не ошибаюсь, примерно с сентября 2012.
Лично скажу по себе, то стоит задуматься а стоит ли? Symfony1 и Symfony2 не более чем один и тот же бренд и те же разработчики.
Но идеология всего фреймворка Symfony2 совсем иная. Это уже скорее Spring.
Стоит ли менять идеологию веб-разработки — решать вам. Но к симфони1 намного ближе тот же Laravel (основан кстати на симфони компонентах), ну и тем более ближе Rails. Всё конечно зависит от целей и задач, но не делайте из изучения нового языка огромную преграду. Используйте то что удобно и эффективно, а не то что популярно.
Но идеология всего фреймворка Symfony2 совсем иная. Это уже скорее Spring.
Стоит ли менять идеологию веб-разработки — решать вам. Но к симфони1 намного ближе тот же Laravel (основан кстати на симфони компонентах), ну и тем более ближе Rails. Всё конечно зависит от целей и задач, но не делайте из изучения нового языка огромную преграду. Используйте то что удобно и эффективно, а не то что популярно.
Вопрос скорее в преграде при НЕ изучении новых возможностей языка/фреймворка.
В существующем проекте действительно не стоило бы переходить на Symfony2. Если, конечно, бюджет проекта не резиновый или другая какая причина. Просто переход на Symfony2 будет означать, что придется переписать проект с нуля.
Новый проект начинать на Symfony 1.4 не советую.
Новый проект начинать на Symfony 1.4 не советую.
Почему не советуете? Только ли потому что 1.4 не поддерживается?
Нет, не только. В целом, я работал с Symfony 1.4 столько же, сколько работаю с 2. И, скажу, что на Symfony2 можно делать более качественные решения, более быстрые и более легкие в поддержке. И тратить при этом только же вермени, сколько и на symfony 1.4.
Но все же поддержка играет ключевую роль в OSS. OSS это труд многих и многих людей. И представьте, что Все эти люди сейчас не работают над тем, чтобы сделать именно ту технологию, которую вы используете лучше, быстрее, надежнее.
Но все же поддержка играет ключевую роль в OSS. OSS это труд многих и многих людей. И представьте, что Все эти люди сейчас не работают над тем, чтобы сделать именно ту технологию, которую вы используете лучше, быстрее, надежнее.
С документации конечно. Есть 2 базовых статьи — теоретическая: чем sf2 отличается от sf1 ( symfony.com/doc/current/cookbook/symfony1.html ) и практическая: как создать страницу на sf2 (Creating Pages in Symfony2 symfony.com/doc/current/book/page_creation.html ).
После неплохо было бы проштудировать book и хотя бы ознакомиться с содержанием cookbook. Однако на это рассчитывать не приходится )
После неплохо было бы проштудировать book и хотя бы ознакомиться с содержанием cookbook. Однако на это рассчитывать не приходится )
Спасибо, поправлю.
Да, конечно, я имел ввиду критичные исключения. Те, которые могут быть исправлены сразу же, должны быть исправлены сразу же в вызывающем коде. Но в любом случае, не хорошо ловить исключения в контроллере. Критичные исключения будут обработаны на уровень выше, а некритичные не должны дойти до контроллера.
Да, конечно, я имел ввиду критичные исключения. Те, которые могут быть исправлены сразу же, должны быть исправлены сразу же в вызывающем коде. Но в любом случае, не хорошо ловить исключения в контроллере. Критичные исключения будут обработаны на уровень выше, а некритичные не должны дойти до контроллера.
А так плохо?
Контроллер:
Контроллер:
try {
$model->save($user);
echo 'ok. user saved';
} catch (DuplicateEntryException $e) {
echo 'error. user already exists';
}
DuplicateEntryException бросает обертка над PDO (при нарушении unique constraint):class DB {
//constructor, etc
public function query($query) {
try {
$this->pdo->query($query);
} catch (PDOException $e) {
switch ($e->errorInfo[1]) {
case 1062:
throw new DuplicateEntryException($e->getMessage());
//other codes
default:
throw $e;
}
}
}
}
Да, так плохо :)
Что не так? Как бы сделали/делаете Вы?
Ну все зависит от того, что именно Вы хотите сделать. По двум кусочкам кода это не очевидно. Но уж точно, что за сохранение сущности контроллер не должен отвечать.
Собственно, и логику обработки исключения стоит пренести туда, где вы будете сохранять эту сущность. Или же, если выхотите сделать это поведение общим, что более логично, т.к. DuplicateEntryException может быть выброшено и при попытке сохранить другую сущность в БД, Вам было бы лучше перевыбросить исключение другого типа, добавив к нему сообщение, которое вы будете показывать пользователю. Неплохо было бы добавить интерфейс, по-которому вы будете в дальнейшем определять, что нужно вывести в браузер сообщение для пользователя. И это, другое исключение централизованно ловить уже в EventListener symfony.com/doc/2.1/cookbook/service_container/event_listener.html.
Я бы сделал так.
Собственно, и логику обработки исключения стоит пренести туда, где вы будете сохранять эту сущность. Или же, если выхотите сделать это поведение общим, что более логично, т.к. DuplicateEntryException может быть выброшено и при попытке сохранить другую сущность в БД, Вам было бы лучше перевыбросить исключение другого типа, добавив к нему сообщение, которое вы будете показывать пользователю. Неплохо было бы добавить интерфейс, по-которому вы будете в дальнейшем определять, что нужно вывести в браузер сообщение для пользователя. И это, другое исключение централизованно ловить уже в EventListener symfony.com/doc/2.1/cookbook/service_container/event_listener.html.
Я бы сделал так.
Но уж точно, что за сохранение сущности контроллер не должен отвечать.
В последнее время прихожу к тому, что сохраняться как раз все по максимуму должно в контроллерах, а вся остальная логика не должна работать с БД, максимум persist. Т.к. все эти хаотичные flush в сервисах начинают сильно портить жизнь. А написать метод контекста, для выделение абстракции лишь для сохранения сущностей, по мне так слишком большой overhead.
p.s.
Выполнять все в транзакции, для того что бы контролировать стихийные flush — это безусловный костыль, который лишь позволяет разработчику ещё более сильно запутать код.
Совет номер ноль: использовать Symfony только в тех проектах, что вписываются в Symfony'вский «стандарт» по функционалу.
К сожалению, Symfony слишком сложен. Монструозная конфигурация. Монструозное кол-во абстракций (одни только формы чего стоят). Как следствие — крайне трудная отладка, а также обучение новых сотрудников. Написание своих сервисов — тот еще танец с бубном, т.к. документация тут уже слабая.
В одном нашем проекте была чуть более «нестандартная» система авторизации, чем предполагает Symfony Security. После пары дней research'а от Security осталось очень мало, а остальной огромный кусок кода заменился одним, нами написанным, лаконичным сервисом.
В нынешнем проекте система безопасности еще более хитрая и в стандартную Symfony'вскую вообще не вписывается. Ну или вписывается кране слабо. В итоге вся Symfony Security была отключена вообще под ноль. Но проблем доставила другая часть фреймворка — формы.
Резюмируя, напишу так. Если вы понимаете как работает Symfony, как работают его части и почему там именно так все написано, а также плюсы и минусы этих решений, то, если у вас проекты не шаблонные, Symfony можно выкинуть. Причем во многих случаях даже нужно выкинуть. Ибо проще поддерживать, условно, 50 классов + ORM, чем воевать с огромным фреймворком.
К сожалению, Symfony слишком сложен. Монструозная конфигурация. Монструозное кол-во абстракций (одни только формы чего стоят). Как следствие — крайне трудная отладка, а также обучение новых сотрудников. Написание своих сервисов — тот еще танец с бубном, т.к. документация тут уже слабая.
В одном нашем проекте была чуть более «нестандартная» система авторизации, чем предполагает Symfony Security. После пары дней research'а от Security осталось очень мало, а остальной огромный кусок кода заменился одним, нами написанным, лаконичным сервисом.
В нынешнем проекте система безопасности еще более хитрая и в стандартную Symfony'вскую вообще не вписывается. Ну или вписывается кране слабо. В итоге вся Symfony Security была отключена вообще под ноль. Но проблем доставила другая часть фреймворка — формы.
Резюмируя, напишу так. Если вы понимаете как работает Symfony, как работают его части и почему там именно так все написано, а также плюсы и минусы этих решений, то, если у вас проекты не шаблонные, Symfony можно выкинуть. Причем во многих случаях даже нужно выкинуть. Ибо проще поддерживать, условно, 50 классов + ORM, чем воевать с огромным фреймворком.
Это первоапрельская шутка же, да?)
Нет.
Тут я более чем согласен с автором комментария. Если вам нужен не сложный проект, то более чем стоит его создавать на Yiiframework.
Если же хотите писать большой проект на длительный срок поддержки, то выбора у вас нет, нужно смотреть на Symfony 2, даже только лишь потому, что Yii 1 версии уже скоро не будет поддерживаться и развиваться, а остальные framework'ки не выдерживают никакой критики.
p.s.
В нашем проекте мы так же выбросили и формы и авторизацию из Symfony
Тут я более чем согласен с автором комментария. Если вам нужен не сложный проект, то более чем стоит его создавать на Yiiframework.
Если же хотите писать большой проект на длительный срок поддержки, то выбора у вас нет, нужно смотреть на Symfony 2, даже только лишь потому, что Yii 1 версии уже скоро не будет поддерживаться и развиваться, а остальные framework'ки не выдерживают никакой критики.
p.s.
В нашем проекте мы так же выбросили и формы и авторизацию из Symfony
Вопрос выбора платформы — сугубо лчиное. Выбор есть всегда и если Вы делаете свои велосипеды для стандартных компнентов, то используйте лучше Yii ;)
Вы делаете свои велосипеды для стандартных компнентов, то используйте лучше Yii ;)
Что за глупости?
Нет, почему же глупости.
Вам что-то не понравилось в формах, и в секьюрити, Вы взяли этот компонент и выбросили, благо в Symfony это легко сделать.
Я правда считаю, что в таком случае лучше юзать другой фреймворк, Yii я привел только потому что вы о нем говорили.
Вопрос еще на что Вы это заменили. Если на другую более или менее популярную библиотеку, то еще ок. Если же вы свой велосипед сделали, то не ок.
Вам что-то не понравилось в формах, и в секьюрити, Вы взяли этот компонент и выбросили, благо в Symfony это легко сделать.
Я правда считаю, что в таком случае лучше юзать другой фреймворк, Yii я привел только потому что вы о нем говорили.
Вопрос еще на что Вы это заменили. Если на другую более или менее популярную библиотеку, то еще ок. Если же вы свой велосипед сделали, то не ок.
Вам что-то не понравилось в формах
Очень тяжело расширяемый, не предоставляющый необходимых возможностей компонент.
К тому же, почему вы рассматриваете Symfony как обертку над формами?
Я вообще не понимаю ваше отношение к Yii.
В этом framework'е свои компоненты. Можно с равной степенью заявить, как и вы:
и Вы делаете свои велосипеды для стандартных компнентов, то используйте лучше Symfony
Что то мы в Оффтоп ушли, ну да бог с ним :)
Насчет расширяемости не согласен. Но, некоторые вещи мне, конечно и самому не нравятся. Например, то что я должен в форм тайпе решить, как я хочу отрендерить поле.
А насчет возможностей? Просто ради интереса, чего Вам не хватает?
> К тому же, почему вы рассматриваете Symfony как обертку над формами?
Не рассмтариваю, где вы это усмотрели :) Просто концепция форм вписывается в общую концепцию фреймворка. И мне действительно удобно работать с формами в симфони в 95% случаев.
Очень тяжело расширяемый, не предоставляющый необходимых возможностей компонент.
Насчет расширяемости не согласен. Но, некоторые вещи мне, конечно и самому не нравятся. Например, то что я должен в форм тайпе решить, как я хочу отрендерить поле.
А насчет возможностей? Просто ради интереса, чего Вам не хватает?
> К тому же, почему вы рассматриваете Symfony как обертку над формами?
Не рассмтариваю, где вы это усмотрели :) Просто концепция форм вписывается в общую концепцию фреймворка. И мне действительно удобно работать с формами в симфони в 95% случаев.
А насчет возможностей? Просто ради интереса, чего Вам не хватает?
Например поля нет в Entity. Обращение к полямпроисходит через некий Manager сущности.
Ну и ещё 1 usecase:
Внешний вид формы может быть чуть ли не произвольным и задаваться пользователем.
> Например поля нет в Entity. Обращение к полямпроисходит через некий Manager сущности.
Ну такова уж особенность форм, точнее паттерна DataMapper. Вам нужен объект или массив, чтобы забиндить его в форму. И так же вы из формы получаете объект или массив. Потом делайте с ним что хотите. Если у Вас как-то по-другому это работает, nо можно копнуть глубже и посмотреть как компонент устроен внутри. Скорее всего вы решите задачу используя события. Возможно Вы сможете решить задачу используя symfony.com/doc/current/reference/forms/types/form.html#property-path
> Внешний вид формы может быть чуть ли не произвольным и задаваться пользователем.
Вот тут вообще проблемы не вижу :) Вплоть до того, что пользователи сами будут шаблоны для форм и полей делать.
Ну такова уж особенность форм, точнее паттерна DataMapper. Вам нужен объект или массив, чтобы забиндить его в форму. И так же вы из формы получаете объект или массив. Потом делайте с ним что хотите. Если у Вас как-то по-другому это работает, nо можно копнуть глубже и посмотреть как компонент устроен внутри. Скорее всего вы решите задачу используя события. Возможно Вы сможете решить задачу используя symfony.com/doc/current/reference/forms/types/form.html#property-path
> Внешний вид формы может быть чуть ли не произвольным и задаваться пользователем.
Вот тут вообще проблемы не вижу :) Вплоть до того, что пользователи сами будут шаблоны для форм и полей делать.
можно копнуть глубже и посмотреть как компонент устроен внутри
слишком сложно, гораздо проще делать так:
example.html.twig:
{{ widget($field) }}
И людей проще этому обучить(на два порядка), и отлаживать на много удобнее.
Вот тут вообще проблемы не вижу :) Вплоть до того, что пользователи сами будут шаблоны для форм и полей делать.
Наверное я не правильно объяснил. Суть в том, что бы пользователь работал с WYSIWYG, со вставкой служебных конструкций для определения полей.
слишком сложно, гораздо проще делать так:
ну а {{ form_widget(form) }} Вам чем не так? Вообще мы говорили о маппинге данных в поля формы или как?
Суть в том, что бы пользователь работал с WYSIWYG, со вставкой служебных конструкций для определения полей.
Ну а я о чем, берете сырые данные из WYSIWYG сохраняете, чтобы их отредактировать позже можно было. Обрабатываете служебные конструкции, чтобы получить параметры (переменные, которые потом используете), делаете себе Twig шаблон. Переменные сетите во вью формы. Или вы не то же самое делаете? Возможно, у Вас есть прослойка, которая служебную информацию сразу в html рендерит. Ну так разницы никакой, кто за рендеринг отвечает.
ну а {{ form_widget(form) }} Вам чем не так? Вообще мы говорили о маппинге данных в поля формы или как?
То что внутрь передается некий form, который нужно описывать до потери сознания, а внутри я ещё и ограничен чем только можно.
Ну а я о чем, берете сырые данные из WYSIWYG сохраняете, чтобы их отредактировать позже можно было. Обрабатываете служебные конструкции, чтобы получить параметры
Что-то я почти ничего не понял, что вы предлагаете. Можно больше деталей?
Как подсунуть нужны шаблон для Symfony Forms?
Как маппить конкретное поле в конкретный form_widget?
Как в сложные виджеты передать список возможных значений для конкретного поля?
Я всё это вообще не представляю в данной концепции.
Я всех Ваших требований не знаю, но на вопросы Ваши отвечу.
Механизм шаблонов очень простой он использует имя формы для определения шаблона. Также Вы можете использовать темы. Т.к. для форм используется паттерн Composite, вы можете иметь сколько угодно тем как для конкретного поля, так и для форм в общем.
Можно определять форм тайпы, можно билдить формы динамически, как Вам больше нравится.
Если речь идет о селектах, то через опции. Так же можно сетить переменные во view непосредственно.
Как подсунуть нужны шаблон для Symfony Forms?
Механизм шаблонов очень простой он использует имя формы для определения шаблона. Также Вы можете использовать темы. Т.к. для форм используется паттерн Composite, вы можете иметь сколько угодно тем как для конкретного поля, так и для форм в общем.
Как маппить конкретное поле в конкретный form_widget?
Можно определять форм тайпы, можно билдить формы динамически, как Вам больше нравится.
Как в сложные виджеты передать список возможных значений для конкретного поля?
Если речь идет о селектах, то через опции. Так же можно сетить переменные во view непосредственно.
А разве нельзя переопределить шаблоны форм/функцию для вызова форм?
Отлично, что делать когда вам никто не дает денег на парк серверов, а нагрузки предвидятся нехилые такие? Можете сами замерить сколько Symfony жрет памяти на один запрос. И сколько минимум времени надо на выполнения кода простенького контроллера без запросов в базу.
Вот не получается у меня что-то с формами. Я лезу в доку, проверяю, что все норм, а все равно не работает. Лезу в гугл, экспериментирую с кодом, но все равно не работает. Открываю дебагер, а там просто нереальное кол-во абстракций.
У контроллеров есть метод getUser(). Отлично, а где этот юзер присваивается? А как изменить этот? А будет ли это очевидно?
По поводу «легко что-то отключить». Попробуйте отключить security, а потом создать свой SecurityBundle. Вас ждет неприятный сюрприз, т.к. Symfony будет думать что в системе есть *стандартный* extension «security». Ок, лезем в наш класс SecurityBundle\DependencyInjection\SecurityExtension, переопределяем метод getAlias(). Теперь начинает падать класс SecurityBundle\SecurityBundle, т.к. там идет проверка alias'а (нафига???).
Зачем-то поля формы можно задавать классом. Ок, а почему через аннотации можно указывать параметры валидации, а вот какие именно виджеты для каждого поля выводить — нет? Есть 3rd-party bundle, видел, да. Только вот меня он не устроил.
Почему html5 validation, в частности атрибут pattern не подставляется автоматом, когда указываешь в списке валидаторов Regex? Да, код в Symfony для этого есть, только вот не работает.
Почему когда я делаю бандл с namespace'ом аля Organisation\Department\SomeBundle, то resource locator'ы перестают искать шаблоны по строке что-то типа «SomeBundle:controller:view», когда делаешь все в точности по официальной доке? Привет часик с дебагером.
Как уже мною упоминалось выше, программирование валидации настроек бандлов — это вообще треш.
И таких мелких и не очень минусов там огромное кол-во. Проблема в том, что мы не штампуем по 5 сайтов за месяц. У нас проекты меньше полугода не длятся. И несмотря на то, что штат сотрудников огромный, PHPшников мало (я и сам одновременно на java пишу). А знакомых с Symfony вообще почти нет. И что делать, когда на проект с Symfony приходит менее компетентный коллега, который далеко не факт, что сможет продраться с дебагером под мышкой через эту кучу кода? Что, он меня дергать будет non-stop?
Что вам такого дает Symfony на крупных проектах, чтобы его так защищать? Модульность? Простоту тестирования? Так ничто не мешает написать слабосвязанный код и без Symfony. ServiceConainer'ер хочется? Так не вопрос, за адекватное время спокойно пишется свой, пусть и куда менее функциональный, но так этого и не надо. Вполне можно обойтись суперглобальными массивами, а не плодить обертки типа Request. И читабельность кода не пострадает. И т.д. «Идеальная архитектура», «100% покрытие тестами», «быстрое и легкое внесение изменений» — это лишь мифы. Да, к этим целям надо стремиться, но никогда не стоит забывать что серебряной пули не существует и всегда лучше сдать проект в срок, чем пытаться сделать супер-пупер код.
Стоит добавить, что подобные рассуждения применимы не везде и не всегда. У вас относительно краткосрочные или шаблонные проекты? Куча PHPшников в фирме, которые *уже* Symfony знают? Не хватает квалификации чтобы без фреймворка написать слабосвязанный код? Тогда, да, юзаем Symfony и не паримся.
Так что, если резюмировать, то отказываться от Symfony так сразу я не предлагаю. Но и думать, что данный фреймворк — серебряная пуля тоже не надо. При выборе технологии всегда голову включать надо.
Возможно, в будущем мнение изменится на противоположное. А, может, ситуация, например, на рынке труда изменится. Но на данном этапе моей карьеры мне видится ситуация вот так.
ЗЫ: Да, я знаю о синдроме «not invented here». Не во всех случаях, к сожалению, его упоминание будет к месту.
Вот не получается у меня что-то с формами. Я лезу в доку, проверяю, что все норм, а все равно не работает. Лезу в гугл, экспериментирую с кодом, но все равно не работает. Открываю дебагер, а там просто нереальное кол-во абстракций.
У контроллеров есть метод getUser(). Отлично, а где этот юзер присваивается? А как изменить этот? А будет ли это очевидно?
По поводу «легко что-то отключить». Попробуйте отключить security, а потом создать свой SecurityBundle. Вас ждет неприятный сюрприз, т.к. Symfony будет думать что в системе есть *стандартный* extension «security». Ок, лезем в наш класс SecurityBundle\DependencyInjection\SecurityExtension, переопределяем метод getAlias(). Теперь начинает падать класс SecurityBundle\SecurityBundle, т.к. там идет проверка alias'а (нафига???).
Зачем-то поля формы можно задавать классом. Ок, а почему через аннотации можно указывать параметры валидации, а вот какие именно виджеты для каждого поля выводить — нет? Есть 3rd-party bundle, видел, да. Только вот меня он не устроил.
Почему html5 validation, в частности атрибут pattern не подставляется автоматом, когда указываешь в списке валидаторов Regex? Да, код в Symfony для этого есть, только вот не работает.
Почему когда я делаю бандл с namespace'ом аля Organisation\Department\SomeBundle, то resource locator'ы перестают искать шаблоны по строке что-то типа «SomeBundle:controller:view», когда делаешь все в точности по официальной доке? Привет часик с дебагером.
Как уже мною упоминалось выше, программирование валидации настроек бандлов — это вообще треш.
И таких мелких и не очень минусов там огромное кол-во. Проблема в том, что мы не штампуем по 5 сайтов за месяц. У нас проекты меньше полугода не длятся. И несмотря на то, что штат сотрудников огромный, PHPшников мало (я и сам одновременно на java пишу). А знакомых с Symfony вообще почти нет. И что делать, когда на проект с Symfony приходит менее компетентный коллега, который далеко не факт, что сможет продраться с дебагером под мышкой через эту кучу кода? Что, он меня дергать будет non-stop?
Что вам такого дает Symfony на крупных проектах, чтобы его так защищать? Модульность? Простоту тестирования? Так ничто не мешает написать слабосвязанный код и без Symfony. ServiceConainer'ер хочется? Так не вопрос, за адекватное время спокойно пишется свой, пусть и куда менее функциональный, но так этого и не надо. Вполне можно обойтись суперглобальными массивами, а не плодить обертки типа Request. И читабельность кода не пострадает. И т.д. «Идеальная архитектура», «100% покрытие тестами», «быстрое и легкое внесение изменений» — это лишь мифы. Да, к этим целям надо стремиться, но никогда не стоит забывать что серебряной пули не существует и всегда лучше сдать проект в срок, чем пытаться сделать супер-пупер код.
Стоит добавить, что подобные рассуждения применимы не везде и не всегда. У вас относительно краткосрочные или шаблонные проекты? Куча PHPшников в фирме, которые *уже* Symfony знают? Не хватает квалификации чтобы без фреймворка написать слабосвязанный код? Тогда, да, юзаем Symfony и не паримся.
Так что, если резюмировать, то отказываться от Symfony так сразу я не предлагаю. Но и думать, что данный фреймворк — серебряная пуля тоже не надо. При выборе технологии всегда голову включать надо.
Возможно, в будущем мнение изменится на противоположное. А, может, ситуация, например, на рынке труда изменится. Но на данном этапе моей карьеры мне видится ситуация вот так.
ЗЫ: Да, я знаю о синдроме «not invented here». Не во всех случаях, к сожалению, его упоминание будет к месту.
Отлично, что делать когда вам никто не дает денег на парк серверов, а нагрузки предвидятся нехилые такие?Писать на Erlang. Разве кто-то утверждает, что sf2 создан для хайлоада?
Проблема в том, что мы не штампуем по 5 сайтов за месяц.Проблема в том, что вы выбрали инструмент, который вам не подходит. Как вообще выбор пал на sf2, если у вас в штате мало php-разработчиков, знакомых с ним?
У вас относительно краткосрочные или шаблонные проекты?Зачем тут sf2? Для шаблонных проектов существуют CMS и специально обученные люди.
Не хватает квалификации чтобы без фреймворка написать слабосвязанный код?Не хватает. Не каждый коллектив разработчиков являет собой лигу выдающихся джентльменов.
Да и новых сотрудников искать проще, указывая в требованиях к кандидату опыт работы с конкретным фреймворком.
Так что, если резюмировать, то отказываться от Symfony так сразу я не предлагаю. Но и думать, что данный фреймворк — серебряная пуля тоже не надо. При выборе технологии всегда голову включать надо.Точно. Только я так и не понял, откуда следует, что отказываться от sf2 вообще надо.
Ваш комментарий чуть менее, чем полностью, состоит из демагогии, с помощью которой можно раскритиковать всё что угодно.
> Писать на Erlang. Разве кто-то утверждает, что sf2 создан для хайлоада?
Отлично, а Erlang так много народу знает? Или заказчик возьмет и радостно оплатит обучение команды, по вашему? Я-то только за, только вот одного моего желания мало. Бывают чисто объективные причины в виде бюджета и сроков или недостатка сотрудников, а бывают и политические.
Я как-то привык сначала код писать, а потом только с профайлером его оптимизировать. Конечно, выбор адекватных алгоритмов еще на этапе написания никто не отменял. Так вот в случае с Symfony очень тяжело понять что с ним можно сделать в плане оптимизации, несмотря на то, что там куча всего в PHP код кешируется и bytecode кешер включен.
> Проблема в том, что вы выбрали инструмент, который вам не подходит. Как вообще выбор пал на sf2, если у вас в штате мало php-разработчиков, знакомых с ним?
Инструмент на *этот* проект, согласен, выбрали неверно. Это моя ошибка. Но проблема не в кол-ве сотрудников, а в том, что конкретно этот фреймворк слишком сложен. Вопрос в том, обосновано ли он такой сложный. Имхо, нет.
> Зачем тут sf2? Для шаблонных проектов существуют CMS и специально обученные люди.
А что делать с проектами, для которых CMS не подходит, а фреймворк хочется, чтобы самим кучу кода не писать? 90% сайтов — это простейший уровень в плане программирования. Так почему тогда фреймворк для этого простейшего уровня должен быть таким монструозным?
> Не хватает. Не каждый коллектив разработчиков являет собой лигу выдающихся джентльменов.
Так нужен хотя бы один или пара действительно сильных на проект, чтобы написать ядро, а рутинную работу можно и более младшим сотрудникам поручить. В чем проблема-то? Совершенно классический расклад.
> Да и новых сотрудников искать проще, указывая в требованиях к кандидату опыт работы с конкретным фреймворком.
Новых сотрудников искать проще? Да еще и конкретный фреймворк указывая? Да ладно? Вы в курсе о ситуации на рынке труда сейчас? Мы два месяца искали одного PHP'шника! И это без указания конкретного фреймворка!
На всякий случай, о конторе. Когда я год назад менял работу, то предложений было очень много и я имел возможность сам выбирать работодателя. Так так контора у нас вполне нормальная. Былая адекватная зарплата, которая всегда выплачивается срок, разные плюшки типа ДМС. Возможность самим выбирать технологии на проект и даже менять язык разработки. Сказать что контора слабая и не способна привлечь хотя бы средних спецов явно нельзя. А вот, тем не менее, два месяца поисков.
Впрочем, похожая ситуация сейчас и в других фирмах — интересовался.
> Ваш комментарий чуть менее, чем полностью, состоит из демагогии, с помощью которой можно раскритиковать всё что угодно.
Вы можете воспринимать мой комментарий как угодно. Я просто описал мой опыт и взгляд на текущую ситуацию с Symfony.
Возможно, я не прав, но у меня сложилось впечатление, что вы меряете людей по себе. Меня от этого, к счастью отучили, хотя и непросто это было.
Отлично, а Erlang так много народу знает? Или заказчик возьмет и радостно оплатит обучение команды, по вашему? Я-то только за, только вот одного моего желания мало. Бывают чисто объективные причины в виде бюджета и сроков или недостатка сотрудников, а бывают и политические.
Я как-то привык сначала код писать, а потом только с профайлером его оптимизировать. Конечно, выбор адекватных алгоритмов еще на этапе написания никто не отменял. Так вот в случае с Symfony очень тяжело понять что с ним можно сделать в плане оптимизации, несмотря на то, что там куча всего в PHP код кешируется и bytecode кешер включен.
> Проблема в том, что вы выбрали инструмент, который вам не подходит. Как вообще выбор пал на sf2, если у вас в штате мало php-разработчиков, знакомых с ним?
Инструмент на *этот* проект, согласен, выбрали неверно. Это моя ошибка. Но проблема не в кол-ве сотрудников, а в том, что конкретно этот фреймворк слишком сложен. Вопрос в том, обосновано ли он такой сложный. Имхо, нет.
> Зачем тут sf2? Для шаблонных проектов существуют CMS и специально обученные люди.
А что делать с проектами, для которых CMS не подходит, а фреймворк хочется, чтобы самим кучу кода не писать? 90% сайтов — это простейший уровень в плане программирования. Так почему тогда фреймворк для этого простейшего уровня должен быть таким монструозным?
> Не хватает. Не каждый коллектив разработчиков являет собой лигу выдающихся джентльменов.
Так нужен хотя бы один или пара действительно сильных на проект, чтобы написать ядро, а рутинную работу можно и более младшим сотрудникам поручить. В чем проблема-то? Совершенно классический расклад.
> Да и новых сотрудников искать проще, указывая в требованиях к кандидату опыт работы с конкретным фреймворком.
Новых сотрудников искать проще? Да еще и конкретный фреймворк указывая? Да ладно? Вы в курсе о ситуации на рынке труда сейчас? Мы два месяца искали одного PHP'шника! И это без указания конкретного фреймворка!
На всякий случай, о конторе. Когда я год назад менял работу, то предложений было очень много и я имел возможность сам выбирать работодателя. Так так контора у нас вполне нормальная. Былая адекватная зарплата, которая всегда выплачивается срок, разные плюшки типа ДМС. Возможность самим выбирать технологии на проект и даже менять язык разработки. Сказать что контора слабая и не способна привлечь хотя бы средних спецов явно нельзя. А вот, тем не менее, два месяца поисков.
Впрочем, похожая ситуация сейчас и в других фирмах — интересовался.
> Ваш комментарий чуть менее, чем полностью, состоит из демагогии, с помощью которой можно раскритиковать всё что угодно.
Вы можете воспринимать мой комментарий как угодно. Я просто описал мой опыт и взгляд на текущую ситуацию с Symfony.
Возможно, я не прав, но у меня сложилось впечатление, что вы меряете людей по себе. Меня от этого, к счастью отучили, хотя и непросто это было.
Отлично, а Erlang так много народу знает?Я утрировал, говоря об Erlang. Почему бы не разрабатывать на Java?
Или заказчик возьмет и радостно оплатит обучение команды, по вашему?Symfony2 тоже требует некоторого обучения, однако, вас это не остановило.
Я как-то привык сначала код писать, а потом только с профайлером его оптимизировать. Конечно, выбор адекватных алгоритмов еще на этапе написания никто не отменял.Избыточная оптимизация алгоритмов — это экономия на спичках, в случае интерпретируемых языков c динамической типизацией. Я склоняюсь к тому, что код должен быть, в первую очередь, читаемым и легко поддерживаемым. Вы можете спокойно спать, зная, что элемент массива, содержащий целое число, в php занимает 144 байта? Я вот могу. И при этом не говорю, что php плохой язык.
Но проблема не в кол-ве сотрудников, а в том, что конкретно этот фреймворк слишком сложен.Я и не говорил, что проблема в количестве сотрудников, я сказал, что вы выбрали не тот фреймворк, а возможно, и язык. В мире php не так часто встречаются паттерны сложнее синглтона, а sf2, как вы справедливо заметили, состоит из одних абстракций — но ведь это всё ради удобства разработки. Программистам, впервые видящим все эти фабрики и контейнеры, остаётся только впасть в академический транс — думаю, в этом виноват не только фреймворк.
90% сайтов — это простейший уровень в плане программирования. Так почему тогда фреймворк для этого простейшего уровня должен быть таким монструозным?Почему вы решили, что sf2 — фреймворк для этого простейшего уровня?
Так нужен хотя бы один или пара действительно сильных на проект, чтобы написать ядро, а рутинную работу можно и более младшим сотрудникам поручить. В чем проблема-то? Совершенно классический расклад.Вы предлагаете писать индивидуальный каркас для каждого приложения, чтобы избежать использования фреймворков? Я понимаю, бывают ситуации, когда такой подход оправдан. Но разве это повод не использовать фреймворки в остальных случаях?
Мы два месяца искали одного PHP'шника! И это без указания конкретного фреймворка!Вы искали иголку в стоге сена, вместо того, чтобы явно указать необходимые навыки. Я лишь это хотел сказать. Ситуация на рынке — это тоже не вина фреймворка.
Возможно, я не прав, но у меня сложилось впечатление, что вы меряете людей по себе. Меня от этого, к счастью отучили, хотя и непросто это было.Возможно, вы правы, но я честно стараюсь быть объективным.
> Я утрировал, говоря об Erlang. Почему бы не разрабатывать на Java?
К сожалению, жависты крайне плохо дружат с вебом, а, особенно, с клиентской стороной. Был как раз выбор между Java и PHP. По разным причинам выбрали PHP, хотя, возможно, мы и пожалеем об этом выборе.
> Symfony2 тоже требует некоторого обучения, однако, вас это не остановило.
Тем не менее, чтобы писать что-то, не уходящее особо за рамки tutorial'ала, много времени на обучение на надо. Когда полезли глубже, стало понятно что попали.
> Избыточная оптимизация алгоритмов — это экономия на спичках, в случае интерпретируемых языков c динамической типизацией. Я склоняюсь к тому, что код должен быть, в первую очередь, читаемым и легко поддерживаемым. Вы можете спокойно спать, зная, что элемент массива, содержащий целое число, в php занимает 144 байта? Я вот могу.
Под фразой «выбор адекватных алгоритмов еще на этапе написания» понимались только совсем очевидные случаи, типа индексы в базе расставить. Это если утрированно. В целом же, придерживаюсь такого же подхода.
> И при этом не говорю, что php плохой язык.
У меня о PHP по сравнению с той же Java резко негативное мнение, но чтобы не разводить срач, ограничусь просто этой фразой.
> Почему вы решили, что sf2 — фреймворк для этого простейшего уровня?
Исходя из документации и статей типа этой, когда все преподносится таким простым. Кроме того, был некий опыт уже с Symfony и относительно удачный. Но, да, это решение было ошибочным.
> Вы предлагаете писать индивидуальный каркас для каждого приложения, чтобы избежать использования фреймворков? Я понимаю, бывают ситуации, когда такой подход оправдан. Но разве это повод не использовать фреймворки в остальных случаях?
Я предлагаю прежде всего думать головой. И банально не надеется что Symfony или иной другой фреймворк решит все проблемы. Если очень упростить, то предлагаю 10 раз подумать о выборе конкретного фреймворка, если разрабатываемый функционал выходит за рамки его tutorial'а.
> Вы искали иголку в стоге сена, вместо того, чтобы явно указать необходимые навыки. Я лишь это хотел сказать. Ситуация на рынке — это тоже не вина фреймворка.
Тут, возможно, вы правы.
К сожалению, жависты крайне плохо дружат с вебом, а, особенно, с клиентской стороной. Был как раз выбор между Java и PHP. По разным причинам выбрали PHP, хотя, возможно, мы и пожалеем об этом выборе.
> Symfony2 тоже требует некоторого обучения, однако, вас это не остановило.
Тем не менее, чтобы писать что-то, не уходящее особо за рамки tutorial'ала, много времени на обучение на надо. Когда полезли глубже, стало понятно что попали.
> Избыточная оптимизация алгоритмов — это экономия на спичках, в случае интерпретируемых языков c динамической типизацией. Я склоняюсь к тому, что код должен быть, в первую очередь, читаемым и легко поддерживаемым. Вы можете спокойно спать, зная, что элемент массива, содержащий целое число, в php занимает 144 байта? Я вот могу.
Под фразой «выбор адекватных алгоритмов еще на этапе написания» понимались только совсем очевидные случаи, типа индексы в базе расставить. Это если утрированно. В целом же, придерживаюсь такого же подхода.
> И при этом не говорю, что php плохой язык.
У меня о PHP по сравнению с той же Java резко негативное мнение, но чтобы не разводить срач, ограничусь просто этой фразой.
> Почему вы решили, что sf2 — фреймворк для этого простейшего уровня?
Исходя из документации и статей типа этой, когда все преподносится таким простым. Кроме того, был некий опыт уже с Symfony и относительно удачный. Но, да, это решение было ошибочным.
> Вы предлагаете писать индивидуальный каркас для каждого приложения, чтобы избежать использования фреймворков? Я понимаю, бывают ситуации, когда такой подход оправдан. Но разве это повод не использовать фреймворки в остальных случаях?
Я предлагаю прежде всего думать головой. И банально не надеется что Symfony или иной другой фреймворк решит все проблемы. Если очень упростить, то предлагаю 10 раз подумать о выборе конкретного фреймворка, если разрабатываемый функционал выходит за рамки его tutorial'а.
> Вы искали иголку в стоге сена, вместо того, чтобы явно указать необходимые навыки. Я лишь это хотел сказать. Ситуация на рынке — это тоже не вина фреймворка.
Тут, возможно, вы правы.
Не лень же Вам было коммент писать :) Вы поймите меня правильно, я вовсе не идеализирую фреймворк. И вовсе не делаю по пять проектов в месяц. И цель моя не холивары холиварить, а помочь людям, тем кто хочет на этом фреймворке делать приложения :)
Юзер берется из токена в секьюрити контексте. Попадает он туда в процесса аутентификации. Изменить можно создав свой провайдер аутентификации.
Простите, у меня всего один вопрос к Вам. Понимаете ли вы почему глобальные переменные, это зло? :)
У контроллеров есть метод getUser(). Отлично, а где этот юзер присваивается? А как изменить этот? А будет ли это очевидно?
Юзер берется из токена в секьюрити контексте. Попадает он туда в процесса аутентификации. Изменить можно создав свой провайдер аутентификации.
Вполне можно обойтись суперглобальными массивами, а не плодить обертки типа Request.
Простите, у меня всего один вопрос к Вам. Понимаете ли вы почему глобальные переменные, это зло? :)
В большинстве случаев создание web-приложений подразумевает «стандартный» функционал.
Symfony не сложен, но, да согласен, у него высокий порог вхождения. И да, секьюрити и формы самые сложные компоненты.
Да, много абстракицй. Но много из них являются фундаментальными и они хороши.
Резюмируя, скажу. Если вы любите минимализм, то не юзайте ORM. Это не тру. Как и не тру «изобретать велосипеды», это не Symfony way :)
Symfony не сложен, но, да согласен, у него высокий порог вхождения. И да, секьюрити и формы самые сложные компоненты.
Да, много абстракицй. Но много из них являются фундаментальными и они хороши.
Резюмируя, скажу. Если вы любите минимализм, то не юзайте ORM. Это не тру. Как и не тру «изобретать велосипеды», это не Symfony way :)
Symfony не сложен, но, да согласен, у него высокий порог вхождения.
Вы уж определитесь.
Под высоким порогом вхождения я понимаю уровень знаний разработчика в общем, необходимый для начала работы. Под сложностью, время которое нужно потратить разработчику на изучение фреймворка, если он этими знаниями обладает.
Для меня, высокий порог вхождения в framework и есть его сложность. Я никак не могу представить что «уровень знаний разработчика» есть «порог вхождения». Даже Русский язык против составления такого предложения.
p.s.
На мой взгляд, Symfony действительно сложен. По сравнению с ним, для меня, Yii изучается чуть ли не более чем целиком за 2 дня.
p.s.
На мой взгляд, Symfony действительно сложен. По сравнению с ним, для меня, Yii изучается чуть ли не более чем целиком за 2 дня.
«Порог» и «уровень» синонимы. В отличи от «сложность» и «порог», которые не имеют ничего общего.
Все паттерны и методы решения определенных задач, применяемые в Symfony2, существовали задолго до его появления.
Если специалист с ними раньше работал, то освоить фреймворк не должно составить труда.
Если специалист с ними раньше работал, то освоить фреймворк не должно составить труда.
Спасибо, Inori :) Именно это и имел ввиду.
Ох, как я Вас понимаю! Так было сложно без админ генератора первый месяц и казалось, что к Twig'у никогда не привыкну.
— Меня зовут Андрей и я 4 месяца разрабатываю на Symfony2. До этого все пилил свой CMS.
Я вот быстро привык к twig'у. Когда первый раз увидел его в документации symfony2, то сразу понял, что хочу шаблоны делать именно на нем. Да еще и с PHPStorm — идеально… Разобрался с DI, MVC использовал и в своем CMS, проблемы с переполнением памяти при работе с dotrine исправил, меняя свой код, а вот с формами проблема. Вот сейчас не могу понять, как правильно сделать форму, количество полей в которой может меняться на стороне клиента…
Я вот быстро привык к twig'у. Когда первый раз увидел его в документации symfony2, то сразу понял, что хочу шаблоны делать именно на нем. Да еще и с PHPStorm — идеально… Разобрался с DI, MVC использовал и в своем CMS, проблемы с переполнением памяти при работе с dotrine исправил, меняя свой код, а вот с формами проблема. Вот сейчас не могу понять, как правильно сделать форму, количество полей в которой может меняться на стороне клиента…
Меня зовут Андрей и я 4 месяца разрабатываю на Symfony2
Прям клуб анонимных Симфонистов какой-то :)
Вот сейчас не могу понять, как правильно сделать форму, количество полей в которой может меняться на стороне клиента.
Если Вы имеете ввиду коллекции, symfony.com/doc/master/reference/forms/types/collection.html то вся магия вот в этом классе github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Extension/Core/EventListener/ResizeFormListener.php.
Если есть какие-то конкретные вопросы. Спрашивайте, я помогу.
Если есть какие-то конкретные вопросы. Спрашивайте, я помогу.
Сделать бы нормальный форум анонимных симфонистов, а то все что я видел(рускоязычные) заброшены, или там два-три человека
Более менее живой форум анонимных симфонистов :)
Артем, отличная статья! :) Еще я кажется знаю, с какого проекта приполз абзац об интерфейсах ;)
Спасибо за статью! Я только начал изучать этот фреймворк и у меня есть один насущный вопрос. Как сделать расширяемую форму? То есть у формы есть какая-то статическая часть + динамическая, например название компании, адрес и описание — статическая, сотрудники — динамическая. На клиенте JSом добавляются поля, но как-то обработать без костылей стандартными средствами фреймворка можно?
Судя по всему Вам нужно использовать FormType Collection symfony.com/doc/current/reference/forms/types/collection.html. У него есть специальный элемент, prottotype. Вы можете рендерить prototype где-нибудь на странице, а потом вставлять этот prototype через JS в форму сделав замену $$name$$ на уникальное значение.
Более частный случай, если у Вас есть полиморфная сущность. Например у Вас несколько типов сотрудников с разными полями и Вы хотите иместь возможность выбрать какую форму Вам нужно вставить на страницу (например, выбирая нужный элемент из бутсраповского dropdown-button). Тогда Вам не подойдет стандартный Collection и нужно будет сделать свой FormType и добавить к нему небольшой Listener.
Более частный случай, если у Вас есть полиморфная сущность. Например у Вас несколько типов сотрудников с разными полями и Вы хотите иместь возможность выбрать какую форму Вам нужно вставить на страницу (например, выбирая нужный элемент из бутсраповского dropdown-button). Тогда Вам не подойдет стандартный Collection и нужно будет сделать свой FormType и добавить к нему небольшой Listener.
Используй стабильные версии бандлов, если есть такая возможность. А если нет, то обновляй зависимости как можно чаще. Ошибки лучше всего исправлять по мере их появления. Когда ты насобираешь много обновлений, то и устранить все проблемы несовместимости, будет намного сложнее.
Недавно пытался собрать Symfony из стабильных пакетов.
— Невозможно
Сколько уже проекту лет, а все равно используешь dev пакеты — позор.
Так версии бандла определяется разработчиком бандла. Сам фреймворк выпускает стабильные версии.
Хм, а так не? github.com/symfony/symfony-standard/blob/master/composer.json
Я имелл ввиду, что есть 3-d party bundles. Для которых нет еще стабильных версий. Их то и нужно обновлять почаще.
Я имелл ввиду, что есть 3-d party bundles. Для которых нет еще стабильных версий. Их то и нужно обновлять почаще.
{ ...
"minimum-stability": "stable",
}
и не соберется, скорее всего :)
Я имелл ввиду, что есть 3-d party bundles. Для которых нет еще стабильных версий. Их то и нужно обновлять почаще.
Да мы как бы даже не собераемся 3d party bundles использовать, лишь все от SensioLabs. Но собрать stable до сих пор нет возможности. Вот этим я сильно раздосадован. Что за prodaction на dev решениях?
Да, как бы соберется :) Вы бы проверяли информацию, перед тем, как высказываться :)
Проверил, не собралось.
Problem 3
— symfony/assetic-bundle v2.1.2 requires kriswallsmith/assetic 1.1.* -> no matching package found.
— symfony/assetic-bundle v2.1.1 requires kriswallsmith/assetic 1.1.* -> no matching package found.
— symfony/assetic-bundle v2.1.0 requires kriswallsmith/assetic 1.1.* -> no matching package found.
— Installation request for symfony/assetic-bundle 2.1.* -> satisfiable by symfony/assetic-bundle v2.1.0, symfony/assetic-bundle v2.1.1, symfony/assetic-bundle v2.1.2.
Да, вы правы. AsseticBundle использует нестабильную версию assetic. Сработает install с стабильностью dev, потом меняем стабильность на stable и делаем update. Собственно, как я и проверил в первый раз.
Впрочем, если для Вас важно, чтобы у Вас в конфиге было stable. То юзайте 2.1:
Впрочем, если для Вас важно, чтобы у Вас в конфиге было stable. То юзайте 2.1:
2.1 соберется
{
"name": "symfony/framework-standard-edition",
"description": "The \"Symfony Standard Edition\" distribution",
"autoload": {
"psr-0": { "": "src/" }
},
"require": {
"php": ">=5.3.3",
"symfony/symfony": "2.1.*",
"doctrine/orm": ">=2.2.3,<2.5-dev",
"doctrine/doctrine-bundle": "1.1.*",
"twig/extensions": "1.0.*@dev",
"symfony/assetic-bundle": "2.1.*",
"symfony/swiftmailer-bundle": "2.1.*",
"symfony/monolog-bundle": "2.1.*",
"sensio/distribution-bundle": "2.1.*",
"sensio/framework-extra-bundle": "2.1.*",
"sensio/generator-bundle": "2.1.*",
"jms/security-extra-bundle": "1.2.*",
"jms/di-extra-bundle": "1.1.*",
"kriswallsmith/assetic": "1.1.*@dev"
},
"scripts": {
"post-install-cmd": [
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile"
],
"post-update-cmd": [
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile"
]
},
"extra": {
"symfony-app-dir": "app",
"symfony-web-dir": "web",
"branch-alias": {
"dev-master": "2.1-dev"
}
}
}
{
"kriswallsmith/assetic": "1.1.*@dev"
}
Не смущает, ну ладно…
Только не надо утверждать что это @stable. Там явно тянется последний commit master branch.
И это ладно мы рассматриваем bundle в стандартной поставке. А если взять хотя бы doctrine/doctrine-migrations-bundle то вообще пиши пропало. \dev на \dev и \dev погоняет
Ну вообще, в стандартной поставке идет и composer.lock файл. Который гарантирует, что выполучите не последнюю версию из мастера, а ту с которой симфони гарантированно работает. Но, если же Вам непременно нужно определнный стабильный тэг, Вы можете сделать так.
В данном случае composer update не приведет к обновлению версии assetic. Тоже самое касается и миграций и всех остальных бандлов. Эта хорошая практика, когда вы в репозитории храните composer.lock. Впрочем и сам composer тоже в альфе до сих пор. Но как-то, привыкли уже с этим жить :) На продакшене устанавливаете через composer install. Если хотите обновиться делаете локально composer update. Прогоняете тесты, все ок – комититесь, не ок – исправляете несовместимости и комититесь. Все просто :)
{
"kriswallsmith/assetic": "1.1.0-alpha4"
}
В данном случае composer update не приведет к обновлению версии assetic. Тоже самое касается и миграций и всех остальных бандлов. Эта хорошая практика, когда вы в репозитории храните composer.lock. Впрочем и сам composer тоже в альфе до сих пор. Но как-то, привыкли уже с этим жить :) На продакшене устанавливаете через composer install. Если хотите обновиться делаете локально composer update. Прогоняете тесты, все ок – комититесь, не ок – исправляете несовместимости и комититесь. Все просто :)
Еще вопрос по консоли. Очень удобная штука, возможно такое восхищение от того что это первый фреймворк.
Подскажите есть ли обертки вокруг консоли, позволяющие постоянно в ней работать, кроме SensioLabs Desktop?
У меня есть свой велосипед, но он не очень прост и много чего не умеет делать, на пример запоминать историю и выводить по нажатию кнопки вверх.
Подскажите есть ли обертки вокруг консоли, позволяющие постоянно в ней работать, кроме SensioLabs Desktop?
У меня есть свой велосипед, но он не очень прост и много чего не умеет делать, на пример запоминать историю и выводить по нажатию кнопки вверх.
Сам велосипед
#include <iostream>
#include <string>
using namespace std;
int main()
{
string path, command, full;
cout<<"Console path: ";
cin>>path;
path = "php " + path + " ";
while(true){
cout<<"Command: ";
cin>>command;
full = path + command;
system(full.c_str());
}
}
С тех пор, как я влюбился в Assetic и консоль, даже небольшие проекты делаю на Symfony2.
После начала работы с symfony2 подготовил парочку скриптов на питоне. Один делает мне новый проект с готовой стандартной структурой, другой обновляет выбранный проект в продакшен на сервере (с очисткой кеша и т.п.).
В целом все нравится. Единственное, что смущает, это скорость разработки. С одной стороны много всего готового, а с другой в своем, скажем так, «устаревшем фрэймворке» мне приходилось писать гораздо меньше, чтобы сделать какую-нибудь новую логику с таблицами, сущностями и т.п. И пока что в голове еще не сложилось, как достичь той же скорости.
Есть вопрос.
Я делаю в сервисах бизнес-логику, которая работает с сущностями. Получаю я EntityManager через контейнер. Раз это плохой стиль, то какое решение? Хотя бы если doctrine передавать в конструктор — это нормальный стиль? Или как лучше в сервисе работать с сущностями тогда?
В целом все нравится. Единственное, что смущает, это скорость разработки. С одной стороны много всего готового, а с другой в своем, скажем так, «устаревшем фрэймворке» мне приходилось писать гораздо меньше, чтобы сделать какую-нибудь новую логику с таблицами, сущностями и т.п. И пока что в голове еще не сложилось, как достичь той же скорости.
Есть вопрос.
Не делай сервисы зависимые от контейнера
Я делаю в сервисах бизнес-логику, которая работает с сущностями. Получаю я EntityManager через контейнер. Раз это плохой стиль, то какое решение? Хотя бы если doctrine передавать в конструктор — это нормальный стиль? Или как лучше в сервисе работать с сущностями тогда?
Да, Doctrine уже лучше. Еще лучше, если только EntityManager (doctrine.orm.default_entity_manager). Т.е. только то, что Вам реально необходимо.
Просто если у Вас будет контейнер в Сревисе, вы не будете правильно определять зависимости класса, а будете дергать все из контейнера. Это потом протестировать, продебажить, отрефакторить очень тяжело.
Позвольте также дать пару советов по сервисам:
1. Используйте yaml для конфигурации, он гораздо легче читается.
2. Не нужно делать праметров для класса сервиса, как в документации. Эти параметры нужны, чтобы можно было подменить класс в 3dparty бандле, если нужно его заоверрайдить. В своем проекте вы всегда можете это сделать ручками, но читабельность конфига повысится.
3. Используйте команду php app/console container:debug (можно сокращать до cont:de) + grep, чтобы найти нужный сервис.
4. Делайте класс, пишите не него тесты. И только потом, конфигурируйте его как сервис в контейнере.
5. Делайте приватными те сервисы, которые нужны только как засисмости для других сервисов. Т.е. если вы не дергаете нигде сервис из контроллера, но используете только как засимость для другого сервиса.
Просто если у Вас будет контейнер в Сревисе, вы не будете правильно определять зависимости класса, а будете дергать все из контейнера. Это потом протестировать, продебажить, отрефакторить очень тяжело.
Позвольте также дать пару советов по сервисам:
1. Используйте yaml для конфигурации, он гораздо легче читается.
2. Не нужно делать праметров для класса сервиса, как в документации. Эти параметры нужны, чтобы можно было подменить класс в 3dparty бандле, если нужно его заоверрайдить. В своем проекте вы всегда можете это сделать ручками, но читабельность конфига повысится.
3. Используйте команду php app/console container:debug (можно сокращать до cont:de) + grep, чтобы найти нужный сервис.
4. Делайте класс, пишите не него тесты. И только потом, конфигурируйте его как сервис в контейнере.
5. Делайте приватными те сервисы, которые нужны только как засисмости для других сервисов. Т.е. если вы не дергаете нигде сервис из контроллера, но используете только как засимость для другого сервиса.
Вот все великолепно в статье… Ох с примерами бы еще по каждому из пунктов, цены бы не было. Можно было смело распечатывать и с собой носить. Тем не менее огромное спасибо за статью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Каким бы я хотел видеть свой первый проект на Symfony