Hi Joe, Please ask this question on the symfony-users mailing list.
Thanks, Kris -- Kris Wallsmith | Community Manager [email protected] Portland, Oregon USA http://twitter.com/kriswallsmith On Jun 25, 2009, at 10:40 AM, JoeZ wrote: > > I just wanted to use the symfony 1.2 events extension mechanism with a > propel object. > > I know there are several other ways, like propel behaviors and so, but > I just don't want to use such a heavy machinery for what I want to do. > > I want an event to be fired when the method "setDesync()" of the > "recurringInvoice" propel object is called. This way, the app can take > some counter-measure when a recurring invoice goes out of sync for > some reason. > > In the docs, they introduce the "dispatcher" object like this: > > ... > class sfRestRequest > { > protected $dispatcher = null; > > public function __construct(sfEventDispatcher $dispatcher) > { > $this->dispatcher = $dispatcher; > } > .... > } > > like if the $dispatcher is supposed to be automatically passed to the > class constructor. > well, maybe all the classes which inherits from sfRequest have that, > but it didn't work for my propel object, I guess the constructor > doesn't get any $dispatcher object passed to it by default. > > So I got it through the sfContext singleton: > > > class RecurringInvoice extends BaseRecurringInvoice > ... > protected $dispatcher = null; > ... > > public function __construct() > { > $this->dispatcher = sfContext::getInstance()->getEventDispatcher(); > parent::__construct(); > } > ... > ... > public function setDesync($v) > { > if($v) > { > $this->dispatcher->notify(new sfEvent > ($this,'recurring_invoice.desynchronized',array('id'=>$this->getId > ()))); > } > parent::setDesync($v); > } > > > it compiles at least. I didn't tested it yet, but when I used this > propel object inside a custom symfony task I was doing: > > > class CheckJobsTask extends sfPropelBaseTask > { > ..... > ..... > public function execute($arguments = array(), $options = array()) > { > ... > (all usual stuff to access database objects, etc ...) > ... > $this->inv = new RecurringInvoice(); > .... > > } > > I got the infamious "the default context doesn't exists" error. > > > I guessed it was because of the sfContext::getInstance call at the > propel object constructor, so I created the sfContext singleton within > the task: > > > public function execute($arguments = array(), $options = array()) > { > ... > ... > $configuration = ProjectConfiguration::getApplicationConfiguration > ($options['application'], $options['env'], true); > sfContext::createInstance($configuration); > ... > $this->inv = new RecurringInvoice(); > ... > } > > > and it worked!!! > > but the thing is. I already now all the tasks are able to throw > events. that means the have some kind of access to the dispatcher , so > what I want to do is to access the dispatcher from the propel object > without having to make a call to the sfContext singleton, just using > something that allow me to integrate it within a task seamlessly . > > > > txs in advance. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
