> м. чтобы они обрабатывали запросы, да?
:-) просто мне показалось странным. Сначала регистрируешь роут, указываешь какому url соответствует view, но и потом зачем-то регистрируешь view. С ходу не понятно просто.
— а зачем нужно регистрировать view функции? (я правда не знаю)
— посмотрел бегло о traversal. Что-то интересное, но до конца не понял как его едят.
— что такое заменяемые рендеры?
Какой опыт у меня есть? в питоне — практически никакой. (слегка касался джанго — писал пару модулей, и один демон по работе), но хороший опыт в php — на нем и реализован мой хобби-проект. В качестве изучения питона — планирую переписать некоторые части его на новом языке (либо на flask либо на pyramid — еще не определился)
каждый запрос входящий ловит система (RoR) и пропускает через routing. Который определяет какой именно контроллер и действие загрузить(MVC). Если разделение возможно — оно где-то скрыто в роутинге.
в обычном ООП я получил общий абстрактный класс включающий в себя достаточно много методов, а так же наличие в конкретных реализациях методов которые не нужны (наследуемые от родителя). Ухудшилась читаемость. По видимому пришло время поменять архитектуру. Ваша идея создать классы «изображение», «тексты» и их методы использовать в конкретных реализациях — мне понравилась.
и да и нет. Потому как в компоновщике речь идет о том, что бы компонент рассматривать не только как компонент, но и как объединение компонентов. Мне кажется что здесь что-то среднее между компоновщиком и декоратором.
От обычного наследования этот подход отличается тем, что наследование, как таковое, можно избежать — достаточно перечислить лишь набор необходимых параметров. Это как компоновать форму — добавить кнопку, добавить поле, добавить субмит. Но наследовать формы, от другой формы — вовсе не обязательно.
