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

[angry.creater]

Ужос!!!
я помню себя, в Ваши годы (года эдак 2-3 назад) заходящим на этот сайт, и вопрошающим у почтенных старожил что же есть FC, AC, FC и прочие абстракции, и Вы знаете, что любопытно? - стиль объяснений не изменился ни чуть!!!
Господа, ну право же, не желаете делиться знаниями полученными в результате собственного опыта? - Ну так хоть не сбивайте с толку человека!

короче:
1. вспоминаешь (изучаешь) основы и идеологию ООП
2. ищешь эту книгу: Matt Zandstra "PHP Objects Patterns And Practice"

полученных знаний из этих двух источников, надеюсь хватит для самого важного - осознать то, что говорил Зерк в 7 посте этого треда.

Далее, идёшь сюда: http://limb-project.com/ и смотришь пожалуй на самую "красивую" (ИМХО, ИМХО ИМХО!!!!) имплементацию FC

-~{}~ 24.06.08 12:29:

Кстати, вторая вешчЪ от этих ребят, архитектурным принципам которой, я всегда стараюсь придерживаться в своих проектах: Dynamic Service Locator и их пакет TOOLKIT

http://wiki.limb-project.com/doku.php?id=limb3:ru:packages:toolkit

 

[crocodile2u]

Опять же не стоит забывать замечание бывалого человека по имени grigori - зачем вам вообще сдался этот фронт-контроллер на пхп? ЧПУ отлично реализуется без вмешательства пхп.

 

[angry.creater]

сейчас, ФС для меня это скорее централизованный композитный менеджер фильтров (возможно, в некоторых случаях, с некоторым подобием конечного автомата) , чем классическое описание (а если юзаем например AC, то последний реализуем в роли того же фильтра)

 

[AmdY]

angry.creater
я не совсем понял, чем вам не нравится способ объяснения, весьма полезную информацию дают и много инфы для размышления и углубленного гугления.
а вот идея с цепочками фильтров мне тоже нравится, вот только не могу припомнить ни одного соременного популярного фреймворка с такой реализацией .

 

[angry.creater]

в своё время, ответы большенства членов PHPClub привели к необходимости углублённого гугления и размышлениям, в результате чего, имея некоторый алгоритм ,я стал делать так, как удобно мне

ФК - это просто "шаблонное решение", ни в коей мере не претендующее на должность спецификации, и в случае следования 100%-у повторению идеологии заложенной в реализации этого паттерна, каким либо фреймвёрком, на лицо факт непонимания нами принципа этих самых паттернов.

Просто мне так удобнее, ФК - композиция фильтров (Сессии, Апп. Контроллер - если юзается, сборщик композитного представления и прочее) , переход между которыми осуществляется в зависимости от состояния выполнения предыдущего. Возможно, я в ФК перенёс некую ф-ность Апп. Контроллера, но ничуть ущербным себя из-за этого не считаю, так как такой алгоритм мне действительно удобней, чем следование описываемому ФК в документации SUN.

Что не понравилось в ответах? - Да нет, всё понравилось, если кого обидел - сорри, и мысли не имел, просто, читая комменты, вспомнил свои мысли, когда пытался понять, как же притянуть эти все понятия к моему ПХП-коду, а "мыслил" я примерно следующее: как я могу поянть, как удобно мне, если у меня нет достаточно знаний для сравнения с последующим анализом?

Я уверен, топикстартер "смешил" вас этими вопросами непотому что он деггер, имбицил или просто дурак, а потому что вся инфа которая ему попадалась до этого была сильно упрощена и не отображала положения вещей в действительности... ему просто нужно было посмотреть от начала и до конца несколько фреймвёрков, реализующих эти паттерны с более-менее полной документацией.
Но рекомендовать челу, делающие сеттеры и геттеры для публичных статических пропертей, к изучению Зенд, и прочие фреймвёрки - это лишнее, сперва необходимо "освежить память" основами

Собсна поэтому я и отослал его к книжке Мэтта Зендстры, в которой разжёвываются эти понятия на уровне достаточном, для просвящения самым высшим ДАО - делать так, как удобно тебе, но понимая, что все эти паттерны означают, и имея необходимые знания что бы сравнивать.
И уже только после этого, ИМХО, чела можно отсылать к промышленным (так сказать) CMF