Comments 56
public function newAction(Request $request)
{
$post = new Post();
$form = $this->createForm(PostType::class, $post);
// ...
}код взят с http://symfony.com/doc/current/best_practices/forms.html
which is recommended as your form becomes reusable.
(PostType::class, $post);
Вся форма на самом деле задается внутри PostType.
Конструкцию
$this->redirect($this->generateUrl('BloggerBlogBundle_contact'));
лучше заменить на
$this->redirectToRoute('BloggerBlogBundle_contact');
, а проверку
$request->getMethod() == 'POST'лучше заменить на
$request->isMethod($request::METHOD_POST)
http://blog.kpitv.net/article/frameworks-1/
Кто не считает, можете тоже сходит.
Статья изменит вашу точку зрения на фреймворки.
Нас е**т, а мы крепчаем— это про вас.
Вас минусуют за пиар своей статьи, а вы все равно вставляете ссылку на нее в каждом посте, который как-то связан с веб-разработкой.
А из-за того, что у людей когнитивный диссонанс, они не могут понять, как можно обойтись без фреймворков.
Минусуют и комменты без ссылок.
А ссылку я вставляю только в постах, связанных с фремворками.
Задевает постоянный постинг ссылки на эту статью. Такое ощущение, что вы навязываете свою идеологию, причем выходит не убедительно. Или я ошибаюсь?
Те, кто их уже использует, вряд ли перестянет.
Просто фреймворки приподносятся как некая панацея, но это не так. Там говнокода тоже тонны.
Хотя как пристанище говнокодеров (хотя там есть и нормальные программисты) фреймворки выполняют свою роль отлично.
Я против пропаганды фреймворков среди неокрепших умов.
Я навязываю идеологию KISS. :)
А что именно неубедительно? :)
Но реалии бизнеса таковы, что, как правило:
- Стартовать нужно в сжатые сроки, а иногда даже вчера. Всем пофиг что вы уже полгода пишете крутое ядро. Бизнесу нужен результат.
- Нужны некие стандарты и документация, дабы любой разработчик быстро сориентировался в проекте
Это как минимум. Со всем этим фреймворки справляются неплохо, при этом позволяют поддерживать код в поддерживаемом состоянии.
Раз уж вы заговорили о принципе KISS, то одним из его важных составляющих является сохранение методов/классов маленькими и простыми. Этого я не увидел в коде, который показал нам MetaDone
А что именно неубедительно? :)
Неубедительны приводимые вами аргументы. Большая часть из них очень субъективны, некоторые просто высосаны из пальца.
Например:
При выпуске новых версий как правило отсутствует обратная совместимость. Программисты на фреймворках никогда не останутся без работы.
Большинство серьезных фреймворков используют семантическое версионирование. А значит пользователь должен понимать, что выпуск мажорной версии не гарантирует обратную совместимость.
Некоторые фреймворки ориентированы на аннотации (комментарии) — это тихий ужас.
А мне нравятся аннотации. Очень удобно, например, описать роут рядом с обработчиком(экшеном). Субъективно? Да.
Зачем брать фреймворк и мудохаться с ним, если можно взять CMS?
>Всем пофиг что вы уже полгода пишете крутое ядро.
Подразумевается, что ядро не пишется под каждый проект, а имеется уже наработанное и просто переносится с одного проекта на другой.
>Бизнесу нужен результат.
Бизнесом, как правило, управляют те еще стратеги. :)
>Нужны некие стандарты и документация, дабы любой разработчик быстро сориентировался в проекте
Мои 50 КБ можно изучить за день :)
Стандарты должны быть логичными. Если стандартов слишком много и они не логичны — на них всем начхать.
KISS.
Это кусок контроллера.
Я не вижу смысла разбивать функцию на мелкие функции, если не будет повторного использования.
Зачем плодить абстрации?
>семантическое версионирование
Какая разница, какое версионирование?
Вон Битриксы все совместимы.
>А мне нравятся аннотации.
Аннотации могут нравиться, но это путанье мух с котлетами по факту. )
Зачем брать фреймворк и мудохаться с ним, если можно взять CMS?
А cms же у нас конфетка, точно.
Подразумевается, что ядро не пишется под каждый проект, а имеется уже наработанное и просто переносится с одного проекта на другой.
А пишете вы его дома в свободное время?
Мои 50 КБ можно изучить за день
Ну действительно, зачем документация нужна.
Я не вижу смысла разбивать функцию на мелкие функции, если не будет повторного использования.
Например, чтобы не читать весь код, а увидеть суть. Тесты написать проще, не? Никто вас не просит кучу абстракций накладывать. Не нужно в крайности бросаться. Использовать абстракции нужно, но к месту и умеренно.
Вон Битриксы все совместимы.
Вон Вася спился. Давай и я тоже сопьюсь.
Аннотации могут нравиться, но это путанье мух с котлетами по факту. )
Вы считаете что аннотации — ужас. Я считаю, что это удобно. Получается, что ваше мнение субъективно, верно? Субъективно — значит применимо к одному субъекту.
А Вы сапожник без сапог? :)
>Ну действительно, зачем документация нужна.
А я и не говорю, что не нужна :)
>чтобы не читать весь код, а увидеть суть
Большинство ИДЕ имеет сворачивание кода.
>Вон Вася спился. Давай и я тоже сопьюсь.
Я ж приводил позитивный пример.
>Субъективно
При чем тут субъективно — не субъективно? Это мешание в кучу мух и котлет.
1. Это пока ноу-хау.
2. Я не хочу распространять код, если он будет труднообновляем. Нужно будет завернуть все в композитор, или как. У меня проблем с обновлениями моих сайтов пока нет, поэтому руки не доходят. :)
3. Я бы еще хотел как-то заработать на этом коде. :) Скорее всего не прямо. Возможно что-то вроде расширенной версии, как у нгинкса. :) В композиторе можно использовать сторонние репозитории с ключем доступа?
4. Как решают проблему конфликта классов сущностей другие? То есть какое-то расширение поставляет с собой какие-то сущности. Как обойти конфликты? Пользовательские сущности выносить в неймспейсы?
5. Перед выпуском в паблик стоило бы подчистить немного легаси код, там пару методов ядра.
6. Нужно написать документацию.
7. Я не знаю, как систему встретят, будут ли пользоваться. Если не будут, то смысла как бы и нет выкладывать. :)
Они как китайские молотки, как бренды-пустышки (слышал, у Бугатти днище гниет за 2 года :) ). :)
Почему берут фрейворки? Чтобы быстрее (якобы еще дешевле) состряпать продукт.
В результате выходит черти что.
Использовать фреймворк — это использовать кувалду, где нужен средний молоток.
2. Каждый раз собирать молоток не нужно при грамотном подходе. Можно, конечно, мудохаться и в самописи, каждый раз переизобретая ранее собой же изобретенный велосипед, но это тупо.
А из-за того, что у людей когнитивный диссонанс, они не могут понять, как можно обойтись без фреймворков.
Мы как-то дискутировали с вами, и выяснилось что у вас просто далеко не те проекты, где нужны фреймворки уровня симфони. "бложики" на симфони писать как-то сильно оверхэд.
А вот опыта с проектами того уровня, где фреймворки спасают у вас попросту видимо нет. Так что ваше мнение не заслуживает внимания.
Какие у вас есть такие проекты?
Давайте я просто расскажу как у меня происходят отношения с фреймворками, библиотеками и т.д. на примере сферического в вакууме проекта, а потом обсудим все же что именно вам не нравится (в конце):
предположим у меня начинается очередной проект, допустим это автоматизация процессов продаж каких-нибудь сопутствующих товаров где-нибудь.
Бизнес-аналитики накидывают мне юзкейсы/юзерстори (или менеджеры, или я сам их накидываю себе в виду фичаспек по результатам обсуждения), из которых формируется представление о том как что делается. Например краиугольным камнем нашего продукта являются платежи.
Что я делаю, я пишу на PHP (никаких фреймворков пока) сущности, примерно как у нас вышло при декомпозиции задачи. Причем только в рамках той фичи которую я сейчас делаю. Частенько я делаю это дело по TDD. Если мне нужна какая-то функциональность вроде "послать email со счетом" я не бросаю все и пишу очередной мэйлер, а просто делаю интерфейс штуки, которая будет для меня это все делать.
В результате через пару-тройку часов у меня есть вся бизнес логика этой фичи. Как только она готова, и я покрыл тестами все интересующие меня моменты, можно браться за инфраструктуру. Прикручивать базы данных (доктрина, она полностью абстрагирует меня от слоя хранения данных, очень быстро подобные штуки пилить), писать контроллеры для HTTP API (симфони, по сути только то что нужно для http, никаких форм, только валидация запросов + реквесты/респоны, обработка ошибок), реализую сервисы для отправки нотификаций (какие-то библиотеки поставленные через composer + реализация интерфейса который я написал как заглушку для тестов).
Нужно прикрутить авторизацию? пара десятков минут и у меня уже прикручена авторизация через JWT. Нужно сделать запись всех запросов — не проблема, ставим бандл, 15 минут и готово. Нужно гибко управлять правами — symfony/security предоставляет механизм воутеров, с которыми я могу описать даже ооочень сложную логику разграничения прав на раз-два.
Любая стандартная задача — меньше часа с учетом чтения доки и "сходить за кофе". Если внезапно приходит хотелка от клиента "ну мы хотим сделать меганестандартную аутентификацию через 10 разных сервисов" — оке, просто делаю свою реализацию аутентификатора реализующего стандартный интерфейс, предоставляемый мне symfony. Он достаточно гибкий что бы сделать практически все что угодно. А даже если внезапно по каким-то причинам его будет не хватать — не вопрос, делаем полностью свою систему аутентификации сверху нашего приложения, симфони предоставляет мне и такую возможность.
Если мы бложики пишем — симфони скорости разработки нам не добавит в сравнении с фреймворками вроде laravel или просто plain php + composer пакеты. А вот если мы интернет магазин пилим — то существенно ускоряется как написание MVP проекта, так и сопровождение значительно дешевеет.
НО!
Все это хорошо работает потому что я с Symfony и Doctrine работаю уже почти 5 лет, знаю их на очень хорошем уровне изнутри. Так же я стараюсь писать код так, что бы он небыл слишком сильно завязан на фреймворк (инверсия зависимости и все такое). Это происходит естественным образом поскольку я начинаю проектировать систему с бизнес логики а не контроллеров.
А подавляющая масса новичков начинает делать дела с фреймворками даже не прочитав документацию к фреймворку. А ведь если все делать методом тыка — то эффективности фреймворки при разработке не добавляют. То есть что бы фреймворки приносили пользу, их нужно знать хотя бы на базовом уровне. В случае Symfony нужно знать хотя бы те компоненты, которые вы используете повседневно (в моем случае это 5-6 компонентов на самом деле из десятков). То есть нам нужно инвестировать свое время в изучение инструмента что бы его использование начиинало окупаться.
Если без этого… разницы как бы нет, с фреймворком или нет — скорее всего получится неподдерживаемый трэшачек.
не изменит
Нет, автор Вы, и стесняетесь признаваться
И оно легко для понимания, в отличии от фрейморков.
Содержит всего 50Кб.
У меня используются нативные функции языка, а не так, что каждый фреймворк по сути является новым языком.
А пишущие на фреймворках не умеют самостоятельно строить архитектуру.
Также не мое ядро дергает пользовательский код, а пользовательский код дергает ядро.
2. Там ничего как бы особенного нет:
автолоадинг
события
работа с языками
кеширование
Просто сделано ради решения задач самым простым способом, а не чрезмерно академически.
Ядро в чем-то божественный объект. Но это оправдано, как и в случае с jQuery, нету лишних сущностей.
Фреймворки привносят очень много своих сущностей в разработку.
Я не против фреймворков ради того, чтобы быть против них.
Я против их недостатков.
Часто чтобы решить тривиальную задачу приходится долго мудохаться с фреймворком и его документацией.
Знаете, у вас в вашем блоге (в разделе IT) много чего занятного, не только по теме данной статьи. Там можно долго обсуждать и комментировать многие темы:
- Почему я не использую тесты кода
- Методологии разработки говно
- ООП говно
- Почему я не использую Twitter Bootstrap
Не смотря на то, что с некоторыми тезисами (но им не хватает должного раскрытия) я лично как-бы согласен, но в принципе наблюдается сумбурность вообще по многим темам в целом и по фреймворкам в частности:
- бОльшая часть негатива адресована Yii. Видимо, потому что там наибольший опыт. Но Yii (особенно 1) — не самый лучший пример фреймворка, да простят меня разработчики, которые используют его.
- вы часто делаете выводы из частного на общее. Например, пример плохого кода из приложения, которое написано с помощью какого-то фреймворка — не сам код фреймворка, а именно приложения! — для вас является показателем качества первого (фреймворка)
Я немного покапитаню, но для эффективного использования сабжа как и вообще фреймворков каких-либо надо много чего учитывать
вот немногое
- методологию
- тестирование
- метрики кода
- знание инструментов
- возможности языка
- алгоритмы
- и т.д.
Если по каким-то пунктах вы уходите так сказать в сторону и у вас появилось раздражение или плохие результаты (невозможность применять инструмент как хочется я также отношу к плохим результатам), это не значит что что-то из этого говно. Это значит, что где-то в применении подхода появился изъян. Важно, что тут речь о практике, а не о теории. И не надо всё месить в кучу. Надо "отдебажить" подход и посмотреть что из набора у вас работает не так как вы хотели и почему.
Может вам ЯП надо поменять или какой-то инструмент. Но в любом случае это напрямую зависит от задачи, которую вы решаете в данный момент. Инструменты разные же для разных целей. Если вам для склеивания фарворовой кружки не полошел молоток или скальпель — это необязательно потому что они — говно. Просто для склеивания надо использовать другое!
А вообще я согласен с мыслью, что фреймворки не надо использовать, но в том смысле, что так или иначе он у вас есть (50 КБ своей гордости), просто надо выбирать лучший, а лучший — это который помогает, а не мешает. В идеале вы его со временем просто не будете замечать.
>наблюдается сумбурность вообще по многим темам
Я часто пишу «статьи» не целенаправленно, а в результате участия в холиварах :)
Статьи постепенно дополняются.
>адресована Yii. Видимо, потому что там наибольший опыт
На всех работах с фреймворками использовался именно он.
А в статьях он потому, что я его использую на работе сейчас
>часто делаете выводы из частного на общее
Иногда это примеры :)
>для вас является показателем качества первого
Ну. например, возможность sql-инъекций — это к фреймворку, ибо говорится, что он от них спасает. :)
>это не значит что что-то из этого говно. Это значит, что где-то в применении подхода появился изъян.
Фреймворки очень сложны и это плата за их универсальность.
Мне такая универсальность не нужна.
А местами не логичны.
>Может вам ЯП надо поменять или какой-то инструмент.
Поэтому я пишу в личных проектах на самописи, которая мне понятна и в которой я хозяин. Мне не нужно гуглить, как в на фреймворке делается то-то и то-то. А это добивает.
>так или иначе он у вас есть
Рад, что поняли :)
Я бы сказал, это здравый смысл.
Жирные модели — это все равно, что у курятника будет 10-метровый фундамент… :)
>Делается наследование от класса
Наследование увеличивает сложность, не универсально.
>Думаю это основная причина вашей неприязни фреймворков.
Да :)
>В случае с Yii ни когда не испытывал проблем с документацией.
Она написана как будто для идиотов. Вот именно в Yii. Для создания хоумпаджей. А иногда просто phpdoc
>А страницы не авторизованных пользователей грузятся 5-1мс. Грамотное использование имеющихся механизмов кеширования.
Закешировать страницу целиком — это не совсем грамотно. Да и в 1-5мс я не верю как-то :)
>Nginx прекрасно с этим справляется.
Ну да, нгинкс веб-сервер :)
>Статичная страница на Yii создается 10 строчками кода.
А хедер/футер у такой странички будет?
>По вашему ORM не нужен?
1. Я писал не об ОРМ, а о конструкторах запросов, вроде andWhere/orWhere
2. Но да, я против ОРМ, это лишняя абстракция.
>В роутинге прописывается все достаточно легко. Дальше зависит от ваших рук и головы.
Удалил этот пункт :)
>Точно так же нужные фичи реализуются во фреймворке
Во фреймворках желательно же реализовывать фичи на АПИ самого фреймворка. А часто это усложнено, так как АПИ не предусматривает такого.
>По сути CMS, они есть, см. github.
Интерфес добавления пунктов меню должен быть одинаков.
Каждая CMS на разном фреймворке скорее всего реализует это по своему.
>Виджеты есть.
Я имел в виду программный интерфейс.
>Между 5 и 7й версией PHP тоже не идеальная совместимость.
У меня было только 2 проблемы с 5.2 на 7:
удаленные функции split и mysql_
>Например внутри Yii 1.x с совместимостью все хорошо.
А хотелось бы и 2 с 1. :)
Как в Битриксе.
Да, это сложно.
>Yii::app()->clientScript->registerCssFile(Yii::app()->request->baseUrl. '/css/style.css?'.md5_file(Yii::app()->basePath.'/../css/style.css'));
У меня на работе аутсорсеры, от которых достался код, просто прописали
/>
md5 файла тяжелая ф-я, лучше filemtime()…
>Безопасность и гибкость.
Откуда безопасность?
А гибкость зачастую не нужна.
Понятней обычные массивы GPCS.
MVC это архитектура
Model2 это архитектура (то что используется в Yii по сути), MVC это прием для уменьшения связанности приложения и GUI. Причем не используется активно уже лет 20 и является самой бесполезной аббривиатурой так как люди вкладывают туда самый разный смысл.
Symfony же (что бы вернуться к текущему посту) это request/response фреймворк и его хоть и можно подогнать под Model2 но нет смысла.
Делается наследование от класса, где реализуете алгоритм нужных вам настроек.
композиция лучше наследования, но ладно
По вашему ORM не нужен?
справедливости ради — далеко не всегда он нужен.
Например внутри Yii 1.x с совместимостью все хорошо.
у симфони еще лучше)
<form action="{{ path('BloggerBlogBundle_contact') }}" method="post" {{ form_start(form, { 'attr': {'class': 'blogger'} }) }}
Нужно просто
{{ form_start(form, { 'action': path('BloggerBlogBundle_contact'), 'method': 'POST', 'attr': {'class': 'blogger'} }) }}
method у форм по умолчанию POST и поэтому его явно указывать не нужно.
Ну и обработку формы можно оптимизировать
$form = $this
->createForm(EnquiryType::class, $enquiry)
->handleRequest($request);
if ($form->isValid()) {
// отправка письма
}Нет необходимости проверять запрос на POST, это сделает автоматически компонент форм
по оформлению форм в шаблоне, правильней всего так:
{{ form_start(form, {action: path('BloggerBlogBundle_contact'), attr: {class: 'blogger'}}) }}
{{ form_widget(form) }}
<button type="submit">Submit</button>
{{ form_end(form) }}- Symfony best practices рекомендует использовать аннотации для описания роутов.
- Валидаторы сущности лучше тоже делать через аннотации. По крайней мере это наглядней.
- Хоть это и не описано в best practices, но если вы протестируете свой проект в SensioLabsInsight, то выясните что все формы должны находится в директории
src/Blogger/BlogBundle/Form/Type/. - Параметры приложения принято описывать в файле
parameters.yml, а неconfig.yml. - Конфиги бандла принято подглючать через DI extension, а не через
app/config/config.yml.
Symfony2 автозагрузчик будет искать необходимые файлы в директории src
В Symfony нет автозагрузчика. Symfony использует для автозагрузки Composer.
Он использует расширение .txt.twig. Первой частью расширения, .txt определяется формат файла для генерации. Общие форматы включают, .txt, .html, .css, .js, XML и .json. В последней части расширения определяет, какой движок шаблона использовать, в данном случае Twig. Расширение .php использовало бы PHP для отображения шаблона.
Расширение
.html.twig это только рекомендации к наименованию расширения. Расширение файлов ни как не влияет на работу шаблонизаторов. Можно указать любое расширение, хоть .foo.bar.Вместо
$this->container->getParameter('blogger_blog.emails.contact_email')можно использовать getParameter
$this->getParameter('blogger_blog.emails.contact_email')Вместо
$this->get('session')->getFlashBag()->add('blogger-notice', 'Your contact enquiry was successfully sent. Thank you!');можно использовать addFlash
$this->addFlash('blogger-notice', 'Your contact enquiry was successfully sent. Thank you!');Несколько мелких замечаний по оформлению:
- В сущностях рекомендуется описывать реальные типы, а не писать везде
mixed. - В сущностях рекомендуется указывать значение по умолчанию. Например email всегда должен быть строкой и не когда не должен становится null-ом.
- В setter-ах рекомендуется возвращать ссылку на текущий объект
$thisчтобы можно было использовать цепочки вызовов. - В классе формы рекомендуется использовать цепочку вызовов для конфигурирования формы.
- В форме метод
configureOptionsне обязательный и если он пустой, то лучше его вообще не указывать.
PS: В целом статья хорошая. Спасибо за проделанную работу. Хотя лучше писать качественный код чтобы новички не перенимали плохое.
PSS: Не сочтите за рекламу. Несколько полезных сервисов для тестирования проекта:
и еще. В PHPStorm с установленным плагином Symfony можно указать в начале шаблона комментарий
{# @controller BloggerBlogBundle:Page:contact #}и тогда в шаблоне автокомплит будет видеть все параметры передаваемые контроллером и по щелчку Ctrl+Mouse Left Click мы перейдем в контроллер, а при аналогичном щелчке по ссылке на шаблон перейдем в сам шаблон
return $this->render('BloggerBlogBundle:Page:contact.html.twig', array(
'form' => $form->createView()
));
Создание блога на Symfony 2.8 lts [ Часть 2 ]