Kohana Forums

Сам когда-то искал пошаговое руководство по кохане, думаю и сейчас многим пригодится. Сам так и не собрался написать, но нашел в сети: http://devcookbook.net

P.S.: понравилась идея с кешированием страниц. Считаю, что правильнее в кеше хранить данные, но иногда можно и полностью страницы (статичные, например).

Раз Вы считаете, что

в принципе как начальное руководство неплохо

, то добавлю его.

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

>1. Откуда контроллер знает логику модели? Какова максимальная длина полей, к примеру.

Ну так это и закладывается в валидацию, верно? Как-раз модель не должна заботиться, не прислали ли ей слишком длинную строку или строку вместо числа.

>2. Модель может редактироваться/создаваться из разных контроллеров - как тут быть? Копировать правила из одного места в другое? Не DRY :)

Как раз для этих случаев у меня правила валидации находятся в отдельном файле, вот в таком виде(application/config/validation/user.php):

<?php<br />
return array(
'username' => array(
'label' => 'Ваше имя',
'rules' => array(
'not_empty' => NULL,
'alpha_numeric' => NULL,
'min_length' => array(3),
'max_length' => array(32),
),
'filters' => array(
'trim' => NULL,
'Common::enhtml' => NULL,
),
'callbacks' => array(),
),
'wmr' => array(
'label' => 'Ваш WMR-кошелек',
'rules' => array(
'not_empty' => NULL,
'alpha_numeric' => NULL,
'exact_length' => array(13),
),
'filters' => array(
'trim' => NULL,
'Common::enhtml' => NULL,
),
'callbacks' => array(
'Validation_Callbacks_Users::validate_wmr'
),
),
);

Соответственно - никакого копирования и т.д.

>3. Вообще, я бы не стал полагаться на то, что данные в модель всегда будут передаваться очищенными.

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

>4. Несколько функций валидации - это Вы про случаи, когда отдельно идет валидация при смене пароля/емейла? Так это все равно можно по уму сделать более удобно, чем в контроллере. Модель содержит все возможные правила валидации, разбитые по полям, а потом просто выдергивает необходимые.

Вот как-раз "Модель содержит все возможные правила валидации" мне и не нравится. Модель разрастается как на дрожжах, а толку - ноль. А если модель будет наследоваться - все это будет тянуться в новую модель мертвым грузом. Плюс, хранить в каждой модели свои функции валидации - не айс.

Толще модель — тоньше контроллер. Тоньше контроллер — проще поддерживать. Проще поддерживать — проще приложение. Ну а последнее — одна из причин использования фреймворка в построении серьёзного приложения, как мне кажется.
Да и проще модель подковырнуть при каких-то проблемах с выдаваемыми её данными для многих контроллеров, нежели пробегаться по всем используемым её контроллерам. А так как модель "толстая", то и разобраться в ней проще — видно все взаимодействия с базой и понятна бизнес логика (особенно при грамотном документировании).
Имели когда-нибудь приложение с парой-тройкой десятков контроллеров с пересекающимися данными, построенными по принципу валидации в них самих? Это ад их мэинтенсить! :)

p.s. Опять оффтопный холивар вокруг нахождения валидации намечается?:)

>1. Как это не должна? А зачем тогда модель (точнее драйвер DB) автоматом экранирует введенные данные? Или это все лишние телодвижения и все должно происходить в контроллере, а драйвер просто "не должен заботиться"?

Верно, автоматом, а не правилами валидации. И причина здесь абсолютно понятная, никак не относящаяся к валидации, верно? =)

>2. Лишние обращения к ФС, по сути - костыль.

Тогда весь фреймворк - костыль. Любое телодвижение = подключение нескольких файлов, верно?

>Ограничения полей в таблице БД никаким образом не относятся к контроллеру. Контроллер должен просто пользоваться "рычагами", предоставляемыми моделью, а не указывать, что и как там лежит.

А это и не относится к контроллеру - разговор про валидацию. Ограничение полей идет в валидации, а вот где вызывать валидацию - есть предмет нашего разговора ;). Я считаю, именно в контроллере. Например, незачем в модель передавать несколько принятых файлов (картинок), когда надо только проверить права пользователя...

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

Зачем прописывать все это в модель, если не использовать в ней валидацию? Что-то я не понял этого предложения...

>3. См. п1. Помним о том, что любой посторонний (т.е. не написанный нами изначально) код в приложении (например плагин) может обращаться к модели. Тут уж нас не спасет знание того, какие правила в модели должны были быть.

Убил бы за это... А как же кеширование, например? Любой плагин может сменить любые данные без ведома движка? Бред полный...

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

Вот именно поэтому не должна быть валидация в модели... Как же фильтры, колбаке и пр.? У меня нет отдельного метода в контроллере для валидации - считаю это абсолютно лишним.

>В итоге скатываемся к спору о "толстых" моделях.

"В споре рождается истина" (с) не_помню_кто...

>Толще модель — тоньше контроллер. Тоньше контроллер — проще поддерживать.

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

>Да и проще модель подковырнуть при каких-то проблемах с выдаваемыми её данными для многих контроллеров, нежели пробегаться по всем используемым её контроллерам.

Вот-вот... Именно поэтому модель должна быть простой и надежное, без лишних телодвижений.

>Имели когда-нибудь приложение с парой-тройкой десятков контроллеров с пересекающимися данными, построенными по принципу валидации в них самих? Это ад их мэинтенсить! :)

Каждый день имею опыт работы с приложением из десятка контроллеров + десяток-полтора моделей со встроенной валидацией - досталось "в наследство". И прекрасно понимаю что это такое. Поэтому и считаю, что валидации в модели быть не должно - модель должна получить чистые и проверенные данные и выдать результат по ним...

>Все - в шаблоны! :)

Не поверишь, но даже такой подход имеет право на жизнь. Встречал фреймворк на данном принципе, к сожалению не помню названия...

Единственный имеющийся у меня рычаг - созданная отдельная дискуссия :)

@AeR
Скажем так, это первый ресурс после http://kohanaframework.org/guide, который обязан посетить любой Kohana-программист :)