Tickets :: Comment on [#1568] Observer Mechanism Implementation

* Your Email Address
* Spam protection	Enter the letters below: . ..__ __.. .. . \| \|[__)(__ \| \|\| \| \|/\\|\| \.__)\|__\|\|/\\|
Comment	> 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.
Attachment
Watch this ticket

Saved Queries