Расскажите, если можно, про реализацию Контроллера (MVC) на Parser (и вообще), (можно с примерами из PF'a потому, что без доки он как загадочные круги на полях - красиво и непонятно :).

andylars 26.07.2015 20:41 / 26.07.2015 20:45

С Шаблонизацией все стало более/менее ясно на практике, промежуточные выводы, что я вынес:

- От junction'а лучше отказаться сразу, т.к. вся его красота применения для шаблона, перечеркивается его контекстом исполнения, а нам чаще нужен внутренний (по месту вызова). И вообще, толкать код как параметр шаблона, это в 99% попытка нахардкодить и запихнуть побольше "Контроллера" в "Представление" (ИМХО).

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

В остальном, простая реализация на коленках шаблона, как класса с методами-подшаблонами, не выявила пока никаких особых проблем или сложностей. Все до крайности просто и работает.

В общем, дело подошло к Контроллеру... а точнее его реализации.

Что к нему должно относиться? Пока, как я понимаю:
1. Сбор/Разбор внешних данных и маппинг их к опр.обработчикам или как? Например, части урла и +/- get-параметры, учавствуют в навигации, и хочется иметь какой-то унифицированный подход в сборке-разборке всей этой uri-строки.

Т.е. часть из них, могут быть командами, и их не надо удерживать для генерации дальнейших ссылок, а какие-то надо.

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

Например, у меня есть список картинок с постраничной навигаций, я нахожусь на 2-ой странице:

 /imglist/?page=2

я хочу открыть картинку, там что-то пощелкать

 /imglist/view?id=001

и вернуться назад к списку на то же место, вариантов масса, хочется узнать решения, прошедшие практикой и опытом.
самый уродливый, это тащить ?backurl= как доп.параметр

приемлемый, это писать часть логики навигации в cookie (в конце-концов, такой же http-header, почему нет)

ну или обыграть построением пути в urle:

 /imglist/2/view/001

тогда вроде и выглядит логично, но надо иметь четкий порядок, иначе выпадание одного под-пути, поламает все.

2. Движок/управление самими "компонентами навигации". Простой пример (как я понимаю) - это механизм постраничной навигация (паджинация) - это как раз задача контроллера.

Вот есть к этому всему какой-то хороший/унифицированный подход? Или кто как сделал? У меня конечно свои мысли есть, но нет столько времени опробовать все сорта граблей.

---