По сути события и хуки очень похожи и скорее всего являются промежуточным звеном развития до событийной модели, НО хуки это просто какие то функции вырывающиеся в определенном месте и соответственно появляются проблемы "а как добавить хук в другом месте?", "где их обрабатывать?", для механизма событий:
1) можно реализовать для базового класса(в Yii это CComponent) и затем создавая все классы путем расширения базового, отпадает вопрос а где же их обрабатывать, так как имеем единый механизм работы с ними
2) гибкий механизм добавления новых событий и их обработчиков
Просто описывает немного другой подход, обращаясь к тому же примеру попробую описать смысл:
что такое добавление комментария? я так понимаю должен быть специальный класс-модель отвечающий за выборку сохранение и другую работу с комментариями, а значит чтобы добавить комментарий в спец таблицу для модерации можно переопределить этот класс-модель добавив необходимую функциональность. Этот подход хорош конечно, но в случае если много добавочных модулей(как любят цмсники) захотят добавить свой кусочек кода каждый получится будет тянуть на себя одеяло и пытаться подключить именно свой класс-модель. Поэтому все таки надо стремиться к классической событийной модели.
mendel вы немного видать не понимаете саму суть механизма событий, на которую вам намекает Dreammaker, к примеру по поводу такого:
в таком случае Dreammaker в своем блоге должен прописать какие могут быть события, в каких местах они вызываются ну и соответственно написать документацию :)
Tarry берет и читает документацию, и если документация хорошо написана не открывая кода начинает просто регистрировать обработчики для соответствующих событий. Обработчиком может быть функция, метод класса, либо с пхп 5.3+ - анонимная функция. При этом совсем не обязательно переопределять базовый класс.
тут по подробней про события и поведения в Yii
через $_SERVER['HTTP_USER_AGENT'] можно вычеслить и браузер и его версию, остается только составить список с какой версии браузера появляется адекватная поддержка HTML 5
а поп поводу надо или не надо, например мой друг коммерсант в таких случаях говорит:
что люди разные бывают, одного пошлют с машиной обуви в Африку, он приедет увидит что все голые и без обуток ходят, скажит что нафиг обувь никто не купит, соберет вещи и уедет домой.
а другой увидит что все босые ходит, обрадуется что обуви пока ни у кого нету и начнет им впаривать в особо крупных объемах и по завышенной цене, а потом еще 3 машины обуви закажет привезти.
так что мне кажется всегда стоит поглядывать в сторону инновационных технологий уже очень скоро они займут свой кусочек интернета, в котором можно стать одним из самых успешных людей.
Юпи-с вы не понимаете что делая всякие трудности для копирования вы усложняете лишь жизнь пользователям которые, приходят к вам на сайт не для копирования а для получения информации. Кому надо копировать найдут 1001 способ содрать информацию и ничего тут не поделать. Наляпаете яваскриптов - посмотрят исходный код страницы или напишут бота который автоматически будет собирать инфу.
тут главное чтобы поисковики определили вас как первоисточник и пусть другие копируют сколько влезет, еще и можете связаться с владельцем сайта и потребовать чтобы оставляли ссылку на первоисточник
Интересно как это может не работать? может головой немного подумать?
сдается мне вы просто online.js не правильно подключаете.... В какой нибудь папке левой файлик создали, а ищите в той же папке где входной скрипт, или еще круче по вашему "туториалу" создали online.txt а подключаете online.js
Дешевле будет пивка попить в баре во дворе, а нестандартные задачи требуют не стандартных решений
Скоро будут за бутылку водки и соленый огурец предлагать работать 😂
Вроде бы надо сначала денег подкинуть, ток потом и он вам может насрать
я б даже со своими скудными знаниями фотошопа такой скрин нарисовал 😂
кто-нибудь в асю уже стучался загадочному дистрибьютору?
О боже мой откуда такая уверенность? Вы этот "качественный" код хоть раз открывали? процедурный стиль программирования, куча гавно кода для поддержки php4. может еще скажите грамотно разработана архитектура?
извините но этот код отстал во времени лет на 10...
Ну да ну да...если все стандартное и лежит в паблике сделайте проект и посмотрим при какой посещаемости он загнется...
Где то давно была статейка одного из разработчиков друпала, про то как друпал оптимизирован, там было переписано куча кода для ускорения в ущерб гибкости, были переписаны куча модулей чтобы они не обращались с одними и теми же запросами по 50 раз к БД. работали.
Элементарно подумайте структура на сайте не изменяется кучу времени, и зачем тогда вся эта гибкость и простое добавление модулей? зачем оставлять функциональность которая никогда не используется?
эффективность кэша зависит от многих параметров. Если у вас сайтом пользуются в основном зарегистрированные пользователи, то джумоловский кэш будет ну очень мало эффективен
