[Tickets #1568] NEW: Observer Mechanism Implementation

[bugs at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://dev.horde.org/horde/whups/ticket/?id=1568
-----------------------------------------------------------------------
 Ticket             | 1568
 Created By         | Carlos Pedrinaci <cpedrinaci at yahoo.es>
 Summary            | Observer Mechanism Implementation
 Queue              | Horde Framework Packages
 State              | New
 Priority           | 1. Low
 Type               | Enhancement
 Owners             | 
+New Attachment     | Observer.php
-----------------------------------------------------------------------


Carlos Pedrinaci <cpedrinaci at yahoo.es> (2005-03-17 01:30) wrote:

The Observer Design Pattern is a widely used technique for achieving
flexible yet efficient run time notifications of some changes/events
happened over some particular data/objects. An "observable" object has a
list of "observers" and, whenever the "observable" object is modified it
notifies each observer about the change so that they can act accordingly.

In pseudo-code .. this is the basic idea:

1.- Some modification over an object observed happens
2.- Look for this objects' observers
3.- For each of them: Notify Change

This is usually applied directly to the objects we wish to "observe" but in
the case of Horde that would be a real mess as it would involve modifying an
important number of objects. In order to adapt this pattern to Horde, I have
created the skeleton of a new framework package (see attachment) that
supports the storage of observers lists for each horde object based on the
datatree backend (this could of course be ported to others). That way, in
run time, when an object has been modified (e.g. an event has been added to
a calendar, a new message has been posted in an Agora thread, a Whups ticket
has been closed etc..) we can go and check in the Observers package whether
we have any observer whishing to be informed about such a change. Each and
every observer would then be notified thus triggering some updating
mechanism, like sending an e-mail to a user etc... 

Because communication between the different modules in Horde happens through
the different API's, it would make sense to add there a method for
performing the updates a la:

updateObjects(objectsIDs) {
 1.- Get the objects
 2.- Do some changes
 3.- Store the changes
}

Potential Uses:

1.- Support setting up watches over Agora threads
2.- Support this notifying users when an event has been added to their
calendar.
3.- Support the Thor project planning mechanism allowing the activation of
new tasks when their pre-conditions are fulfilled (i.e. previous needed task
is finished). 

Note: This would certainly solve your Planning vs. Workflow "problem"
Jason.

There are many other possible uses of such a functionality which I believe
would be really nice having.