hook и ООП

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

Никогда не понимал зачем загонять себя в рамки только для того чтобы "все было правильно". :)

Ок, ну пусть даже мы загоним себя в рамки столь простых проектов в которых плагины и виджеты так редки что если один плагин в проекте и будет, то это круто... и значит конфликтов никаких не будет в нескольких хуках одного и того же метода.

Опять таки изменение правил роутинга будет делаться в ЧУЖОМ коде :)

В результате гоняясь за более "правильным ООП" мы лишимся главного преимущества ООП - скрытия внутренней структуры.

mendel, ок, ладно оставляю вас вариться в собственном соку, но все же посоветовал бы вам глянять как реализованы современные фреймворки и на подходы в них, ибо у меня складывается впечатление, что вы пишете очередную дле :)

p.s. Я бы предложил позадавать вопросы на phpclub.ru - всё же там профессиональных php-программистов на единицу площади намного больше чем на сёрче.

mendel, если чесно ничего не понятно, абсолютно... какой конфиг? по крайней мере я вижу около 'ньюз' вызвать 'ньюз2лог'...

кстате, не для спора, хотите посмотреть одну реализацию которую я увидел пару месяцев назад на perl'овом фреймворке?

распределенное ООП какое-то своеобразное...

записать так:

  sub blog : Chained PathPart('blog') CaptureArgs(0) { }


  sub user : Chained('blog') PathPart('user') CaptureArgs(1) {
      my ( $self, $c, $id_un ) = @_;
      $c->stash->{ message } = "Hello ";
      $c->stash->{ arg_sum }->[0] = $id_un;
  }




  sub view : Chained('user') PathPart('view') CaptureArgs(1) {
      my ( $self, $c, $id ) = @_;
      $c->stash->{ message } .= "World!";
      $c->stash->{ arg_sum }->[1] = $id;

  }







  sub view_page_off : Chained('view')  PathPart('') Args(1) {
      my ( $self, $c, $page ) = @_;
      
      $c->stash->{ arg_sum }->[2] = $page;
      
   $c->forward( 'view_blog_message', [ @{$c->stash->{ arg_sum }} ] );
    
  }
  


  

  sub view_off : Chained('view') PathPart('') Args(0) {
      my ( $self, $c ) = @_;

   $c->forward( 'view_blog_message', [ @{$c->stash->{ arg_sum }} ] );
   
  }



  sub view_page_user : Chained('user') PathPart('') Args(1) {
      my ( $self, $c, $page ) = @_;

      $c->stash->{ arg_sum }->[1] = $page;
      
# print '99';
   $c->forward( 'view_blog', [ @{$c->stash->{ arg_sum }} ] );
   
  }
  


  sub view_user : Chained('user') PathPart('') Args(0) {
      my ( $self, $c ) = @_;

   $c->forward( 'view_blog', [ @{$c->stash->{ arg_sum }} ] );
   
   
  }
  

все вызывается по очереди и можно прицепить к $c->stash (т.н. виртуальному методу)

и методы будут вызыватся так, друг за другом, как роли... красиво получается

