Как работать с MVC структурой?

модель MVC у меня такая http://habrahabr[dot]ru/post/150267/ , единственное в роутере у меня существует проверка (после подключения контроллера) существования метода, если нет, загружается по умолчанию 'index'.
Проблема в следующем:
запрос - website/news/{какой то экшен}
Вопрос: Как поступать когда экшен динамический? К примеру переход на под страницу.
Или website/search/{строка поиска} ?

(Отредактировано автором: 19 Июля, 2013 - 10:56:59)

Соответственно, ваш роутер должен уметь вызвать правильный контроллер, а остальную часть url передать контроллеру в качестве параметров.
при этом лучше вообще не думать об URL
Он может быть хоть:
website/1/2/100/sometheing-else/ search/qwertyuiopa

Важно, чтобы реально запрос перенаправлялся на website/index.php?параметры
или в ту точку, входа, которая принята у вас, чтобы ваш роутер корректно разобрал параметры и вызвал нужные контроллеры.

Иными словами, в случае с вашим примером, — без разницы какой у вас {какой то экшен}, его все равно получит контроллер news.inc.php и обработает. Если при запросе website/news/1/2/4 ваш роутер пытается искать контроллер с именем 4 или что-то подобное, то это неверно настроенные перенаправления или некорректная (если конечно так не было задумано) логика роутера.

(Отредактировано автором: 19 Июля, 2013 - 10:51:25)

я думаю не о урл а какие параметры в нем передавать, или даже вернее что из него брать.

Если я Вас правильно понял какие методы грузить должен решать контроллер?
В моем случае в роутере происходит поиск метода.
А контроллер в website/news/1/2/4 -"news"

(Отредактировано автором: 19 Июля, 2013 - 10:55:41)

Все зависит от вашего "феншуя" и реализации паттерна.
Традиционно задача роутера именно вызвать контроллер и передать ему параметры запроса.
(Добавление)
Соответственно, метод news должен получить параметры "/1/2/4" и обработать. Что, собственно, вам не ясно?

(Отредактировано автором: 19 Июля, 2013 - 11:03:33)

Хосспаде! Опять эта статья! Не юзай это в боевом проекте!!!

-----
Шта? Репозиторий?

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

К чему? К тому что в статье? Не смеши..
Вот именно.
Я тоже пытался тут на форуме объяснять ООП в статьях простыми словами.
Увы - меня закидали помидорами.
И я полностью согласен с этими помидорами.
Потому, что невозможно объяснить за один раз все, что нужно, да еще и так, чтобы поняли.

-----
Шта? Репозиторий?

(Отредактировано автором: 19 Июля, 2013 - 12:53:58)

В той статье это конструкция switch case, какой там роутер?
И тут shum0531 спрашивает как отловить динамические параметры.
Я сперва подумал рассказать ему про __call() но куда там..

-----
Шта? Репозиторий?

1. Не видел никакой статьи. На момент чтения поста ссылка была либо удалена модером либо незапостена тс.
2. В статье конструкция с switch приводится в качестве пример того, "как раньше все делали", хотя так делал, по-видимому, только автор и его последователи.

[quote=DeepVarvar]
Все просто! ООП нужно для работы в команде, не надо вникать как работает модуль коллеги. Знаешь интерфейс, расширил модуль в 2 строки и вуаля. В итоге каждая голова в команде загружена только своей задачей - удобно.
Если же ты кодишь один тогда тебе это не к чему. До поры до времени.

Неверно. Противоречие на противоречии.
Вот я один писал свой велосипед, и что? Я писал его процедурно?
И нет и да. Там где надо были объекты, а где надо - функции.
(Добавление)
ООП не для командной работы - это точно.

-----
Шта? Репозиторий?

DeepVarvar Либо Вы меня не поняли либо я Вас. Я говорю о ООП и MVC как основа проектирования

Реализация автора статьи была применена для сайта визитки. Уже на этапе роутинга запроса для такого простого проекта создаются объекты классов и прочее что совершенно для него не требуется, тем более, — реализация на основе перегрузок методов. Простейшее перенаправление параметров запроса контроллеру, только разумеется не из самого урла, а в случае с последними проектами, — запрос их сигнатур из БД и перенаправление обработки в контроллер. И пока ни разу конкретно в этих проектах не сталкивался с необходимостью перетаскивать логику роутинга на объектную основу, а они по сложности далеко интереснее сайта-визитки. Касательно пухлых командных проектов, — естественно применяется роутинг заложенный в фреймворк.
В реализации же автора статьи показаны процедуры обернутые в классы без какого-либо выигрыша в производительности или удобстве, хотя и "похоже" на то, как роутинг реализуется на самом деле на ООП в популярных фреймворках, но стоило-ли того написание статьи?

(Отредактировано автором: 19 Июля, 2013 - 12:25:37)

никогда мвц не было основой
(Добавление)
shum0531, два человека тебе говорят что дело - какашка.
Чего тебе еще в доказательство надо?

Объяснений "почему и как сделать правильно"?
Это очень долго, ковыряй пока как умеешь, все само придет со временем.

-----
Шта? Репозиторий?