mvc и чпу

[Timur]

Есть у меня CMS-ка.
Там администратор может назначать любое количество страниц и любой уровень вложенности
чпу реализовано

Как он называет страницы я совсем не контролирую.

Например url может быть вида
company/about
porfolio/sites/2010

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

Кто как решал этот вопрос

 

[С.]

Решал этот вопрос выбрасыванием ЧПУ. Он уже много лет как никому нафиг не нужен. А нужен ППУ.

 

[fixxxer]

С.
отучаемся говорить за всех

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

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

 

[Redjik]

У меня сделано так.

Есть дефолтный контроллер.
Есть контроллер для статей.
Ну и скажем контроллер для каталога товаров.

при обращении, UrlManager смотрит на пришедшую строку и вызывает нужный контроллер.
возмем примеры

/about_us.html
Смотрит сначала в дефолтный контроллер, если есть такой экшен вызывает его, если нет, вызывает Page:: page($alias), если $alias (about_us) нет в базе - выкидывает 404

/catalog/toys.html
Видит, что в пути несколько сущностей.
Смотрит есть ли контроллер Catalog, потом вызывает в нем Catalog:: page($alias)... По такой же схеме

Ну и соответсвенно при создании каталога или странцы в бд идет првоерка на существование контроллера или экшена в контроллере.

 

[fixxxer]

то есть на странице статей показать сайдбар с товарами нельзя?

 

[Redjik]

fixxxer
можно, я же на Yii пишу, и у меня свое понимание mvc =)))
ставлю виджет в виде, который в себе инкапсулирует всю логику работы... по сути вид ничего не знает о том, что происходит внутри.
виджет в свою очередь сам обращается, если надо, к модели и генерит html разметку.

пофиг, что не MVCшно, зато в коде сразу понятно

 

[Timur]

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

 

[Timur]

fixxxer, Пример такой взрослой системы(систем) не приведете?
Буду очень благодарен.

 

[fixxxer]

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

 

[fixxxer]

Redjik
получается субконтроллер в шаблоне. Не вижу ничего плохого, кроме того, что это через жопу

 

[Timur]

Всем спасибо

 

[Redjik]

fixxxer
согласен, но меня устраивает, что логика прозрачная, пока не нашел более хорошего решения

 

[Ragazzo]

fixxxer
Почему виджет это субконтроллер?Он вообще никак к контроллеру не относится... или я что-то не понял? У тебя HMVC как сделано?ну т.е. у тебя данные запросов друг с другом не конфликтуют, т.к. там же одно из правил чтобы данные определенного роута были доступны только ему, и никому больше(читай гет, пост)?

 

[fixxxer]

у меня не совсем hmvc. напрямую гет-пост вообще никто не видит, все видят свой контекст. корневой элемент имеет определенные привелегии в том, что он видит, и как обрабатываются его ответы.

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

 

[Ragazzo]

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

 

[fixxxer]

ну я это называю компонентами - виджет в моем понимании - это что-то, что идет от view

есть страница, у нее есть конфигурация - корневой компонент и субкомпоненты (можно, в принципе, и дерево сделать, но не понадобилось)
(на самом деле, корневой component.action и т.д. но не суть)

под страницей, конечно же, имеется в виду не конкретный урл, а скорее это такое динамическое описание контроллера страницы

все компоненты получают свою конфигурацию из конфигурации страницы
корневой компонент также получает ее из роута
пост видит только корневой

non-200 ответы в полном смысле обрабатываются только для корневого, для остальных это просто view-флажок

кажется не очень понятно объяснил )

 

[Ragazzo]

fixxxer
Да не, норм объяснил, примерно понял, я так и думал что у тебя есть какой-то свой массив входных элементов для каждого роута при HMVC. Ты кстати что предпочитаешь использовать: простой массив или коллекцию? ну например ты говорил что можно было бы сделать дерево (что-то типа композитора можно, ну или проще совсем коллекция какая-то, вот о чем я).

 

[fixxxer]

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

В конкретно данном случае с "недоhmvc" - простой ArrayObject (который велосипедный).

 

[grigori]

я же на Yii пишу, и у меня свое понимание mvc

поржал

Yii - это не MVC, чтоб там автор под грузом ЧСВ ни писал, это просто удобная ООП-шная поделка с ароматом джумлы, руби и делфи.
Виджет в yii - это субконтроллер в полной мере, это грязно, но удобно: в шаблон воткнул строку, и оно отрисовалось, и на hmvc можно забить.

Я вот и не знаю как можно сделать без плагинов. Править конфиги контроллера вместе с шаблоном чтобы добавить сайдбар с товарами - неудобно.

 

[grigori]

По сути вопроса ТС.
Я сделал систему, по функционалу схожую с rewrite rules в Apache:

в базе таблица правил:
rule_id, pattern, route, params, scope, weight, entity_id1, entity_id2...

при вызове разбирается строка вызова $_SERVER['REQUEST_URI'], и по pattern находится route в формате controller/action, по params формируются GET-параметры запроса для контроллера,
формирование ссылок у меня идет по модели сущности (страница, товар, новость): по route находится pattern, по params формируется query-часть,
scope и weight нужны для обработки иерархических сущностей (категории/разделы/статьи)
entity_id1, entity_id2 - просто FK на записи в таблицах сущностей, они нужны чтобы при удалении сущности удалялось правило для нее

логика кода очень сложная получилась, но сам код маленький и работает быстро и позволяет задавать URL для раздела так, чтобы менялся URL всех сущностей в этом разделе

например, можно создать правило, по которому из /catalog/view/ будет генериться /catalog.html, а у всех товаров, у которых должно было быть /catalog/view/category?name=toys&... будет /catalog/toys/...
причем, программист пишет в коде просто yii::app()->createUrl($Product);