Насколько я помню - не задавать поле во второй entity в связанных entities вообще нельзя, валидация Doctrine на это ругается. Сейчас попробовал - валидация не проходит.
Медитировать, отлично расслабляет ум, как с утра так и после работы. Если какой-то конкретной техникой медитации не владеете - вокруг сейчас много вариантов где найти информацию. Та же анапана прекрасно подходит.
Напрямую вряд ли получится, как минимум grid-gap в IE не поддерживается т.к. там реализована старая версия спецификации. Также не уверен есть ли там работа с регионами
fman2, Да, задача ясна. Собственно вы сейчас как раз описали inheritance mapping в Doctrine. Причём, поскольку список entities планируется к расширению - вам стоит рассматривать вариант Class Table inheritance, хотя он и несколько медленнее из-за дополнительного join'а.
fman2 Уточните пожалуйста, ваш className в поле entity - это прямо свойство самой entity, а не inheritance mapping? Если так - то ваш вопрос скорее про запросы, а не про associations
Alxjzx100, А data source к базе данных, к которой адресован этот запрос у вас сконфигурирован? Если нет - то логично что PHPStorm не может проверить его корректность и пишет об ошибке.
Если же вы хотите чтобы PHPStorm перестал анализировать ваши запросы, то здесь тоже всё просто: на запросе Alt+Enter -> Inject language using PHPDoc -> и установите /** @lang text */
Во-первых спасибо за разъяснения, все мы учимся :)
Тем не менее, для того чтобы мне самому лучше разобраться в вопросе - хотел бы попросить вас прояснить следующий момент (или ткнуть носом туда где можно почитать по этому вопросу подробнее): сущности нам рано или поздно всё равно необходимо создавать. При отсутствии setter'ов (с чем я полностью согласен) очевидно, что при исключении фабричных методов (как было в моём примере) у нас по-идее остаётся два пути: либо передача данных в конструктор напрямую либо создание "пустой" entity и перевод её в нужное состояние через вызов соответствующего метода.
Однако (поправьте, пожалуйста, если я неправ), в первом случае мы должны будем где-то держать логику передачи данных в конструктор (и это может быть более одного места в коде приложения), а во-втором мы после создания "пустой" entity получаем её в потенциально невалидном состоянии что нежелательно.
Был бы очень благодарен за более подробный комментарий.
Да, забыл ещё один момент: поскольку этот код находится внутри класса Entity то в нём можно напрямую обращаться к приватным свойствам вновь созданной $entity, а значит не нужно делать кучу setter'ов которые могут привести entity в неконсистентное состояние.
class Entity {
// ...
public static function fromDTO(DataObject $dto) : self
{
$entity = new self();
// и здесь уже наполняю новый экземпляр данными из dto
return $entity;
}
}
Это позволяет сосредоточить логику передачи данных DTO -> Entity в одном месте
Ваш эффект полагается на поддержку субпиксельной точности для box-shadow, видимо Firefox это пока не поддерживает. Насколько я смог проверить через BrowserStack - в Safari вроде тоже не поддерживается.
Поскольку это фича браузера то остаётся только ждать пока реализуют, можно отправить им bugreport, благо issue tracker'ы для всех браузеров открыты.
vasx3, нативно, конечно, можно, в документации Symfony Security всё описано. Но из вопроса вроде бы следовало что в дебри Securiy вы лезть пока не хотите (иначе, как мне показалось, вопроса бы не возникло). В FOSUserBundle есть много для простого и быстрого старта.
В Sonata есть свой UserBundle, но он опирается на тот же FOSUserBundle.
