Посмотрите по в ссылке на гитхабе, как авторы книги DDD in PHP реализовали User->Wish отношения. Они используют one-to-many through join table И передают UserId в сущность Wish, при это делая мапинг foreign key на проперти объекта.
1. наоборот, одно правило содержит несколько нарушений, ну не суть
2. external mapping согласен, только он
3. разве это правильно хранить объекты внутри агрегата, а не айдишники?
По поводу изначального вопросы: Агрегат - это совокупность сущностей, где есть главная сущность (Aggregate Root), которая управляет всеми другими внутри области "ее действия". Это все понятия DDD *Domain Driven Design". (здесь не Агрегация, а именно Агрегат).
Если забыть про все эти термины, сформулирую вопрос еще раз по-простому:
У меня есть сущность Rule (Правило), есть зависимые от нее сущности Violations (Нарушения правила). Вопрос в том, какой тип связи у них должен быть в рамках Doctrine ORM.
Как я написал выше в исходном вопросе, типов связи может быть как минимум 2 (см.выше).
Мой главный вопрос, как построить маппинг (организовать код сущностей в связке с Doctrine) для отношения Rule <-> Violation, учитывая то, что Violation НЕ должен ничего знать о Rule, но в тоже время нам надо понимать какие Violations относятся к конкретному Rule.
Следуя тенденциям современного написания кода, и толкованиям DDD, сущности инициализируются полным набором данных используя конструктор, т.е. не имеют сеттеров. В связи с этим дополнительный вопрос - должны ли мы иметь `ruleId` внутри сущности Violation и как всё это ложится на мапинг Doctrine
leventov: спасибо за ваши ссылки - интересный пост про открытый код.
Но почему я должен разочароваться? Вопрос о монетизации не стоит. Всё что я хотел бы получить от открытия кода - это возможные пул реквесты. Шанс, что они будут, не равен нулю. Почему на ваш взгляд открывать код "почти бессмысленно" (опять же, учтите что я не заинтересован в монетизации)?
WarGot: хороший довод по поводу ссылок и языка в урле. Вобщем провел я несколько часов, настроил Apache так, чтобы он брал значение языка из куки, создавал кастомный header "X-Language", и добавил Vary: X-Language. В теории это позволяет делать версии одной страницы для каждого языка, а на практике - страница кешируется, и браузер потом отдает свой локальный кеш, "не пуская" запрос далее до Apache.
Я в полном непонимании как решить эту проблему :) Что-то фундаментальное упущено
С технической точки зрения, погуглив, это осуществимо. Теперь хочется понять - а хорошая ли это практика иметь дело с куками на уровне прокси? Или все же вариант, когда язык указан в URL лучше?
1. Приведите полный вывод стек трейса, в том что вы привели - нет самого текста ошибки.
2. Приведите пожалуйста только строки, на которых появляется ошибка (а не весь файл).
3. Вы специально пишите в конце debug_print_backtrace()?
Матвей Моя цель в привлечении новых клиентов, т.к. показалось, что данная функция будет заметно отличать мой сайт от других, но судя по высказавшимся - это никому не нужно :) Спасибо за советы, видно что вы в теме.
m0rd Хотелось бы думать что до этого никто не додумался, но по отзывам - это банально никому не надо. Спасибо за участие.
m0rd Я понимаю ваше недоумение :) Захотелось мне узнать мнение людей, все-таки как то причастных к IT. Действительно ли это модно сейчас, и стОит ли на это тратить время.
Да хотя бы - будет ли данная фича выделять как-то сайт из множества других, или это никому не надо впринципе..?
Здравствуйте,
цель не уйти от атак, а предоставить пользователям возможность сохранять свои задачи в зашифрованном виде, чтобы они знали, что только они могут прочесть свой контент, и даже администратор сайта имея доступ к БД не сможет этого сделать.
Тут именно вопрос в том, "а нужна ли эта фича с шифрованием на клиенте и записи зашифрованных данных уже на бекенд"?
Спасибо за комментарий, очередной голос в пользу "не делать".
1. А почему защищенный не получится? Дело то нехитрое зашифровать на клиенте и сохранить зашифрованное на бекенде. Повторюсь, ключ знает только пользователь и никогда не сохраняется он в БД.
2. > "Бесполезное шифрование только добавит багов" - прокомментируйте пожалуйста подробнее, почему бесполезное. Наверно я ошибся в предположениях, но думал что люди помешаны сейчас на том, что бы их контент никто не мог прочитать, и такое шифрование только помогло бы в этом.
Проапдейтил тело вопроса, посмотрите обновление, пожалуйста. Что касается фильтров - в этом бандле же и используется свой фильтр. Он по идее все и делает необходимое, да только сконфигурировать все правильно не получается.
В dev окружении данный фильтр не отрабатывает, это верно. Смотрите апдейт вопроса.
Вот это и вызывает вопросы и недопонимание