Find better terminology to use for classes representing the common patterns being used

[amoslanka]

I think there is better terminology to find for "NotificationType" and for "Translator"

Rename notification types to strategies.

Rename translators to adapters.

Though perhaps proxy is the truest description of what translators/adapters are doing:

A proxy, in its most general form, is a class functioning as an interface to something else.

These don't tightly fit the pattern descriptions but are clearer, don't clog the "notification" namespace and in the case of adapter, is a kinder sounding word.

[amoslanka]

Is the group of settings that determine how a notification is delivered better referred to as a set of rules or as a strategy?

[amoslanka]

Potential app/notifications dir:

app/notifications
  adapters
    push_adapter.rb
  policies
    user_preference_policy.rb
  strategies
    foo_strategy.rb

Namespaces for any of these suck because in these directories they shouldn't have Notify as the namespace.

Would be better as?

app
  notifications
    foo_notification.rb 
      # class FooNotification; extend Notify::Strategy; end
lib
  notify
    adapter
      action_mailer.rb 
        # class Notify::Adapter::ActionMailer; extend Notify::Adapter; end
      push.rb 
        # class Notify::Adapter::Push; extend Notify::Adapter; end
    policy
      user_preference.rb 
        # class Notify::Policy::UserPreference; extend Notify::Policy; end

[amoslanka]

Restructure

A strategy is an object that lives in app/notifications and is named <name>Notification. It extends Notify::Strategy, which defines the class methods available for defining strategy rules.

A notification should compose an ActiveRecord object Notify::Message, referring to it as record and delegating some instance actions to it. There should be no more Notifications namespace for Notify's models.

So a message is a model, not actually containing the message body, but representing a message being sent to a receiver and having attributes describing what the message is about. A Notification is a class that is defined by the user of the library, and contains a strategy, which is a subset of methods on the notification that outline how the message is delivered. An instantiated notification object is not an ActiveRecord object, but is more presentable than the Notify::Message or Notify::Delivery, since an instantiation composes a message and one or more deliveries.

You can create a notification by saying FooNotification.send_to users

You can still create a notification by saying Notify.create to: users, which will look up the strategy and delegate the parameters to it.

You can still create a notification by saying user.notify :foo, which similarly maps to the correct notification strategy.

Retrieving a list of notifications for a receiver is still retrieving an ActiveRecord::Relation, but by calling present on the relation or on an instance will instantiate and return the strategy with a reference to the record. This is how a coder might retrieve a list of notifications to render on a list of notifications the user has received.

At this point, the notification strategy is responsible the full process of creation and delivery. It should delegate each step to a class referenced object responsible for the task. (This is currently done in Notify.create).

This would be four main steps to creating a notification:

1. merge rulesets
2. create the record
3. create the deliveries
4. execute the deliveries

The logic (ignoring for the moment the Strategy module and use of the term as a definition of notification delivery rules) for each (save, perhaps, the strategy merge) could be referenced differently per notification type. Each step could be a particular algorithm out of a selection of algorithms to carry out the task.

Strategy instance methods

• rendering. A form of adapter for viewing on the web or immediately in the code, this adapter is always available directly from the presented notification for this purpose. Calling notification.render will automatically run it through a standardized view location (`views/notifications/') or with a specific view named in the strategy.

[amoslanka]

• [x] Rename NotificationType to Strategy
• [x] Rename Notification model to Notify::Message
• [x] Move creation logic to Strategy
• [ ] Notification presenter methods (later)