1

(3 ответов, оставленных в Symfony 3.0–3.2)

antifreez пишет:

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

Я хочу сказать, что если вы хотите рассматривать «php код symfony» как обычный PHP код, то вам в первую очередь нужно выкинуть нахер плагин Симфони из вашего редактора. И ошибки перестанут сыпаться из него, как из рога изобилия. При условии, конечно, что дебагер будет исполнять ваше приложение в идентичном серверному окружении, а не как ему самому вздумается.

Как разработчик, вы должны понимать, что дебаггер редактора (обычно) не идентичен профайлеру. И его тоже нужно настраивать, потому что сам он не обязан догадываться, как именно ему нужно исполнить ваше приложение, в каком окружении и через какую точку входа. И даже настройка всего этого не гарантирует идентичности результатов, особенно если дебаггер пытается «для улучшения результатов» вносить какую-то отсебятину в исполнение.

antifreez пишет:

Скрины отработки одного и того же запроса прилагаю.

Кстати, если посмотреть внимательнее, то запросы на скринах РАЗНЫЕ. default/smile

Редактор на скрине согласно эксепшенам пытается получить шрифт glyphicons в формате woff2. Причем спрашивает он его у приложения: «no route found for /fonts/some-long-shit.woff2». И рядом в «Output» виден бинарный контент woff.

2

(3 ответов, оставленных в Symfony 3.0–3.2)

Никогда не работал с этим редактором, но ошибки намекают на то, что в редакторе плагин Симфони либо не настроен, либо просто кривой/под другую версию фреймворка.
Соответственно, можно попробовать разобраться с плагином в редакторе, поигравшись с его настройками, если не поможет — забить и пользоваться для отслеживания ошибок профайлером самой Симфони.

3

(1 ответов, оставленных в Symfony 2.0—2.2)

Lisjann пишет:

Понятно что вот так $builder->add( 'properties', 'text') не получится

Ну кагбэ, документацию по формам вам в руки, с официального сайта.
http://symfony.com/doc/current/forms.html

И не сильно важно, что там на 2.0/2.2 уже документации нет (странное, на мой взгляд, решение выпилить доки на неподдерживаемые версии), там в контексте вашей задачи не так много изменилось. Открываете для 2.7 и вперед, с песней.

Единственное ощутимое отличие, емнип, это то, что в 2.0/2.2 конфигуратор формы выглядел так:

public function setDefaultOptions(OptionsResolverInterface $resolver)

а в 2.7 (и в мануале соответственно) он выглядит немного по-другому:

public function configureOptions(OptionsResolver $resolver)

Поэтому в 2.2 вариант кода из мануала работать не будет.

Параметр data_class = homes для основной формы (если вдруг не стоит, ибо в приведенном коде метод setDefaultOptions() у формы отсутствует), тип поля properties — CollectionType, тип элемента в коллекции — какой-нибудь PropertiesType, который вам нужно создать. У этого элемента data_class = properties. В общем, все стандартно, по доке.

4

(3 ответов, оставленных в Symfony 1.3, 1.4)

Самый простой способ лечения — вернуть проект под пхп5. Ни первая ветка, ни Пропел — не совместимы с пхп7 и без допиливания напильником вручную работать не будут.
Можете как вариант попробовать заменить Симфони на последнюю версию в ветке 1.4 (если вдруг в проекте используется не последняя) — может там что-то и пофиксили на этот счет, не в курсе. Но скорее всего проект просто не совместим с пхп7.

5

(3 ответов, оставленных в Symfony 1.3, 1.4)

Можете попробовать погуглить по «specifies category with missing class key», чтобы лучше понять природу проблемы.
Проблема могла возникнуть из-за обновления версии фреймворка либо обновления версии PHP (второе значительно более вероятно, так как проблема судя по всему возникает в самой Симфони, и к коду проекта отношения не имеет).

6

(2 ответов, оставленных в Изучение Symfony)

