Если бы вы внимательно прочитали статью, вы бы увидели, что HMVC — это не «возможность вызывать один контроллер из другого». Точнее, это лишь малая его часть. Вызвать один контроллер из другого дело нехитрое и ничем не отличается от обычного создания экземпляра класса:
$controller = new Controller;
$controller->action();
Вся прелесть HMVC как раз в том, что тут создаются полноценные запросы к каким-либо частям приложения, вероятно даже внешнего, которое никак не зависит от вызывающего, и поэтому (если говорить в контексте данной статьи) может быть в частности перенесено на другой сервер, что сильно упрощает горизонтальное масштабирования приложения
Спасибо за интересный перевод отличной статьи. Не поленились даже картинки перевести :)
От себя могу добавить, что полная поддержка HMVC (внешние запросы и передача отдельных данных (POST, GET) другому запросу) появилась в версии 3.1, которая сейчас находится в стадии RC2 и должна в скором времени увидеть свет
Отличный обзор, спасибо! Теперь я знаю какими будут следующие пара книг, которые я прочитаю :)
Особенно понравились мысли из книги «Незаменимый», уверен — она отлично мотивирует
Родительская страница доступна из ифрейма даже на другом домене. Наоборот — нет. Так что тут всё в порядке. Кстати, это довольно популярный метод «избавления» от ифрейма, т.е. можно сделать так, чтобы сайт при попытке загрузить его внутрь ифрейма заменял собой основную страницу. Таким образом, при попытке Васи загрузить сайт в ифрейме, пользователь будет перенаправлен на сайт магазина
Также кроме контроллера и экшена есть ещё специальная переменная directory. Указав её, можно помещать контроллеры в подкаталоги.
Про реверс роутинг (построение адресов из роутов) к сожалению тут тоже ничего не сказано (может будет в следующей части?).
В общем, новичкам будет полезно ознакомиться со статьёй, потому что по личному опыту знаю, что довольно у многих на начальном этапе возникают проблемы с механизмом задания и функционирования роутов в KO3.
Неплохая статья. Относительно понятно всё написано
Наверно стоит ещё добавить, что получить параметры роута можно (внутри контроллера, например) таким способом:
$this->request->param('id')
Контроллер, экшн и директория хранятся, соответственно, в переменных запроса controller, action и directory, т.е.
Тут видимо имеется ввиду, что Query Builder полюбому генерирует запрос, совместимый со всеми поддерживаемыми БД, т.е. об этом можно даже не задумываться (естественно, если не использовать конструкции типа DB::expr())
Но это, естественно, не единственное его преимущество. Как вы сказали — им удобнее «собирать» запросы, т.е. генерировать их динамически в зависимости от условий или переданных параметров
в общем, такое ощущение, что писал дилетант. Не в обиду переводчику, но лучше бы вы написали какой-нибудь свой туториал по этому несомненно замечательному фреймворку, чем переводить такие сомнительного качества материалы
По-моему, от этой статьи больше вреда, чем пользы. Те, кто уже знаком с фреймворком, итак знают что как надо делать, а новичков этот «туториал» научит как делать не надо.
1. Про ручное экранирование запросов уже было сказано выше;
2. Модель надо наследовать от класса Model, а не Kohana_Model, иначе вся расширяемость коту под хвост;
3. У модели есть статические метод factory, который предпочтительнее
ну и ещё всякого по-мелочи
> 2. Метод render() вообще в явном виде необязателен — при преобразовании к строке он и так вызовется
Согласен, но как вы знаете в методе __toString() нельзя выбрасывать исключения. Это может создать некоторые неудобства, поэтому я предпочитаю всегда явно указывать render(). Где это делать — в контроллере или в view — это уже другой вопрос
Примерно это я и пытался ответить, а меня обвинили в демагогии. Лично у меня паталогическая тяга ко всему новому, поэтому мне очень интересно наблюдать за развитием разных новых фреймворков/библиотек и т.д., плюс действительно можно почерпнуть много разных интересных идей, изучая исходники.
Кому-то другому возможно понравится его скорость, удобство или что-то ещё. Я же не могу сразу за всех ответить
Надо оценивать не текущее состояние, а перспективы. Предлагать свои идеи, принимать участие в создании и т.д. Это же community-driven framework, поэтому от нас с вами в том числе зависит его будущее. Хотя, пользоваться всем готовым, конечно, намного проще…
А вот это очень дельная мысль! Кохана сейчас действительно развивается не теми темпами, какими хотелось бы, к сожалению. Но с другой стороны — это очень качественный фреймворк и объединив усилия вместо того чтобы распыляться, можно было бы действительно сделать его одним из лучших
А зачем он используется, если не предоставляет ничего нового и дополнительного
Вы не поверите, но фреймворки пишутся на нативном PHP, поэтому по определению не могут давать ничего «нового», а вот дополнительного и удобного дают много. По вашей логике разные обёртки над БД тоже не имеют смысла, ведь можно вместо них писать strtr(), mysql_real_escape_string() и т.д.
Тем, что он не отправляет заголовки, а только «складывает их в массив», чтобы потом отправить все разом. Но перед этим можно их ещё подредактировать/удалить лишние и т.д.
Вся прелесть HMVC как раз в том, что тут создаются полноценные запросы к каким-либо частям приложения, вероятно даже внешнего, которое никак не зависит от вызывающего, и поэтому (если говорить в контексте данной статьи) может быть в частности перенесено на другой сервер, что сильно упрощает горизонтальное масштабирования приложения
От себя могу добавить, что полная поддержка HMVC (внешние запросы и передача отдельных данных (POST, GET) другому запросу) появилась в версии 3.1, которая сейчас находится в стадии RC2 и должна в скором времени увидеть свет
Может вы хотели сказать наоборот, что у человека даже мысли не возникнет, что идея чужая?
Особенно понравились мысли из книги «Незаменимый», уверен — она отлично мотивирует
Например:
Также кроме контроллера и экшена есть ещё специальная переменная directory. Указав её, можно помещать контроллеры в подкаталоги.
Про реверс роутинг (построение адресов из роутов) к сожалению тут тоже ничего не сказано (может будет в следующей части?).
В общем, новичкам будет полезно ознакомиться со статьёй, потому что по личному опыту знаю, что довольно у многих на начальном этапе возникают проблемы с механизмом задания и функционирования роутов в KO3.
Наверно стоит ещё добавить, что получить параметры роута можно (внутри контроллера, например) таким способом:
Контроллер, экшн и директория хранятся, соответственно, в переменных запроса controller, action и directory, т.е.
Но это, естественно, не единственное его преимущество. Как вы сказали — им удобнее «собирать» запросы, т.е. генерировать их динамически в зависимости от условий или переданных параметров
Для этого есть метод
Arr::get($_POST, 'title', '')
в общем, такое ощущение, что писал дилетант. Не в обиду переводчику, но лучше бы вы написали какой-нибудь свой туториал по этому несомненно замечательному фреймворку, чем переводить такие сомнительного качества материалы
1. Про ручное экранирование запросов уже было сказано выше;
2. Модель надо наследовать от класса Model, а не Kohana_Model, иначе вся расширяемость коту под хвост;
3. У модели есть статические метод factory, который предпочтительнее
ну и ещё всякого по-мелочи
Согласен, но как вы знаете в методе __toString() нельзя выбрасывать исключения. Это может создать некоторые неудобства, поэтому я предпочитаю всегда явно указывать render(). Где это делать — в контроллере или в view — это уже другой вопрос
Кому-то другому возможно понравится его скорость, удобство или что-то ещё. Я же не могу сразу за всех ответить
На этот вопрос каждый отвечает для себя сам
Вы не поверите, но фреймворки пишутся на нативном PHP, поэтому по определению не могут давать ничего «нового», а вот дополнительного и удобного дают много. По вашей логике разные обёртки над БД тоже не имеют смысла, ведь можно вместо них писать strtr(), mysql_real_escape_string() и т.д.