Webアプリケーションフレームワークでは、プレゼンテーションを司るViewと アプリケーションを司るLogicの分離が行われることが多い。
プレゼンテーションはデザイナーに任せ、 アプリケーションロジックはプログラマが担当することで、 適切に分業が行われることが望ましい、ということだ。
で、ViewはHTMLのテンプレートで行われることが多い。
が、ViewそのものにLogicが必要なケースがある場合はどうだろう。 よくある例では、テーブルの各行ごとに色を変えて見易くすることがある。 奇数行めと偶数行めでバックグラウンドカラーを変えるロジックは、 ドメインとしてはViewに属するに違いない。少なくともアプリケーションドメインではない。
しかし、HTMLテンプレートでは記述できないし、するべきではないだろう。 なんのためにテンプレートを導入したか分からなくなるからだ。
では、このようなロジックはどこに所属すべきか。
ビュー（プレゼンテーション層）をさらにデータとロジックに分離すれば解決です。興味があればこちらをご覧ください。
http://www.kuwata-lab.com/kwartz/kwartz-overview/index.php?page=4
http://www.kuwata-lab.com/kwartz/kwartz-overview/index.php?page=8
Webアプリケーションのフレームワークじゃなくて、Web-UIのフレームワークとUIと独立のアプリケーションの具で構成する方が自然だと小さな声で主張しようっと。
そういうわけで見た目のためのコードもWeb-UIむけのコードの中にためらわず書いてしまう。
コードが多少は書けるデザイナーさんに頼み、HTMLにLogicを埋め込んでしまう、がスマートではありますが・・・
デザイナーとプログラマ、明確に役割分担するのはよくないと思ってます。それで制作効率が上がるといえば、高いコミュニケーションを保ったチームならいいんですけど、同じ部屋で作業できないとなると明らかにだめ。
HTML内に単純なロジックを埋め込むのはよいと思います。ERbでコーディングしようが、シンプルなコードに保てていればそれでＯＫでしょう。
純粋にちょっと見た目を変えるのであればスタイルシートを使うべきだと思います。CSSは貧弱ですが、XSLTを使えばたいていのことはできます。
もう少し複雑なことを(ダイナミックなこと)をHTML側でやるならばスクリプト(JavaScriptなど)を埋め込むべきだと思います。
それでもだめならViewをサーバー側で処理することになるのでは。アプリケーションロジックとは別のロジックとして。