mavellol пишет:

сделать вызов контроллера из вьюхи?

Как вариант, один из многих.

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

Можно накатать сервис и/или хелпер. Зависит от конкретики задачи. Но и вызов контроллера вполне нормальный вариант, не вижу тут особых проблем.

brizzz пишет:

Оригинальный текст в качестве ключа пока мне кажется не очень удобным.

На самом деле это вовсе не решение, так как одна и та же фраза или слово, находящиеся в разных местах, в зависимости от контекста, легко могут иметь разные эквиваленты в другом языке. В хорошем переводе переводится не текст сам по себе, а его значение в контексте.
Простой скрипт может брать например англоязычный XLIFF файл перевода за основу и подставлять ключ в id блока, а в source оригинальный английский текст.  После чего переводчики могут спокойно грузить это в Традос. Обратно по аналогичной схеме — заменять оригинальный английский текст в source на значение, сохраненное в id, и результат совать в Симфони.

brizzz пишет:

Во первых нет иерархической структуры

Ну, это в той же БД реализуется на ура, добавляете дерево и получаете копию иерархии в ФС. default/smile

brizzz пишет:

редактировать html.twig шаблоны в простом текстовом поле неудобно, ни подсветки, ни форматирования, ни возможностей IDE. К тому же активно используется наследование, include конструкции, и даже уже подключаются шаблоны из файловой системы

Тут только самому писать, видимо, надстройку на JS, чтобы подсвечивала и через макросы нужные конструкции добавляла. У меня похожим образом форматирование публикаций в проекте работает (размещение элементов и линковка через макросы).

brizzz пишет:

Мета информацию можно хранить в twig-комментах. А по поводу опций... Их можно реализовать в другом месте

default/smile Если так извращаться, то опции тоже можно в тех же комментах Твига хранить, в json. Но один хрен БД в этом плане удобнее.

brizzz пишет:

Проверки синтаксиса шаблона не достаточно.

Ну, не обязательно это делать сразу на проде. Тут посыл несколько другой — автоматизация. Если действительно нужно только ручное ревью, то автоматической эту операцию конечно не сделаешь. Но можно например создать песочницу, где версия шаблонов будет билдиться и проходить все тесты. И в случае успешного прохождения — автоматом же апдейтить прод скриптом.

brizzz пишет:

Важнее дать возможность редактировать файлы переводов

Мигрировать на XLIFF и использовать стандартные инструменты для переводчиков. Вернее, это переводчики будут использовать эти инструменты, а вы им просто отдаете XLIFF и получаете в ответ XLIFF. Это «родной» формат для TRADOS (стандарт для переводчиков, примерно как Фотошоп для дизайнера).
Единственная проблема — в Симфони XLIFF используется не совсем стандартно (если вы используете ключи, а не оригинальный текст в качестве ключа). Из-за этого у переводчиков будут неудобства при переводе, так как по сути они вместо оригинального текста будут видеть ключи. Но это, опять же, больше их проблема, чем ваша. Можно конечно написать простенький скрипт, который будет конвертировать оригинальные XLIFF в удобные для переводчиков и потом результат их работы конвертить обратно. В любом случае, лучше XLIFF для этого ничего нет. Ямл для переводчиков — НЁХ, про пхп я уже молчу. А через веб-интерфейс тоже неудобно и медленно.

Не вижу проблемы в хранении шаблонов в базе в контексте задачи. БД функциональнее, можно параллельно хранить кучу мета-информации, добавлять опции и т.д. С файлами такого не провернешь.

Но процесс «тестовый сервер — дамп в csv — пулл реквест» мне лично непонятен. Есть какие-то специфические требования, требующие такой замороченной реализации? Попробуйте описать эту часть, и зачем она. На мой взгляд, этот процесс вообще можно сделать автоматическим, и без всяких csv.

