Кто-нибудь может объяснить что это за зверь и с чем его едят?
Понятно что это объект который цепляется к компонентам типа АР, контроллер, модель и т.д.
а для каких целей это лучше использовать? какого рода функции лучше в него вкладывать?
Кто-нибудь может объяснить что это за зверь и с чем его едят?
Понятно что это объект который цепляется к компонентам типа АР, контроллер, модель и т.д.
а для каких целей это лучше использовать? какого рода функции лучше в него вкладывать?
Например несколько таблиц у тебя имеют поле UUID, которое служит для сокрытия ID.
Ну вот и пишется один раз унифицированный алгоритм, который при добавлении-обновлении записи меняет это поле UUID, а таблице просто назначается такой behavior.
Часто используется для: рейтингования, комментирования, тэгирования любой записи в любой таблице.
Vit, ты чего? Это к таблицам и БД отношения вообще не имеет.
Суть тут в другом. В Иии можноцеплять обработчики на некоторые события компонентов. Цеплять их надо после создания, то есть при содании должен быть дополнитеьный код. каждый раз как создаем. Это не очень удобно в большинстве случаев. Поэтому делается класс поведения, в котором методы являются обработчиками соответсвующих событий. тоесть "цепляем все пакетом". Прелесть в том, что это поведение может быть прицеплено в конфигурации компонента.
Другая прелесть в том, что можно прицепить несколько, отключать-включать их и т.п.
я не юзал, это теория
Пример испольщования есть в кукбуке для вставки даты модификации. Там ловится событие, которое генерирует компонент CActiveRecord.
мда, так и не понял есть ли вообще смысл их использовать
Ну под таблицами в БД я им в виду Модели по работе с ними.
Я симфонист, и сам еще не вникал как в ИИИ сделаны behaviors
Но судя по документации, сделаны они похожим способом как и в симфе.
behavior classes must implement the Ibehavior interface. Most behaviors can extend from the Cbehavior base class. If a behavior needs to be attached to a model, it may also extend from CModelbehavior or CActiveRecordbehavior which implements additional features specifc for models.
Если я все правильно понял мы просто начинаем писать пачками behavior(мля, как этта будет па рюсский) которые будут реализовать повторяющиеся операции, подходящие для разных моделей, я уже выше писал, для примера почти любой модели могут понадобиться следующие behaviors: TagAble, CommentAble, RateAble, BookmarkAble
Не совсем понял про твои Able?
Тэгируемый, Комментируемый, Рейтингуемый…
Представь себе что для подлючения рейтингования модели News тебе надо будет написать всего лишь:
[tt]CActiveRecordbehavior::attachbehavior('News', 'RateAblebehavior');[/tt]
Vit, а можешь привести какой-нибудь код примера?
Мне немного сложно представить как это будет выглядеть на уровне базы данных и на уровне контроллера.
Сразу оговорюсь что в Иии я этого не делал, я могу привести пример только из Симфони, например для тэгирования любой модели, в БД появляется 2 таблицы
tags:(тут копятся все тэги от всех моделей)
id
name
tagging:
id
tag_id
model ('Post', 'News', etc)
Назначение в модели типа: CActiveRecordbehavior::attachbehavior(‘News’, ‘RateAblebehavior’); добавляет к модели дополнительные методы типа getTags(), setTags(), getTagsCloud(), getTagsList()…
Ну и собственно остается в форму редактирования добавить поле 'tags' в него поместить значение $model->getTags(), а потом при сохранении записи убедиться что происходит
$model->setTags($_POST['tags']);
$model->save();
По идее все должно работать так…
Еще один пример на эту тему - новости и категории, свзяка many to many.
Вешаем behavior вставку/удаление/изменение новости и получаем возможность вносить изменения в связующую таблицу NewsCategory.
Очень понятно про поведения написано здесь. Суть в том, что php не поддерживает множественное наследование. (то есть нельзя унаследовать класс сразу от нескольких базовых). behavior’ы решают эту проблему. Они расширяют функционал класса, добавляя в него функционал другого класса. Существующие в расширяемом классе методы перекрыты не будут