Question

I’m working on a Symfony project (my first) where I have to retrieve, from my Widget class, a set of widgets that belong to a Page. Before returning the results, though, I need to verify–against an external service–that the user is authorized to view each widget. If not, of course, I need to remove the widget from the result set.

Using CakePHP or Rails, I’d use callbacks, but I haven’t found anything similar for Symfony. I see events, but those seem more relevant to controllers/actions if I’m reading things correctly (which is always up for discussion). My fallback solution is to override the various retrieval methods in the WidgetPeer class, divert them through a custom method that does the authorization and modifies the result set appropriately. That feels like massive overkill, though, since I’d have to override every selection method to ensure that authorization was done without future developers having to think about it.

It looks like behaviors could be useful for this (especially since it’s conceivable that I might need to authorize other class instances in the future), but I can’t find any decent documentation on them to make a qualified evaluation.

Am I missing something? It seems like there must be a better way, but I haven’t found it.

Answer 1

Although, at least in theory, I still think that a behavior is the right approach, I can’t find a sufficient level of documentation about their implementation in Symfony 1.4.x to give me a warm and fuzzy that it can be accomplished without a lot of heartburn, if at all. Even looking at Propel’s own documentation for behaviors, I see no pre- or post-retrieval hook on which to trigger the action I need to take.

As a result, I took my fallback path. After some source code sifting, though, I realized that it wasn’t quite as laborious as I’d first thought. Every retrieval method goes through the BasePeer model’s doSelect() method, so I just overrode that one in the customizable Peer model:

static public function doSelect( Criteria $criteria, PropelPDO $con = null ) {
  $all_widgets = parent::doSelect( $criteria, $con );
  $widgets     = array();

  foreach ( $widgets as $i => $widget ) {
    #if( authorized ) {
    #  array_push( $widgets, $widget );
    #}
  }

  return $widgets;
}

I haven’t wired up the service call for authorization yet, but this appears to work as expected for modifying result sets. When and if I have to provide authorization for additional model instances, I’ll have to revisit behaviors to remain DRY, but it looks like this will suffice nicely until then.