• Правильный способ хранения текста и HTML-кода в базе MySQL?

    В чем-то вы правы, например в том, что автор не упоминал источник. Но мы упомянули. И разобрались в том, что вас так беспокоит в моих ответах. И ЧСВ тешить нужно, наверно, в дргом месте, а не хвастать тут тем, что вы один поработали википедией в этом вопросе. И, представляете, вопросы могут еще вызывать другие вопросы и затрагивать не только те темы, которые автор предусматривал. Ведь на то он и тостер, что бы несведущих просвещать, разбираться в вопросах. А как это можно сделать, если вопрос некорректен или не полон? Ни как. Поэтому и раскрываются другие моменты, что не так уж и плохо. Может автор по другому взглянет на проблему. Ну, что бы наглядно свою мысль продемонстрировать, давайте рассмотрим вот такой диалог:
    - (автор) как засунуть шар в треугольную дырку?
    - (вы) надо сильнее давить (помечено как правильный ответ)
    - (кто-то еще) надо взять треугольних
    - (еще кто-то) надо в круглую дырку пихать
    - (опять вы) "Автор вообще не говорит об круглости дырок. Это вас, учителей неграмотных, набежало целое стадо, поблеять о своём. Что характерно, ответить на вопрос ни один не осилил."
  • Правильный способ хранения текста и HTML-кода в базе MySQL?

    Г-н тролль, тут такое дело, что, например, твиг может парсить строки, которые могут быть чем угодно... И, да, я понял, почему мы не понимаем друг-друга, вы (и автор) говорите о контенте, генерируемом пользователем, а я о разметке страниц, которую пользователь может создавать сам, при этом тут и шаблонизатор. И не ведите себя как хам, а то стрёмно смотрится. И не вам решать, когда "можешь расходиться", грамотей ;)
  • Правильный способ хранения текста и HTML-кода в базе MySQL?

    Дак естессено слышал, даже больше, - использовал, но если твой, мой милый тролль ))), кругозор, не позволяет тебе понять, что редактируемые фрагменты разметки (а оссобенно если они еще потом шаблонизатором парсятся), всетки можно и даже нужно стараться хранить таки в файлах, то - это значит мы смотрим на это по разному и не надо тут жечь напалмом ))))) Конечно бывают такие случаи когда надо хранить все это в БД, но они редки и их вообще лучше избегать... Простой пример: в статье с "богатым" форматированием должны быть фотки. И что? Вы собираетесь их контент прям в разметку засовывать? Ну неее... Извращение. Лучше загружать их вообще отдельно как прикрепления и накрайняк ссылки тут же выдавать для вставления их пользователем в редактируемый текст. Да и вообще, вариантов много, можно повсякому делать. Вы высказали свое мнение, я свое, давайте разойдемся.
  • Правильный способ хранения текста и HTML-кода в базе MySQL?

    И, да, я не претендую не на что, - это - я так считаю
  • Правильный способ хранения текста и HTML-кода в базе MySQL?

    Аа... Ну понятно... Вы тут уже пробурлили на эту тему. Ясно. В любом случае в БД должна быть выжатая инфа, без разметки...
  • Хорошая архитектура symfony app?

    krocos
    @krocos Автор вопроса
    Вы отлично подытожили все, что здесь было сказано. Структурировали, так сказать.
  • Хорошая архитектура symfony app?

    krocos
    @krocos Автор вопроса
    Ну, как мне кажется, самому классу сущности хуже от аннотаций не станет (тем более, Фабьен говорит, что лучше и читабельней как раз аннотации в классах моделей ), лучше относиться к этому как к приятной особенности работы с доктриной и/или сериалайзером (JMS). Ведь, если начать использовать другой слой БД то аннотации просто-напросто будут игнорироваться...
  • Хорошая архитектура symfony app?

    krocos
    @krocos Автор вопроса
    А в модельные задачи, CRUD входит, или еще что-то?
  • Хорошая архитектура symfony app?

    krocos
    @krocos Автор вопроса
    Ну вот пример: Допустим, споит задача: получить какие-то итемы из БД, при этом, что бы их получить, нужно учесть определенные фильтры, потом их обработать и выдать.

    Если я вас правильно понимаю, то надо сделать так: получить итемы из итем-репозитория (пусть будет доктрина), потому что мы хотим логику работы с данными оставить в моделях, при этом можно учесть необходимые фильтры, передав их в качестве параметров в вызываемую функцию репозитория; потом мы полученные итемы обрабатываем, вызывая какой-то необходимый для этого сервис, так как бизнес логику (эту самую обработку итемов) нехорошо писать в контроллерах, а уже полученный результат отдаем на рендеринг в шаблонизатор...
    Таким образом контроллера остаются ультра-тонкими, модели жирными, потому что много чего (обычно дергать приходится из БД и с разными параметрами), а сервисы хорошо тестируемыми и пригодными для повторного использования

    Я все правильно понимаю?
  • Хорошая архитектура symfony app?

    krocos
    @krocos Автор вопроса
    У меня такое ощущение, что ваш ответ можно сократить до "Патернов много. В любом случае надо исходить из задачи, и подбирать лучшее инструменты для её решения."

    Но в том то и вопрос, как правильно использовать контейнер и организовывать сервисы, что бы было хорошо?
  • Хорошая архитектура symfony app?

    krocos
    @krocos Автор вопроса
    Ну, я лично, подразумеваю под словом сервис что-то, что доступно везде в любой части приложения, что-то, что можно написать единожды без копипасты и потом использовать...
  • Как удалить объект, вызвав какой-либо его же собственный метод (PHP)?

    Ну да, я так и думал... Остается только uset всех ссылок на объект...
  • Битва титанов: BEM vs Twig или твиг уже не то?

    krocos
    @krocos Автор вопроса
    Мне одному кажется, что проще сдалать твиговых макросов и импортировать куда надо? При этом плюсом будет возможность формирования страницы динамически, а не JS-ом из браузера пользователя... В общем, сомнительная польза БЭМ не дает мне покоя потому, что я никак немогу понять лучше ли будет для симфонии, если его использовать, то ли я бэм не понял, толи твиг всетки тожесамое умеет...
  • Битва титанов: BEM vs Twig или твиг уже не то?

    krocos
    @krocos Автор вопроса
    Вопрос та как бы в том есть ли профит от использования бэм вместо твига для бэкенда на симфонии...
  • Битва титанов: BEM vs Twig или твиг уже не то?

    krocos
    @krocos Автор вопроса
    Ну если мы про интеграцию БЭМ с симфони, то я могу сказать, что она врядли появится по той простой причине, что БЭМ - это методология сборки фронтенда абсолютно независимая от бэкенда... Если я все правильно понял, то бэм обеспечивает гибкую систему сборки фронтенда, по сути превращая его в лего )) но а бэкенд может быть любой... Вот яндекс, как я понимаю, в основном пишет бэкенд на c++... А мы можем на симфонии писать...
  • Битва титанов: BEM vs Twig или твиг уже не то?

    krocos
    @krocos Автор вопроса
    Интеграцию чего: бэм или твиг?
  • Битва титанов: BEM vs Twig или твиг уже не то?

    krocos
    @krocos Автор вопроса
    Вот кто-то хрен с пальцем сравнивает, а тут котлеты с носками... Вы женаты? ))) А по делу ниже ответ...
  • Как же всётки создавать админку c Symfony2?

    krocos
    @krocos Автор вопроса
    Вот я собственно тоже не очень понимаю радость от использования бандлов, которые по размерам сравнимы с Form-фреймворком symfony...
  • Как же всётки создавать админку c Symfony2?

    krocos
    @krocos Автор вопроса
    >>>> "Много JS - не по феньшую"
    >> Мне кажется в наши дни это как раз по фэншую.
    Меня не оставляет мысль, что всетки надо побольше решений php... Я понимаю, что бум развития js-решений последнее время всех задел, но, боюсь наверно, что это будет просто вспышка, а мы потратим на это кучу времени, вместо того, что бы написать достойное решение для php. Я наверно смотрюсь после сказанного как perl-прогер, который за 27 лет повидал много всяких всплесков вокруг других ЯП, в том числе и новых, но попрежнему кодит на перле...
  • Как же всётки создавать админку c Symfony2?

    krocos
    @krocos Автор вопроса
    Да вот про это я и говорю :) Много JS - не по феньшую... А как же php? А как же цикл запрос-ответ? Фабьен несколько лет ни спал ни ел писал фреймворк, формы, груд, валидаторы, а вы ng-admin... В сторону nodejs не посматриваете ли? )))

    Ну а кроме шуток, - получается, что надо знать на очень хорошем уровне еще один ЯП. В особенности angular, что бы отвечать современным скоростям и качеству разработки приложений? Или еще один слой абстракции над и без того гибким и нетипизированным языком по типу кофескрипта?

    Вы сами пробовали писать админку на JS с js-фреймворком? Как это по времени выходит? Как со сложностью, удобством разработки?