Если бы вы внимательно прочитали статью, вы бы увидели, что HMVC — это не «возможность вызывать один контроллер из другого». Точнее, это лишь малая его часть. Вызвать один контроллер из другого дело нехитрое и ничем не отличается от обычного создания экземпляра класса:

$controller = new Controller;
$controller->action();

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

Спасибо за интересный перевод отличной статьи. Не поленились даже картинки перевести :)
От себя могу добавить, что полная поддержка HMVC (внешние запросы и передача отдельных данных (POST, GET) другому запросу) появилась в версии 3.1, которая сейчас находится в стадии RC2 и должна в скором времени увидеть свет

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

Может вы хотели сказать наоборот, что у человека даже мысли не возникнет, что идея чужая?

Отличный обзор, спасибо! Теперь я знаю какими будут следующие пара книг, которые я прочитаю :)
Особенно понравились мысли из книги «Незаменимый», уверен — она отлично мотивирует

Родительская страница доступна из ифрейма даже на другом домене. Наоборот — нет. Так что тут всё в порядке. Кстати, это довольно популярный метод «избавления» от ифрейма, т.е. можно сделать так, чтобы сайт при попытке загрузить его внутрь ифрейма заменял собой основную страницу. Таким образом, при попытке Васи загрузить сайт в ифрейме, пользователь будет перенаправлен на сайт магазина

Раньше времени отправилось…
Например:

$this->request->controller

Также кроме контроллера и экшена есть ещё специальная переменная directory. Указав её, можно помещать контроллеры в подкаталоги.

Про реверс роутинг (построение адресов из роутов) к сожалению тут тоже ничего не сказано (может будет в следующей части?).

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

Неплохая статья. Относительно понятно всё написано
Наверно стоит ещё добавить, что получить параметры роута можно (внутри контроллера, например) таким способом:

$this->request->param('id')

Контроллер, экшн и директория хранятся, соответственно, в переменных запроса controller, action и directory, т.е.

Вот тут даже на русском :)

Тут видимо имеется ввиду, что Query Builder полюбому генерирует запрос, совместимый со всеми поддерживаемыми БД, т.е. об этом можно даже не задумываться (естественно, если не использовать конструкции типа DB::expr())

Но это, естественно, не единственное его преимущество. Как вы сказали — им удобнее «собирать» запросы, т.е. генерировать их динамически в зависимости от условий или переданных параметров

(isset($_POST['title'])? $_POST['title']: ""

Для этого есть метод

Arr::get($_POST, 'title', '')

в общем, такое ощущение, что писал дилетант. Не в обиду переводчику, но лучше бы вы написали какой-нибудь свой туториал по этому несомненно замечательному фреймворку, чем переводить такие сомнительного качества материалы

По-моему, от этой статьи больше вреда, чем пользы. Те, кто уже знаком с фреймворком, итак знают что как надо делать, а новичков этот «туториал» научит как делать не надо.
1. Про ручное экранирование запросов уже было сказано выше;
2. Модель надо наследовать от класса Model, а не Kohana_Model, иначе вся расширяемость коту под хвост;
3. У модели есть статические метод factory, который предпочтительнее
ну и ещё всякого по-мелочи

> 2. Метод render() вообще в явном виде необязателен — при преобразовании к строке он и так вызовется

Согласен, но как вы знаете в методе __toString() нельзя выбрасывать исключения. Это может создать некоторые неудобства, поэтому я предпочитаю всегда явно указывать render(). Где это делать — в контроллере или в view — это уже другой вопрос

Примерно это я и пытался ответить, а меня обвинили в демагогии. Лично у меня паталогическая тяга ко всему новому, поэтому мне очень интересно наблюдать за развитием разных новых фреймворков/библиотек и т.д., плюс действительно можно почерпнуть много разных интересных идей, изучая исходники.
Кому-то другому возможно понравится его скорость, удобство или что-то ещё. Я же не могу сразу за всех ответить

А вот это очень дельная мысль! Кохана сейчас действительно развивается не теми темпами, какими хотелось бы, к сожалению. Но с другой стороны — это очень качественный фреймворк и объединив усилия вместо того чтобы распыляться, можно было бы действительно сделать его одним из лучших

Тоже только что хотел спросить — вы вообще считаете фреймворки ненужными? :)

А зачем он используется, если не предоставляет ничего нового и дополнительного

Вы не поверите, но фреймворки пишутся на нативном PHP, поэтому по определению не могут давать ничего «нового», а вот дополнительного и удобного дают много. По вашей логике разные обёртки над БД тоже не имеют смысла, ведь можно вместо них писать strtr(), mysql_real_escape_string() и т.д.

Конечно, только ради этого не стоит тащить никакой фреймворк. Но ведь это не главная цель его использования, правда? А если всё равно он используется, то почему бы не воспользоваться его возможностями? Тем более никто не запрещает вам использовать тот же тернарный оператор или суперглобальные переменные напрямую, если нравится.

Кстати говоря, Input::server(index) может к примеру делать очистку от XSS и прочего, или вы думаете, что авторы просто решили усложнить себе жизнь?