| Path Spec                           | Private                              |
+-------------------------------------+--------------------------------------+
| /blog/user/*/view/*                 | /blog/blog (0)                       |
|                                     | -> /blog/user (1)                    |
|                                     | -> /blog/view (1)                    |
|                                     | => /blog/view_off                    |
| /blog/user/*/view/*/*               | /blog/blog (0)                       |
|                                     | -> /blog/user (1)                    |
|                                     | -> /blog/view (1)                    |
|                                     | => /blog/view_page_off               |
| /blog/user/*/*                      | /blog/blog (0)                       |
|                                     | -> /blog/user (1)                    |
|                                     | => /blog/view_page_user              |
| /blog/user/*                        | /blog/blog (0)                       |
|                                     | -> /blog/user (1)                    |
|                                     | => /blog/view_user                   |
'-------------------------------------+--------------------------------------'

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

rtyug, в PHP5 это реально и активно используется в фреймворках в той или иной форме, вот как раз пишу проект на Yii, строчка оттуда:

Здесь модель Listen получает данные из таблицы по примари кей, и соединяёт параллельно данные из другой таблицы по relation 'listenname'.

Если мы хотим чтобы присоединение принудительно осуществлялось одним запросом, то меняем на такое

Надеюсь я правильно понял, что имелось в виду :)

ну я написал как раз что не для спора, а именно толкунуть идею ТС, чтобы его ядро получало url /blog/user/*/view/*/* ( /blog/user/1/view/22/333 ) и чтобы "толкало" ("диспатчиризировало", dispatch) между классо(а)м(и)

в данном случае класс blog и методы user и view (или алиасы) и количество параметров в них соответственно '1' '22' '333'...

с Yii я не знаком, знаком с ним со всем не много, я читал полностью всю документацию по Symfony и Zend, и смотрел написанные на нем сайты, только на 100% не приходилось с ними двумя работать, к сожалению, попадались уже готовые движки написанные кем-то на php...

вы написали про таблицы и primary key, но тут имелось ввиду url путь /blog/user/*/view/*/* (с mod_rewrite или на прямую с apache)

извините, если забыл написать что это именно url

mendel вы немного видать не понимаете саму суть механизма событий, на которую вам намекает Dreammaker, к примеру по поводу такого:

в таком случае Dreammaker в своем блоге должен прописать какие могут быть события, в каких местах они вызываются ну и соответственно написать документацию :)

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

тут по подробней про события и поведения в Yii

JTRTA, а чем это не хук? :)

Я ж изначально об этом и веду речь... а Dreammaker, уводит разговор в переопределение методов и т.п.

Суть вопроса то в чем - если мы обрабатываем хуки/события например так то к чему привязывать событие/хук в случае объекта?

Это может быть как метод класса так и метод экземпляра...

Ну пусть будет хук на $user->read зарегистрирован.

Но $user у нас является экземпляром класса _db и у нас может быть также зарегистрирован хук на _db->read

физически то вызов обработчика идет один.

по идее тут напрашивается что сначала надо foreach для класса а потом foreach для экземпляра, но я не уверен что все учел... потому и спрашиваю :)

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

1) можно реализовать для базового класса(в Yii это CComponent) и затем создавая все классы путем расширения базового, отпадает вопрос а где же их обрабатывать, так как имеем единый механизм работы с ними

2) гибкий механизм добавления новых событий и их обработчиков

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

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

Хуки реально проще для восприятия, и как мне кажется лучше смотрятся во фреймворке с "низким порогом вхождения".

В простейшем случае

// прописываем хук в функции
function hook_me($var1,$var2,$var3)
    {
    $result = $var1 + $var2 + $var3;
    ....
    return $istio->hook($result);
    }
// регистрируем хук для нашей функции
$istio->hook('function','hook_me','hook4hook_me');
// объявим хук-функцию
function hook4hook_me($return,$args)
    {
    return $return/($args[0] + $args[1] - $args[2]);
    }

args мы получаем через debug_backtrace примерно так:

function hook($result){
	global $hook;
	$d_backtrace=debug_backtrace();
	$backtrace=is_array($d_backtrace[1])?$d_backtrace[1]:$d_backtrace;
	$functions=@$hook[$backtrace['function']];
	$args=$backtrace['args'];
	if(is_array($functions)){
		ksort($functions);
		foreach($functions as $function)
			if($function&&function_exists($function))
				$result=$function($result,$args);
	}
	return $result;
}

т.е. $istio->hook в зависимости от количества параметров и первого параметра либо регистрирует хуки (бывают еще хуки вьюва и модели) либо обрабатывает хук примерно так как описано выше....

Ничего сложного... для добавления хука делать не надо...

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

у хуков он не менее гибкий.

Другой подход, который не не применим в моей задаче. К чему он здесь? :)

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