DevMan: Я уже нашел ответ. Ниже отпишусь. Я использую первую версию фиксера, у вас вторая (atom beautify совместим только с первой, надо бы на досуге этим тоже заняться, pull request запилить). Первая версия удаляет пробелы без определенных опций.
P.S. А так я использовал такой список правил:
--level=symfony
--fixers= short_array_syntax,class_definition,function_declaration,indentation,double_arrow_multiline_whitespaces,duplicate_semicolon,empty_return,include,multiline_array_trailing_comma,namespace_no_leading_whitespace,object_operator,operators_spaces,phpdoc_params,remove_leading_slash_use,remove_lines_between_uses,return,spaces_before_semicolon,spaces_cast,ternary_spaces,unused_use,whitespacy_lines,concat_with_spaces
brainflow: Да я тоже когда ответ писал, думал что решение наркоманское. Но при простом листинге постов со списком тегов будет очень быстрым. А вот для статистики по тегам надо будет прикручивать отдельную таблицу с тегами, где поле тег будет помечено уникальным ключом. Тогда статистика типа популярных тегов будет отображаться быстро, но получается что при добавлении поста будет дублироваться информация в две разные таблицы которые друг с другом ни как не связаны, что не очень элегантно. Да и при получении постов с определенным тегом поиск по полю с json будет медленней чем поиск по ключу. И для нового человека который такой код увидит, будет все не очень логично. Это всё палка о двадцати концах какая-то, вам надо понять для начала для каких данным вам критична производительность. Но я бы свой вариант не использовал, я бы оставил стандартный реляционную модель, отделная табличка для постов, отдельная для контента в постах, отдельная табличка для тегов и там всякие мэни ту мэни связи.
А вообще гляньте во всякие опенсурс проэкты типа Wordpress (он вроде даже с постгерсом работать умеет), как там реалезованно.
moneymakerXA: Тоесть шрифт при увеличении изменяется сильнее чем все остальное? В любом случае вам надо будет читывать то, что в форму могут вбить пару глав "Войны и Мир", и вам надо будет либо ограничить ввод по количеству символов, либо прикрутить скроллинг.
dllweb:
/**
* ORM\Table(name="Blog\Post")
*/
эта запись указывает в какой таблице бд будут хранится записи. MySQL 5.7 в названиях таблиц поддерживает символы: [0-9,a-z,A-Z$_], как видите слеша среди них нет. Скорей всего раньше просто не генерировалась аннотация для имени таблицы, и поэтому таблицы назывались по умолчанию (по имени класса).
Антон Дышкант: То-есть вы хотите прописать phpDoc'ом в одном месте, чтобы для SomeCollection, SomeCollection2 и т.д., автоматически задавалось соответствие для $items: SomeClass и SomeClass2 соответственно. Если так, то увы, у вас это не получится.
По поводу property: вы указываете /** @ property SomeClass[] $items */ только в одном месте и в классе конкретной коллекции, и везде где используется класс этой коллекции phpstorm будет знать, что в свойстве $items лежит массив объектов SomeClass. Имхо это самый правильный вариант для вашего случая.
Андрей: Меня сбило "Вот пример представления: ...". Попробую переформулировать, в общем View должно рендерить конкретный шаблон (допустим 'news'), в этом шаблоне вы переопределяете или назначаете переменные для главного шаблона, а затем подключаете главный. В twig для этого используются блоки.
Если говорить о реализации, то это выглядит примерно так: рендерим news, с помощью буферизации вывода (ob_start) и записываем в переменную $content, затем рендерим главный шаблон выводя в нужном месте $content.
