Я. Специально. Написал. В. Нескольких. Местах. Что. Это. ПСЕВДОКОД.Но вот смысла регистрировать отдельно notifyBoss и notifyUser да ещё и для каждого тикета отдельно - не вижу.
Я. Специально. Написал. В. Нескольких. Местах. Что. Это. ПСЕВДОКОД.Но вот смысла регистрировать отдельно notifyBoss и notifyUser да ещё и для каждого тикета отдельно - не вижу.
http://xkcd.ru/451/Про литературные изыски прикольно)))
Да ладно не гуди))) Идею я поддерживаю на 100% Нужна регистрация логики
имхо - не получится так волшебно, чтобы и регистрация ивентов была, и в одном месте логикаНужно вводить новое состояние задачи "приостановлено". И опять возникают вопросы поиска этих назначенных заданий для всех пользователей которые относятся к объекту (сейча тикету) и т.д и т.п.
Либо нужно в сами эти назначенные задания добавлять логику определения нужно ли отсылать для объекта извещения (а это ж вроде как раз то, от чего хотели уйти).
Ну ИМХО не нужно это всё. В одном месте всё должно быть.
В который раз убеждаюсь, спрашивающие на форумах, имеют кучу гонора и святую веру в непогрешимость собственной точки зрения.что существует помимо тех таблиц - вас волновать не должно.
в том-то и дело, что человек с датой регистрации 2004г очертил задачу более чем явно, дал список таблиц и описал их структуру.Если человек с датой регистрации 2004й год ведет себя так, то что можно требовать от начинающих?
да, пускай скрипт дёргается раз в минуту, как это принято в cron'е.И я вообще предлагаю выполнять её периодически не привязываясь к тому, были созданы тикеты или нет.
(Возможно не sendNotify а getAllNotify и рассылку отдельным модулем. Думать ещё надо.)Автор оригинала: Mols
....Думаю сделал бы интерфейс вида sendNotify и все объекты, которые могут потребовать извещений реализовывали бы этот интерфейс. А внутри sendNotify уже выполнялся бы поиск всех экземпляров по которым надо разослать извещения.
т.е. sendNotify - это интерфейс, который реализует "тикет" (класс ticket). и речь вроде идёт о конкретном экземпляре объектаДумаю сделал бы интерфейс вида sendNotify и все объекты, которые могут потребовать извещений реализовывали бы этот интерфейс.
а тут говорится о методе поиска объектовА внутри sendNotify уже выполнялся бы поиск всех экземпляров по которым надо разослать извещения.
Таблицу с извещениями - тоже думаю не очень сложно сделать.
если представить - что уведомление о тикетах - специфичная для сущности тикет задача (иными словами - в системе больше не будет подобных вещей), тогда можно события уведомлений писать в ticket_actions тожеНо думаю не составит труда заносить все действия над тикетом в ticket_actions и определить когда был добавлен исполнитель в тикет
приводя к нормали, описынные требования(с первой страницы) - поверка действий пользователя, будь то логин в систему, или просмотр тикета, оплата счёта.... зачем для этого создавать таблицы действие над тикетов, таблица входов, таблицу платежей. А какие случаи при эвенте делать, это уже другая задача, почти никак не связаная.Уходя от этого сферического примера: в интернете мне попадался ряд сервисов (из последних навскидку - livemocha.com), которые, после некоторого периода неактивности начинают напоминать о себе, расспрашивая почему ты перестал заходить и какие же они клёвые (теперь стали).