Триггеры / обратные вызовы в Ruby on Rails - PullRequest
3 голосов
/ 18 декабря 2009

Мы создаем систему в Ruby on Rails, и мы хотим предоставить нашим пользователям немного контроля над уведомлениями и действиями, которые могут иметь место, когда происходит какой-то заранее определенный триггер. Кроме того, мы планируем перебирать импортированные данные и позволять нашим пользователям настраивать некоторые действия и триггеры на основе этих данных.

Позвольте мне привести несколько примеров, чтобы лучше уточнить:

Trigger                              - Action
------------------------------------------------------------------------
New Ticket is Created                - User receives an e-mail
New Ticket Parsed for Keyword 'evil' - Ticket gets auto-assigned to a
                                       particular group
User Missed 3 Meetings               - A ticket is automatically created

В идеале, мы бы хотели, чтобы некоторые триггеры были настраиваемыми. Например, последний пример, возможно, позволит вам указать, сколько встреч было пропущено до начала действия.

Мне было интересно, какие шаблоны могут помочь мне в этой ситуации события / обратного вызова в Ruby on Rails. Кроме того, триггеры и действия могут быть настраиваемыми, но они будут предопределены; так, должны ли они быть жестко запрограммированы или сохранены в базе данных?

Любые мысли будут с благодарностью. Спасибо!

Обновление 1: Посмотрев его, я заметил, что система значков в SO несколько похожа, и на основании этих критериев я хочу выполнить это действие. Это немного отличается, но я хочу иметь возможность легко добавлять новые критерии и действия и представлять их пользователям. Есть мысли по этому поводу?

Ответы [ 3 ]

4 голосов
/ 18 декабря 2009

Я думаю, что вы ищете Наблюдателей. В ваших примерах наблюдатели могут обрабатывать первый и третий примеры (но не второй), поскольку наблюдатель только наблюдает за объектом, но не взаимодействует с ним, даже если это технически возможно).

Код, показывающий, как я имею в виду:

class TicketObserver < ActiveRecord::Observer
  def after_create(ticket)
    UserMailer.deliver_new_ticket_notification
  end
end

class UserObserver < ActiveRecord::Observer
  def after_update(user)
    Ticket.new if user.recently_missed_a_meeting and user.missed_meetings > 3
  end
end

А затем добавить наблюдателей в environment.rb

config.active_record.observers = :user_observer, :ticket_observer

Конечно, вам придется заполнить логику для missed_meetings, но одну деталь упомянуть. Поскольку after_update будет срабатывать после каждого обновления пользователя, атрибут recently_missed_a_meeting полезен. Я обычно придерживаюсь мысли о restful-аутентификации и у меня есть переменная экземпляра, которая устанавливается в true каждый раз, когда я хочу вызвать эту строку. Это может быть сделано в обратном вызове или в некоторой пользовательской логике, зависит от того, как вы отслеживаете встречи.

А для второго примера я бы поместил его в обратный вызов before_update, возможно, с ключевыми словами в справочной таблице, чтобы пользователи могли обновить, какие слова должны вызывать перемещение в конкретную группу.

1 голос
/ 18 декабря 2009

Вы должны посмотреть на методы "обратного вызова" в Rails

Документы см. - Обратные вызовы

Ваше первое правило будет реализовано с помощью метода after_create.

Если вы хотите, чтобы их можно было настраивать, я бы предложил использовать модель / таблицу для хранения возможных действий и выполнить поиск в обратном вызове.

Если это большой объем, обязательно рассмотрите возможность кэширования конфигурации, поскольку в конечном итоге она будет выполнять поиск в БД для каждого обратного вызова.

0 голосов
/ 18 декабря 2009

Может быть, что-то вроде конечного автомата может помочь. Попробуйте AASM для RoR.

...