С вменяемыми визивигами и файл-менеджерами под веб вряд ли помогу — в основном все что мне доводилось видеть — унылое говно, часто еще и дырявое. И, я все же не уверен, что именно визивиг в данном случае — подходящий вариант. Но тут уже нужно смотреть, какие есть возможности у менеджеров (т.е. обладают ли они хотя бы базовыми знаниями html/twig разметки или все совсем плохо).

10

(3 ответов, оставленных в Symfony 2.6–2.8)

zaynabiginov пишет:

куда надо глянуть?

Я за вас ваш проект не знаю. Это не CMS, здесь программист сам решает, как ему строить свое приложение.

Для начала нужно найти этот Layout2.html.twig и изучить, особенно вблизи строки 58. Затем поискать в коде и шаблонах bottomBlock, чтобы понять, как и где эта переменная формируется. И есть ли она вообще в природе проекта. Возможно, это ошибка в теге и вместо переменной там должен быть вызов блока bottomBlock, который формируется где-то в шаблоне выше по иерархии. Тут нет универсальных советов.

11

(3 ответов, оставленных в Symfony 2.6–2.8)

zaynabiginov пишет:

все страницы и шаблоны есть и ссылки к ним правильно прописаны

Это каким образом вы определили, что все «правильно прописано»?

zaynabiginov пишет:

Variable "bottomBlock" does not exist in Layout2.html.twig at line 58

Тут в тексте совершенно однозначно указано, что в шаблоне Layout2.html.twig на 58 строке объявлена переменная bottomBlock, но при этом в шаблон переменная с таким именем не передается. Или передать, или удалить объявление, или добавить условие на существование этой переменной.

zaynabiginov пишет:

Undefined index: gall_left_menu

Аналогично. Нет индекса gall_left_menu в каком-то там массиве где-то. Смотрите трейс и исправляйте (ставьте условие или удаляйте код/данные, требующий этот индекс).

Вторая ошибка вообще к Симфони не относится, это пхп матерится.

12

(3 ответов, оставленных в Symfony 2.6–2.8)

Otezvikentiy пишет:

Я нашел AbstractAuthenticationListener, мне вполне достаточно его.

Эм. Я правильно понял, что вы собираетесь ИЗМЕНИТЬ код класса AbstractAuthenticationListener из пакета Симфони?
Кагбэ, мягко выражаясь, изменять что-либо непосредственно в библиотеке вендора не принято. Потому что следующий апдейт/реинсталл вендоров затрет ваши изменения.


Otezvikentiy пишет:

Как мне из AbstractAuthenticationListener обратиться к сервису

Если он туда не «приезжает», то никак, очевидно.
Создайте свой слушатель, суньте ему в конструктор энтити менеджер, пропишите слушатель в сервисах с соответствующим аргументом (энтити менеджером) и пользуйтесь. Слушатель не должен никуда сам обращаться. Он может работать только с тем, что ему дали при создании/что пришло в ивенте.

13

(3 ответов, оставленных в Symfony 2.6–2.8)

Запилите свой слушатель на это событие, и там выполняйте все, что вам нужно.
Пропишите его в сервисах, пропишите ему необходимые зависимости (Доктрина какая-нибудь или что там в вашем проекте используется, чтобы в базу лазить).

Например: http://www.webtipblog.com/create-authen … symfony-2/
Алсо: http://symfony.com/doc/current/event_dispatcher.html

14

(3 ответов, оставленных в Изучение Symfony)

dubovitskii1990 пишет:

Попробовал поменять

Ну, лучше все-таки менять значение %locale% в app/config/parameters.yml, а не напрямую забивать его в конфигурацию. Хотя бы потому, что параметр %locale% мог быть использован программистом где-нибудь еще в коде, где ему нужна была локаль по-умолчанию.

