Я предлогая разделить эти две обсолютно разные вещи. Попытаюсь объяснить как я понимаю эти понятия.

View — соответствует представлению в известном трёхбуквенной абривеатуре MVC. Не будем забывать, что эта святая троица была придумана не для веба, чем же она должна была заниматься. View должен передавать данные в удобном для потребителя виде. В декстопных приложениях — это отрисовка окна приложения, контролов в нём, менюшки, анимация, таблицы с данными, реагирование на действия пользователя и т.д. В ОС некоторыми вещими берёт на себя сама ось и вьюха должна руководить этим поведением через api. Поэтому я не перевёл дословно — «Вид», фактически View занимается гораздо большим количеством вещей. Затем, мы сменили декстопный вид на web интерфейс, который пользователь получает в браузере. Теперь View занимается формированием html, js и т.д. И сново же View, посредством javascript обрабатывает действия пользователя, которые затем браузер передаёт конторллеру. Получается данные влияют на представление, которое в свою очередь передаёт нужное действие контроллеру, а тот работает с данными и так по кругу. Поэтому MVC, а не CMV. Если выбросить контроллер, то получатся данные и их представление == xml и xsl. А теперь и вовсе избавимся от зрительных образов, чем занимается View при XML RPC (удалённый вызов процедур)? Он приводит данные к нужному формату — xml.

Шаблоны. Мне больше нравится обозначение трафарет — этакая заготовка со специальными местами, которые нужно обрисовать, заполнить данными. Соответственно это уже законченый образец отображения данных, который нельзя менять. Хочешь вырезать квадратик с кружочком внутри — будь добр, заведи новый шаблон и не порть квадрат, который ещё пригодится.

И очень важное убение View работать с шаблонами, например при отображении данных в виде xml известной структуры, можно воспользоваться заготовкой xml и заполнить нужные места данными. Но если структура динамическая придётся xml формировать другими средствами, например с DOM или SimpleXML в php 5. Но этим будет заниматься как раз View, это его задача.

Вывод 1

View значительнее функциональнее шаблонов и дожен покрывать максимально возможные потребности по представлению.

Вывод 2

Шаблон вовсе не должен обладать функциональностью.

Теперь перейдём к шаблонизаторам и View.

Нам нужно сформировать контрол select. Соответственно у View должен быть метод, который берёт данные о контроле и выводит готовый контрол. Для вывода ему понадобится два шаблона select и option, это прекрасно видно в javascript при генерации списка создаётся элемент select и в него добавляются option-ы. Статические селект генерим без проблем простой заменой псевдометок, а вот отобразить динамические данные без участи MC шаблон и вовсе не может . Вначале рендерится открывающийся тег, затем рендерится энное количество шаблонов с option, а затем закрывающийся тег. Получается, что шаблонизатор — это кастрированый View, который к тому же разбивает сущность на части при рендеринге.

Идеальный шаблонизатор. Функция str_replace, она покрывает возможности заменять псевдокод данными, плюс цикл для обработки циклических частей.

Идеальный View. Его нету, так как View должен быть платформонезависимым, самая успешная попытка в этом плане XSLT. В php мне нравится smarty и quicky, так как дают возможность создать свой View и при этом за счёт псевдоязыка практически не даёт использовать не View возможности php, но при этом есть неудобства. Во-первых нужно учить псевдоязык, удобнее было бы, если бы синтаксис совпадал с синтаксисом самого php. Во-вторых не очень удобно расширять возможности, допусти для контрола типа дерева в smarty нужно писать функции для компилятора, либо использовать рекурсивный инклуд, что неприемлимо так как разделяет функционал.

P.S. Перечитал и понял, что зря таки Фаулера забросил на первой сотни страниц, с терминологие тяжело приходится, надеюсь, всё же более менее понятно.