PHP: механизм правил стиля Outlook - PullRequest
Новая
       9

PHP: механизм правил стиля Outlook

2 голосов
/ 12 марта 2009

Я пытаюсь построить основанную на правилах систему для интерпретации данных. Однако у меня возникают проблемы при выборе способа построения логики для хранения и интерпретации правил.

В настоящее время существует довольно сложная структура базы данных, которая будет охватывать все аспекты хранения данных правила. Идея состоит в том, что система сможет имитировать способ, которым MS Outlook позволяет пользователю добавлять правила.

Мои проблемы заключаются в следующем:

  1. Какой шаблон я должен использовать для хранения этих правил внутри объектов?
  2. Должен ли я использовать eval () или правильную ориентацию объекта для выполнения правил?

И пример правила может быть:

Собака должна иметь ошейник в области парк

Где каждый элемент (собака, должен иметь ошейник, в области, парк) представляет собой отдельный кусок логики для интерпретации.

Любые общие советы по вышеуказанным вопросам очень ценятся!

Ответы [ 2 ]

1 голос
/ 12 марта 2009

Возможно, этот ответ слишком тривиален / очевиден для вас, но я просто подумал, как бы решить что-то подобное в моем текущем существующем проекте, который является приложением Zend Framework. Я думал о фильтрах и валидаторах, которые использует ZF. Я предполагаю, что у вас есть конечное число возможных входных объектов, конечное число условий / ограничений и конечное число действий. В этом случае вы должны сначала создать экземпляр объекта и запустить его в цепочке условий (валидаторов), если все условия выполнены, вы запускаете объект против actionChain. Здесь я, вероятно, должен был бы внедрить какую-то систему приоритетов действий, поскольку некоторые действия должны выполняться раньше других. Например, «отправить уведомление», а затем «удалить» рассматриваемый объект. Так что в ZF я бы создал собственный валидатор для каждого условия / ограничения. Я не верю, что система Outlook очень интеллектуальная, а это значит, что я не считаю валидаторы очень общими.

В БД может быть таблица для фактических правил, одна для условий и одна для действий. Тогда может быть две таблицы «многие ко многим», связывающие правило со всеми необходимыми условиями и действиями.

1 голос
/ 12 марта 2009

Я никогда не реализовывал такую ​​систему, как вы описываете, в контексте «реального мира», но я играл с ними немало в качестве хобби-проектов. Мой предпочтительный подход - использовать какой-то логический язык, такой как Пролог , чтобы делать утверждения и проверять их. У вас будут утверждения о том, где находится парк, что значит иметь что-то, что такое собака, и тогда вы создадите правило, очень похожее на ваш пример в скобках внизу вашего поста. Извините, мой Пролог слишком ржавый, чтобы дать вам полезный пример ... Я слишком долго играю с доморощенными языками вывода.

Существуют интерпретаторы Prolog, доступные для встраивания в большинство языков, хотя я не уверен насчет PHP5. Вы можете собрать что-то простое, что делает вывод с прямой связью в структурах данных правил вашего собственного создания в довольно короткие сроки, если вы не можете найти интерпретатор Prolog. Вас могут заинтересовать эти заметки по автоматическому выводу.

...