И да, после смены конфигурации ничего не произойдет до тех пор, пока вы не сбросите кеш (лучше всего через консоль, что-нибудь типа "php bin/console cache:clear --env=prod").
http://symfony.com/doc/current/console/usage.html
Если доступа к консоли сервера нет, можно конечно просто грохнуть все внутри директории app/cache (или var/cache в последних версиях Симфони). Но это не самая безопасная операция, так как если по какой-либо причине новый кеш  конфигурации создан не будет, то сайт перестанет отвечать на запросы. Новый кеш генерируется автоматически, при первом запросе вебсервера к приложению, в случае отсутствия ошибок.

15

(3 ответов, оставленных в Изучение Symfony)

Язык по-умолчанию меняется в конфигурации приложения (обычно app/config/parameters.yml), parameters -> default_locale.
Но замена дефолтного языка вызовет совсем не то, что вы хотите — просто по адресу domain.com будет сразу открываться англоязычная версия. А если вам нужен редирект, то его можно либо запилить в том же .htaccess (менять там ничего не нужно, просто добавьте правило редиректа с корня на /en сразу за первым RewriteRule), либо в контроллере в экшене, который обрабатывает корневой роут (/). Где он конкретно в вашем приложении — я понятия не имею, это как писавший этот проект программист решил. Какой из вариантов вы используете — значения не имеет.

Алсо, редирект с корня на /en — хоть и допустимая, но не самая удачная идея. У сайта в этом случае вообще нет корневой страницы, это минус для поисковиков. Но без конкретики и знания проекта советовать тут нечего.

antifreez пишет:

почему в поставку симфони по-умолчанию не входит средство по работе с юзерами?

Потому что мир разнообразен. И построить одно универсальное «средство по работе с юзерами» для всех проектов не представляется возможным. Тем более что его универсальность его же и похоронит, потому что универсальность нельзя создать просто так, она обязательно будет в ущерб производительности, лаконичности, безопасности. Поэтому его даже не пытаются создать, за что разработчикам Симфони большой респект.
Фреймворк вообще не должен лезть в модель и бизнес-логику. Это то, что разработчик должен делать сам, в соответствии с конкретной задачей.

Есть «прекрасный» пример — Symfony CMF. Бессмысленная и беспощадная попытка «занести» Симфони в нишу ЦМС. Никогда не используйте эту поделку в коммерческой разработке.

Koc пишет:

в реально проекте его лучше не использовать

Холиварненько. default/smile
В реальности, к сожалению, в коммерческих проектах можно использовать хорошо если каждый двадцатый бандл из опубликованных, это если быть оптимистом. И FOSUser не исключение, правда с оговоркой — если программист неопытный, то крайне рекомендуется просто взять и поставить долбаный FOSUser по туториалу, а не клепать свой дырявый велосипед, ибо пользователи и безопасность их данных важнее глупых амбиций.
А так да, из известных бандлов (из тех, что не входят в поставку Симфони «по-умолчанию») я затрудняюсь назвать хоть один, который можно было бы рекомендовать для использования в коммерческом проекте.

Я поставить FOSUser предложил не потому, что он хорошее решение. А потому, что это хороший вариант на практическом примере разобраться с устройством фаервола.

antifreez пишет:

в официальной документации по security и firewall описан чрезвычайно сложный процесс

antifreez пишет:

Может кто-нибудь объяснить это для новичка?

Не проще взять готовый бандл?
https://github.com/FriendsOfSymfony/FOSUserBundle
Не факт, конечно, что его установка будет такой уж простой. Но всяко она будет проще, чем реализация своего велосипеда, когда вы плохо понимаете, как он должен быть устроен.
Ну и ессно, ничего не мешает поковырять внутренности бандла, чтобы лучше понять, как устроен фаервол в Симфони и как под него писать свои велосипеды.

19

(7 ответов, оставленных в Symfony 2.6–2.8)

antifreez пишет:

Я понял. Но куда всё же их положить?

antifreez пишет:

В сущности это могут быть даже статичные методы Helper::slugify($text)

