Development

Changeset 3572 for plugins/sfPropelNotificationPlugin

You must first sign up to be able to contribute.

Show
Ignore:
Timestamp:
03/04/07 13:22:08 (6 years ago)
Author:
tristan
Message:

sfPropelNotificationPlugin :

  • Wrote new notification backend howto
Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved
  • plugins/sfPropelNotificationPlugin/README

    r3571 r3572  
    181181=== Implementing a new notification backend === 
    182182 
    183 TODO. 
     183It is possible to create new notification backends. Let's see how to create a (fake) XMPP notification backend. 
     184 
     185 * Specify new backend in application's `config/sfPropelNotificationPlugin/backends.yml` : 
     186  
     187{{{ 
     188xmpp: 
     189  enabled: on 
     190  class: FakeXmppNotificationBackend 
     191  params: 
     192    server: jabber.example.net 
     193    user:   bot@jabber.example.net 
     194}}} 
     195 
     196 * Implement the `FakeXmppNotificationBackend` class : 
     197 
     198A few notes :  
     199   * Notification backends should extend the `sfPropelNotificationPluginAbstractBackend` class. 
     200   * Notification backends must implement a `notify()` method. 
     201   * The `getParameter()` method grant access to parameters defined in the `params` section of backend's specification 
     202 
     203{{{ 
     204#!php 
     205<?php 
     206class FakeXmppNotificationBackend extends sfPropelNotificationPluginAbstractBackend 
     207
     208  /** 
     209   * Sends a IM message to user related to given watch. This a totally fake implementation. 
     210   *  
     211   * @param     Watch        $watch 
     212   * @param     BaseObject   $object 
     213   */ 
     214  public function notify(Watch $watch, BaseObject $object) 
     215  { 
     216    // class initialization 
     217    $xmpp = new SomeXmppLib(); 
     218    $xmpp->setServer($this->getParameter('server'));     
     219    $xmpp->setUser($this->getParameter('user')); 
     220 
     221    // Make useful information available to action 
     222    $request = sfContext::getInstance()->getRequest(); 
     223    $request->setParameter('watch', $watch); 
     224    $request->setParameter('object', $object); 
     225 
     226    // Build message body 
     227    $controller = sfContext::getInstance()->getController(); 
     228    $msg_body = $controller->getPresentationFor('sfPropelNotificationPluginBackends', 'FakeXmpp'); 
     229    $xmpp->setBody($msg_body); 
     230     
     231    // Send the message 
     232    $xmpp->setDestUser($watch->getUser()->getJabberAddress()); 
     233    $xmpp->send(); 
     234     
     235  } 
     236
     237}}} 
     238 
     239 * You now add a `FakeXmpp` action to plugin's `sfPropelNotificationPluginBackends` module : 
     240 
     241This action will take care of building message body depending on notification type, object that triggered notification and  
     242user who will receive the notification. 
     243 
     244{{{ 
     245#!php 
     246<?php 
     247class backendsActions extends sfPropelNotificationPluginBackendsActions 
     248
     249 
     250  public function executeFakeXmpp() 
     251  { 
     252    // We don't want a layout 
     253    $this->setLayout(false); 
     254     
     255    // Make useful information available to view 
     256    $this->watch = $this->getRequestParameter('watch'); 
     257    $this->object = $this->getRequestParameter('object'); 
     258     
     259    // Build template name depending on notification type 
     260    $this->setTemplate(sfInflector::camelize($this->watch->getWatchType())); 
     261  } 
     262 
     263
     264}}} 
    184265 
    185266== Changelog == 
     
    189270 * removed hardcoded "User" model 
    190271 * wrote installation docs 
    191  * started writing usage docs 
     272 * wrote usage docs 
    192273 * deprecated sfUser::getId() / getPeerClass() in favor of getAttribute() + plugin namespace 
    193274