Эквивалент обратного вызова модели Symfony - PullRequest
0 голосов
/ 12 января 2010

Я работаю над проектом Symfony (мой первый), где мне нужно извлечь из моего класса Widget набор виджетов, принадлежащих Page. Однако прежде чем возвращать результаты, мне необходимо проверить - в отношении внешней службы - что пользователь имеет право просматривать каждый виджет. Если нет, конечно, мне нужно удалить виджет из набора результатов.

Используя CakePHP или Rails, я бы использовал обратные вызовы, но я не нашел ничего подобного для Symfony. Я вижу события , но они кажутся более подходящими для контроллеров / действий, если я правильно читаю (что всегда обсуждается). Мое альтернативное решение - переопределить различные методы поиска в классе WidgetPeer, перенаправить их через пользовательский метод, который выполняет авторизацию и соответствующим образом изменяет набор результатов. Это похоже на массовое излишество, так как мне пришлось бы переопределить каждый метод выбора, чтобы гарантировать, что авторизация была сделана без необходимости думать об этом будущим разработчикам.

Похоже, что поведения могут быть полезны для этого (особенно с учетом того, что возможно , что в будущем мне может понадобиться авторизовать другие экземпляры классов), но я не могу найти приличную документацию для них, чтобы сделать квалифицированная оценка.

Я что-то упустил? Кажется, должен быть лучший путь, но я его не нашел.

Ответы [ 3 ]

1 голос
/ 13 января 2010

Прежде всего, я думаю, что основанный на поведении подход неправильный, поскольку он увеличивает уровень связи между уровнями модели.

Существует sfEventDispatcher::filter() метод, который позволяет вам соответственно фильтровать передаваемые ему параметры.

Итак, черновик кода будет выглядеть так:

<somewhere>/actions.class.php

public function executeBlabla(sfWebRequest $request)
{
  //...skip...
  $widgets = WidgetPeer::getWidgetsYouNeedTo();
  $widgets = $this->getEventDispatcher()->filter(new sfEvent($this, 'widgets.filter'), $widgets));
  //...skip...
}

apps/<appname>/config/<appname>Configuration.class.php

//...skip...
  public function configure()
  {
    $this->registerHandlers();
  }
  public function registerHandlers()
  {
    $this->getEventDispatcher()->connect('widgets.filter', array('WidgetFilter', 'filter'));
  }
//...skip

lib/utility/WidgetFilter.class.php

class WidgetFilter
{
  public static function filter(sfEvent $evt, $value)
  {
    $result = array();
    foreach ($value as $v)
    {
      if (!Something::isWrong($v))
      {
        $result[] = $v;
      }
    }
  }
}

Надеюсь, у вас есть идея.

0 голосов
/ 13 января 2010

Хотя, по крайней мере в теории, я все еще думаю, что поведение - это правильный подход, я не могу найти достаточный уровень документации об их реализации в Symfony 1.4.x, чтобы дать мне теплый и неясный вопрос о том, что это может быть выполняется без изжоги, если вообще. Даже глядя на собственную документацию Propel о поведении, я не вижу никакой ловушки до или после извлечения, чтобы вызвать действие, которое мне нужно предпринять.

В результате я выбрал свой запасной путь. Однако после некоторого отсеивания исходного кода я понял, что это не так сложно, как мне показалось. Каждый метод поиска проходит через метод doSelect() модели BasePeer, поэтому я просто переопределил его в настраиваемой модели Peer:

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;
}

Я еще не связал сервисный вызов для авторизации, но, похоже, он работает должным образом для изменения наборов результатов. Когда и если мне придется предоставить авторизацию для дополнительных экземпляров модели, мне придется пересмотреть поведение, чтобы остаться СУХИМЫМ, но, похоже, до этого этого будет достаточно.

0 голосов
/ 12 января 2010

Вот некоторая документация по поведению Symfony 1.2 Propel: http://www.symfony -project.org / cookbook / 1_2 / en / поведение .

Почему бы не использовать метод getAllowedWidgets для объекта Page, который выполняет проверки, которые вы ищете? Что-то вроде:

public function getAllowedWidgets($criteria = null, PropelPDO $con = null) {
  $widgets = $this->getWidgets($criteria, $con);
  $allowed = array();

  // get access rights from remote service

  foreach($widgets as $widget) {
    // widget allowed?
    $allowed[] = $widget;
  }

  return $allowed;
}

Однако, если вы всегда хотите, чтобы эта проверка выполнялась при выборе виджетов страницы, то поведение Propel - ваш лучший выбор.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...