Могут, но не должны быть.
В сущности НЕ ДОЛЖНО быть посторонних методов и зависимостей. Статический вызов — это тоже зависимость, причем худшая из возможных. Вы намертво привязываете свою сущность к классу хелпера. Этот код невозможно тестировать и он хрупкий.

Я уже несколько раз писал выше про принятую структуру. Есть сущность, у которой в каноническом случае должны быть простые как дверь геттеры и сеттеры (да, тупые сеттеры и геттеры это не лучший вариант, но самый простой функционально и лучший для вас, пока вы не дошли до какого-нибудь DDD). Никакой логики сущность не выполняет, никаких операций с данными внутри себя не производит — простейшие геттеры и сеттеры, ничего более.
И есть менеджер группы сущностей, задача которого — выполнять всю работу по созданию, обновлению, удалению и т.д. этих сущностей. Вы пишите и оформляете его как сервис. И вот он и будет генерировать слуг и вставлять его в сущность через setSlug(), делая попутно разные проверки, которые диктуются бизнес-логикой.
Откройте, как пример, FosUserBundle. Не лучший, имхо, вариант для подражания, но позволит понять принцип. Вот например управление сущностями пользователей:
https://github.com/FriendsOfSymfony/FOS … anager.php

20

(7 ответов, оставленных в Symfony 2.6–2.8)

antifreez пишет:

То есть True Symfony way это держать две одинаковые функции slugify? По одной в каждой сущности?

Это не держать в сущностях никаких посторонних функций.
Зачем сущности нужна slugify? Почему эту функцию не может делать ее менеджер, например?
Сущность получает заголовок извне, через метод setTitle. Ровно таким же способом она может получать готовый слуг.

21

(7 ответов, оставленных в Symfony 2.6–2.8)

antifreez пишет:

Как сделать просто и красиво?

Единственный вариант сделать «просто и красиво» — навсегда забыть про идею держать и вызывать внутри сущностей какие-то посторонние штуки. Если хочется сделать сложно и некрасиво, можно фигачить сервисы в сущности через слушатель по postLoad. Но это крайне плохая идея.

Во-первых, это магия. Вот конкретно в приведенном примере, вы устанавливаете в сущности заголовок согласно правильному однозначному методу setTitle, а сущность сама себе ставит слуг, хотя соответствующей команды вы не давали. И, более того, вы не управляете этим процессом. Т.е. когда вам понадобится поменять только заголовок, не меняя слуг (а вам обязательно понадобится, потому что заголовки как раз имеют обыкновение меняться по разным причинам, а вот слуги не очень — потому что если объект уже опубликован, то изменение слуга вызовет изменение адреса объекта, и как следствие 404-ю по старому адресу), вы не сможете это сделать через ваш код.

True Symfony way — это сущности, свободные от бизнес-логики, и их менеджеры, выполняющие всю работу. Можно долго спорить о том, хорош такой подход или нет, но он позволяет держать сущности легкими, а их управление — гибким. В менеджере вы можете реализовать десятки кейсов апдейта сущности со своей логикой, при этом сама сущность останется легкой и свободной от тонн кода. В более продвинутых подходах часть бизнес-логики может находиться в сущностях, но опять же, если она при этом требует каких-то посторонних сервисов, то это плохая практика. Всю эту работу должен делать внешний менеджер/хендлер/любая другая хрень в зависимости от конкретного подхода, созданная конкретно для этой цели.

22

(5 ответов, оставленных в Symfony 2.6–2.8)

antifreez пишет:

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

Ну я её тоже не в Гарварде изучал. default/smile
Все зависит от начального базового уровня (ООП, паттерны, ЯП) и твердости намерения изучать. Базис нужен, чтобы понимать, как и что устроено и, главное, почему устроено именно так. Без этого знание мало полезно и напоминает манки-кодинг по туториалам. Для Симфони с учетом его сложности, базис нужен обязательно.
Что касается подходов, то на мой взгляд лучший — через разбор кода фреймворка. Это позволяет понять, что и как работает внутри. Это медленный путь, но дающий лучшее по качеству знание.

