sim3x: От области знаний тема не особо зависит на мой взгляд. Функциональные модули и архитектура в целом - едина для любой области. Сама база знаний может быть специфична для некоторых сфер, но вопрос сейчас не в этом.
На данный момент задача - разработка экспертной системы. Эта задача решена на 99%, сейчас наполняется база знаний.
В процессе работы над системой, появилось понимание потенциала сервиса, поэтому прежде чем двигаться дальше решил изучить тему, что не нагородить велосипедов и граблей. Тема довольно старая, с точки зрения теории. На практике же пока вырисовывается картина, что есть несколько серьезных систем естественно коммерческих и с закрытым кодом, и ощущение, что никто в open sorce за подобные задачи не берется.
С мат. частью более-менее понятно, много общих вопросов в теории рассмотрено в интернете. Есть и схемы работы с разделением на модули и описанием взаимодействия между ними.
Вопрос именно в практике, в примерах так сказать. Хочется посмотреть, как сделано у других, чтобы у себя сделать лучше.
Разница наших решений в том, что вы напрямую чистите контент, а я вызываю метод плагина, который по идее делает тоже самое. Вот только делать он может больше, кеш какой-нить чистить например. Если не вникать в код плагина, то ваш вариант может глючить в каких-то гипотетических ситуациях.
Нее, я вас категорически не понимаю!
Хочется изящного? Пишите просто, понятно и масштабируемо (как для себя, так и для других, с кем работаете), а не выдумывайте сложности на пустом месте, это ли не изящность кода?
Ну дак и я о том же, смысла в тесте нет! Либо есть привязанная модель, либо ее нет. Если есть - ее тип и так известен, если нет - то null, если связь обязательно должна быть - это ошибка, но ошибка, на мой взгляд, не тут и тестить этот момент нужно не тут, а при добавлении например (если модели всегда добавляются парами), или тестить именно то, что null обрабатывается при выборке и не ложит все остальное.
Ну ок.
Если у вас определена связь (getCar(){...}), вы так-же можете обращаться к связанному элементу, как $this->car... Зачем вам его заранее то загружать?
Я чутка поторопился и не совсем правильно написал. Паулус ниже уточнил.
Это - if (!$this->save()) {...}, тоже нужно выкинуть и сделать так - $this->save().
Получается следующее, если save() не сработал, он выбросит ексепшен, в catch'е он отлавливается, смотрим и что-то делаем, если нужно - профит!
Тогда уже так:
public function rules() {
return [
//...
['username', 'unique', 'targetClass' => Users::className(), 'message' => 'Имя пользователя уже занято', 'filter' => ['!=', 'id', $this->id]],
//...
];
}
и не надо ничего никуда копировать.
Ок, будем считать, что я прописал 2 сценария insert и update, у всех правил выше указал on => 'insert'. Все отлично, все работает, но для update нет никаких проверок. И вот теперь вернемся к вопросу и немного его переформулируем, получится "Как прописать rules() для сценария update?"
Про роли читал. И правило это как раз для insert. Но, как должно выглядеть правило для update, я не понимаю, ведь по сути все должно быть тоже самое, только валидатору как-то нужно сообщить что текущую запись при проверках нужно пропускать.
