Skip to content

Requirements analysis

Jump to bottom
Sylvain Schellenberger edited this page Sep 7, 2020 · 1 revision

The following document is an analysis of the code on last commit against the version 1 of the WP Notify requirements document

The notification model

The WPNotify_BaseNotification class is composed of a WPNotify_RecipientCollection class, a WPNotify_BaseMessage class and a WPNotify_BaseSender class

The notification is implemented as a composition of three components:

  • A collection of recipients, which will receive the notification
  • A message to be displayed
  • Information about the sender

Uses cases application

The composition principle would be key for implementing our uses cases while keeping code duplication minimal as we could reuse behaviors from one notification type to another.

The different notification types are composed of two variations of recipients collection and messages types.

The example above shows how we could implement the WPNotify_RecipientCollection and WPNotify_Message interface only twice, and to compose our five uses cases by combining these two separate behaviors.

This would also ease the changes if our cases evolve during the project life-cycle.

Requirements observations

  • 5.1.A: Because the WPNotify_Notification interface extends both JsonSerializable and WPNotify_JsonUnserializable interfaces, we have a guarantee that any notification instance could be serialized.
  • 5.1.B: The Recipient interface is implemented as a RoleRecipient and a UserRecipient, and a CapabilityRecipient could be implemented as well to validate 4.2 - Backend.B.
  • 5.1.C: The status property is actually tied to the WPNotify_Notification. So we either have to duplicate a notification for each of its recipients, or store the status in the recipients instead.
  • 5.1.D: This could be done by creating a persistence layer for recipients, but is out of the scope of this code. The sender information could be a factor to select these different notifications, but:
    • It is hardcoded in the current state of the code.
    • It will require plugins and theme authors to play 'by-the-book' and registers their own senders.

Two levels of API

5.3.A: The draft for the (unimplemented) API defines a very easy to use interface for entry-level programmers:

/**
 * @param int|string|array|WPNotify_Recipient $recipients can be a user ID, a role string, an array of user IDs or role strings, or an instance of an object implementing the WP_Notification_Recipient interface.
 * @param string|WPNotify_Message $message can be string or an instance of an object implementing the WP_Notification_Message interface.
 **/
wp_notify( $recipients, $message )

The procedural API calls to the aggregate notification factory, that allows plugins to register their own notification factories

5.3.C: My guess is that this function is intended to use a WPNotify_Factory behind the scenes, or more precisely, the WPNotify_AggregateFactory, that may allow each plugin to registers its own WPNotify_Factory to tailor the notification creation to its needs, or just to identify its own notifications.

Persistence

4.2 Backend C: The WPNotify_NotificationRepository defines an interface to implement the different persistence mechanism, although it not defined how it should interface with the rest of the code at the moment.

Home

Clone this wiki locally