Что касается освоения «боевого применения» сидя дома с самому придумываемыми заданиями — тут конечно сомнительно. Но до уровня «могу писать под Симфони на коммерческой основе» дорасти дома вполне можно. Дальше все равно командная работа незаменима — нужны и реальные задачи, и код-ревью, и сам по себе навык командной работы, поскольку Симфони — это сложный фреймворк для сложных проектов, а сложные проекты почти никогда не реализовывают в одиночку.

23

(5 ответов, оставленных в Symfony 2.6–2.8)

antifreez пишет:

Вместо того чтобы делать проект, я 4/5 своего времени трачу на то что воюю с самим фреймворком?

Это потому что вы его не знаете. А не знаете потому, что доку как следует не прочитали.

antifreez пишет:

Ну не могу же я по каждому чиху лезть в документацию и копипастить строчки в конфиги или в сами файлы?

А какие у вас предложения есть по решению этого вопроса, собственно? Любая сложная вещь (а Симфони — безусловно сложный фреймворк) требует большого количества времени на освоение и настройку.
Нет, можно конечно взять какой-нибудь Кодигнайтер (не при женщинах будет упомянуто). Он простой как дровяной сарай начала прошлого века и там все понятно и без документации. Просто потому что понимать особо нечего.

Везде есть свои плюсы и минусы. Просто нужно выбирать решение по задаче.
Симфони — сложное серьезное решение для соответствующих проектов. На его изучение требуется время и хороший базис знаний (в принципе не свойственный для похапешников default/smile). Но результат оправдывает затраты. Для сложных проектов Симфони — лучшее, что есть в PHP. И, в общем-то, единственное, что меня до сих пор в PHP держит.

antifreez пишет:

Ну серьезно, чисто теоретический вопрос, в чем преимущество такого программирования?

Основное преимущество в том, что в проекте с 50к+ строк кода вы получаете устойчивую архитектуру (при условии, что пишут его программисты, а не рукожопы, ессно), при этом фреймворк решает все базовые задачи по работе вашего приложения (сервинг, протоколы, middleware, пачка компонентов типа форм, фаервола, DI и т.д).

Интуитивность — штука относительная. Мне сложно судить о интуитивности, поскольку я программирую на Симфони последние лет семь и для меня в ней все интуитивно. Ассетиком я правда не пользуюсь, но в принципе любые нормальные решения по генерации ресурсов имеют функцию слежения, поэтому для меня совершенно логичным было поискать в Гугле по словам «assetic watch» и убедиться, что такая функция существует. Ресурсы можно билдить и какой-нибудь Нодой, но там будет ровно то же самое. Т.е. либо слежение, либо билдите ручками командой после каждой запятой, если хотите увидеть изменения. Это нормально, другого пока никто не придумал.

24

(5 ответов, оставленных в Symfony 2.6–2.8)

antifreez пишет:

Мне после каждой запятой своём стиле

Достаточно покурить документацию Ассетика по команде assetic:watch для режима разработки.
Ну или вообще просто вдумчиво покурить его документацию.

25

(2 ответов, оставленных в Symfony 2.6–2.8)

antifreez пишет:

но по факту нету таких файлов в Web/js и Web/css

antifreez пишет:

В том руководстве ничего больше не сказано.

Ну этсамое...
А по assetic доку почитать, не? default/smile

bin/console assetic:dump --env=prod --no-debug

в консоли.
И я там components в зависимостях вижу. Что говорит о том, что они должны быть установлены (если вдруг еще нет).
https://github.com/RobLoach/component-installer

antifreez пишет:

В предыдущей ветке никто не отвечает

Видимо всем некогда. Мне по крайней мере точно.