Во-первых, спасибо за ответ, наконец-то появилась возможность подискутировать на интересную мне тему =) Во-вторых, если не сложно, продублируй свой ответ в блоге - его читаю пользователи других форумов, возможно они тоже захотят принять участие в дискуссии. Теперь ответы по пунктам.
1. Я довольно скептически отношусь к использованию объектов в шаблонах и, как следствие, к представлению, например, новости, как объекта. В моем понимании новость - это ассоциативный массив, ключи которого дублируют поля таблицы, и, если необходимо, некоторые дополнительные значения, которые предварительно устанавливаются доменным объектом. А список новостей - это массив таких хэшей. Может в будущем я изменю свое мнение, но сейчас мне кажется, что объектам в представлении не место (за исключением статических методов построения блоков информации).
Касательно замены определенных символов в некоторых полях, приведения даты к стандартному формату и прочего - я размышлял над этим, но пока не пришел к окончательному выводу, хотя уже вижу два пути реализации:
а) изменять данные непосредственно после выборки и хранить их в новом формате.
б) делать то же самое, но не в коде, а при помощи xml конфига. Пример подобного конфига был приведен в отчете о PHP конференции (доклад посвященный ORM).
2. У меня существует отдельный класс Request который занимается парсингом параметров и он умеет преобразовывать, например, /news/show/123/ в action=show&id=123. Использования такого класса упрощает модификацию обработки и пасинга параметров путем просто переопределения нужных методов.
3. Раньше все так и было. Все классы наследовали Object (в нем методы select, update, create, delete, getAll), зачастую в классах-наследниках указывался только путь к xml конфигурационному файлу (в нем определились короткие синонимы для полей, указывался первичный ключ, его тип и пр.), а так же был статический метод list (find) который занимался работой со списком. Однако вскоре стали появляться большие проблемы. Например, все документы я храню в одной таблице, информацию об авторах - в другой, иконку для документа - в третьей, информацию о источнике - в четвертой и т.д.. Я так и не смог придумать, как правильно реализовать метод выбора одной новости и списка новостей в этом случае и в какой класс его поместить. С одной стороны загромождать класс Document неправильно, с другой - больше эти методы и деть-то некуда.
Вот такой вот был запрос для списка (немного упрощенный =):
my $query = "
SELECT *
FROM $TBL{document}{_} AS doc
LEFT JOIN $TBL{author}{_} AS a ON a.$TBL{author}{id} = doc.$TBL{document}{authorid}
LEFT JOIN $TBL{category}{_} AS cat ON cat.$TBL{category}{id} = doc.$TBL{document}{categoryid}
LEFT JOIN $TBL{source}{_} AS s ON s.$TBL{source}{id} = doc.$TBL{document}{sourceid}" .
($self->SQLOrderBy($sparam->{OrderBy})) .
$self->SQLLimit(@{$sparam->{Limit}});
А так я вынес все методы отображения в отдельный класс и теперь доменные классы практически не подвергаются правке. Ну и в шаблоне это дело удобно использовать:
<!-- вывод первых 3 новостей с одним шаблоном -->
[% News::List("tmp_1", LimitForm => 0, LimitTo => 3, OrderBy => ‘date’, OrderType => ‘DESC’) %]
<!—вывод новостей с 3 по 7 с другим шаблоном -->
[% News::List("tmp_2", LimitForm => 3, LimitTo => 10) %]
tmp_1, tmp2 - это тройные шаблоны (альтернатива foreach).
Все, конечно, упрощенно. Можно обрабатывать ситуации, когда список пуст и т.д., но общая идея должна быть понятна.
Кстати, весьма интересная реализация работы с шаблонами есть в WordPress (блоге). Я думаю что для PHP (с перлом другая история) шаблонизаторы типа смарти - это излишество.
