FrontController, как грамотно построить?

[AP]

grigori, Front Controller фактически должен объединить эти действие в классе. Лично я испльзую Front Controller через Filter Chain.

 

[Ksarien]

AP, а можно поподробнее о паттерне Filter Chain? в 2ух словах.

 

[AP]

Ksarien, http://ru.sun.com/pdf/patterns/pattern7.pdf

 

[dark-demon]

ну и велосипед от меня http://php.ru/forum/viewtopic.php?t=6729
это только разбор и формирование ури, но фронт-контроллер на его основе пишется на раз.

 

[Ksarien]

AP, спасибо за ссылку.

 

[iSlayter]

Господа, кого не затруднит, ответьте на один пару вопросов: как в целом, удался ли мне фронт_контроллер или нет? http://makarychev.ru/job/Front_Controller.phps что стоит исправить и как?

 

[HraKK]

Как по мне это пиз::::ц какой-то а не FC

 

[iSlayter]

HraKK, что переделывать? как?

 

[kirill538]

Читайте про рефакторинг что-нибудь. Метод dispatch можно выкинуть сразу, еще до прочтения. public геттеры для public static свойств зачем понадобились ? Мда, про рефакторинг я загнул, начните с основ ООП.

 

[iSlayter]

kirill538, паблик геттеры совершенно не нужны, т.к., собственно всё public static.

public static свойства понадобились потому что думал, что буду использовать определённые имя контроллера, действия и параметры запроса где-либо в другом месте (например, в плагинах к smarty). однако они ими быть не должны, в крайнем случае их можно в Registry положить (хотя и это не нужно, оно у меня в вид передаётся прямо во FC, а в смарти есть $smarty->get_template_vars()).

В самом методе dispatch много кусков повторяющегося кода, к-е лучше вынести в отдельные методы.

что ещё?

 

[kirill538]

В самом методе dispatch много кусков повторяющегося кода, к-е лучше вынести в отдельные методы.

Я об этом и не говорю. Но кроме того там еще очень много if-else ...

что ещё?

Вы думаете, кто-то будет долго разбираться в вашем сильно пахнущем коде ? Отложите этот класс, читайте про ООП, затем Фаулера про рефакторинг (там как раз про запахи кода написано), потом вернитесь к своему коду. Сами все поймете. Пока вам не станет ясно, зачем придумали полиморфизм и как его использовать для замены if-else на 2 страницы - советы впрок не пойдут.

 

[iSlayter]

но всё же не стоит ли массив с параметрами и их значениями сделать паблик статик? и статический метод, к-й выдавал бы оттуда значения по запрошенному параметру. нет? будет использоваться ведь в моделях, и сделав их public static ($param_array и метод get) мы сможем легко получать значение. с помощью метода не будем получать нотисов об отсутсвии элемента в массиве (в методе проверка на существование)

 

[kirill538]

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

Я повторяю - сначала прочитайте про ООП (особенно про полиморфизм). Зачем вам в этом классе статические поля и методы, да еще в таком количестве ?

-~{}~ 12.06.08 03:06:

паблик статик? и статический метод, к-й выдавал бы оттуда значения

Мда. Вы PHP5 используете потому, что PHP4 не нашлось ? знаете, что доступ кроме public бывает еще и protected и private. Пока не ответите на вопрос (сами себе) - зачем ваши статические поля public и что изментся если их сделать protected (а также НЕ static) - дискуссия беспредметна. Но спасибо, развлекли под финиш рабочего дня

 

[iSlayter]

kirill538, обоснованным я вижу статический метод get и массив param_array -- почему написал выше.

-~{}~ 12.06.08 03:11:

kirill538, различия между public, protected и private прекрасно осознаю. Написал полный бред, с этим тоже согласен. Сегодня же покажу другой вариант.

и спасибо за путёвку в нужную степь. сам то ли не осознавал, то ли признавать всего ужаса не хотел


собственно геттер вообще имеет смысл лишь в случае protected, private... так ну это уже монолог пошел..

 

[kirill538]

обоснованным я вижу статический метод get и массив param_array

А вот обоснуйте еще разок. Только не вслух, сами для себя.

Сегодня же покажу другой вариант

Не стоит. Сами же понимаете, что фигово выходит. Чего вы бросаетесь писать код, не понимая его конечной цели ?

различия между public, protected и private прекрасно осознаю

Нет, не прекрасно. Из кода следует - вообще не осознаете. Потратите пару дней на изучение теории - себе же сэкономите кучу времени потом ...

 

[Gas]

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

 

[iSlayter]

http://makarychev.ru/job/Front_Controller__refactored.phps


теперь лучше? посмотрите кто-нибудь, пожалуйста.

 

[Farsh]

The Front Controller's Job in Detail

1. Define the core constants.
2. Locate the symfony libraries.
3. Load and initiate the core framework classes.
4. Load the configuration.
5. Decode the request URL to determine the action to execute and the request parameters.
6. If the action does not exist, redirect to the 404 error action.
7. Activate filters (for instance, if the request needs authentication).
8. Execute the filters, first pass.
9. Execute the action and render the view.
10. Execute the filters, second pass.
11. Output the response.

с Symfony =)
А если на словах, то инициализирует конфигурацию , ищет первое соответствие request uri правилу роутинга , запускает фильтры и после грузит соответствующий запросу module/action .

 

[AP]

ищет первое соответствие request uri правилу роутинга

ИМХО этим должен заниматься другой класс....

 

[iSlayter]

Да уж... по-моему там половиной вещей не FC должен заниматься (1-4 уж точно).