2007年04月10日
Viewは完全にロジックから切り離してApacheモジュールとかで面倒見たらどうだろうか
うちの部署が公開するサービスの構築に、社内の技術資産流用の一環として、隣の部署が開発したフレームワークを導入*1する担当になっているのだけど。
そのフレームワーク、テンプレートシステムとしてXSLTを使っているんだけど、この構築が中々面倒くさい。
おまけに、部署間で要求するデザイン精度が異なる(うちの方が厳しい)ものだから、フレームワークの出力するデータ等がうちの要件に十分対応していないところを、むりやりXSLTのアクロバティックなやり方で回避してたりして、でもそれでもうちの部署のデザイン担当の眼鏡には適わずあちこち修正要求が。
XSLTは確かにやろうと思えばなんでもできるんだけど、変数の再代入はできない、複雑なループは再帰させなきゃいけない、正規表現なんかも使えないというわけで、「ここをこう変えて」と言われたら「確かに変える方法はある」んだけど「そのためにTemplateの切り方から何から、全体の構成から見直さないといけない」ような事が多すぎて、普通のhtmlテンプレート修正するような感覚で要求されるとウザいことこの上ない。
いや別に、デザイン担当の人は職務を正しく遂行しているだけなので、その人にイラついているわけではないのだが。
んで思ったんだけど、最近色んな開発言語でいろんなフレームワークが出ていて、それぞれにテンプレート機構等のViewのシステムを持つわけだけど、これって各フレームワークから分離できないですかね。
例えば今回の例だと、うちの部署は普通のhtmlに社内で定義したタグを埋め込んで、ロジックがそれを動的な値に置換する、という形のテンプレートシステムを採用しているわけだけど、一方の部署ではXSLTを用いていて、企画・デザイナーレベルの人がフレームワークに振り回されていろんなテンプレート記法を覚えないといけなく、また異なるフレームワーク間でデザインの統一等も難しく、生産性がよいとはいえない気がする。
一方で、ロジックの方は、社内で統一した方が資産の活用等の面でよい、という考え方もありますが、開発者の経験やフレームワーク毎の得意/不得意なんかを考えると、ある程度選択の自由があった方が開発効率があがるのではないかと思います。
そうなると、開発側にいろんな開発環境での開発を許しつつ、企画・デザイン側のテンプレートを統一化しようと思うと、ロジックはどのような開発環境を使うにせよ、処理結果をYAMLなんかで出力し、Apache内で出力前にフックしてYAML⇒テンプレート適用処理を行って、HTMLを出力する、という形がよかったりするのでは?と思ったりしました。
Apache内といってもApacheモジュールはmod_perlで作れるわけなので、Template::Toolkitとかでよいのではないかと思います。
判りやすいし、汎用性あるし(XSLTは勘弁してくれ...)。
あと、Apacheの層でViewを面倒見ると、どう考えても、どんなサイトでも同じ処理になるもの(例えばケータイ絵文字変換等)はApache層でだけ作ってやれば、ロジック層でPerl用の絵文字変換処理、php用の絵文字変換処理、とか同じ機能のものをいくつも作ってやる必要もなくて、その点でも経済的。
同様にレスポンスだけでなくリクエストに対してもフックしてやれば、携帯の機種判定や位置情報の処理なんかもApacheのリクエスト層で判別して環境変数に展開してやると、Perl用のケータイ判定、php用のケータイ判定、等を作る必要がなくなる。
問題は、mod_proxyやmod_jkを利用しているアクセスに対しても、リクエスト/レスポンスをフックして共通処理を適用できるのか、とかいうところだけど...どうなんだろう。
よく判らない。
...みたいなことを考えたんですけど、どうでしょう?
----- 追記 -----
*1えっと、
隣の部署が開発したフレームワークを導入
とか書いてますけど、ここで書いてるフレームワークっつうのはCatalystやRuby on Railsみたいな抽象度の高い、システム開発のフレームワークと言うものではなく、既に利用度の高いユースケースをコーディング済みで用意してあり、個々のサービス開発者はそのユースケースの出力するXMLに適用するXSLTを書くだけ、というもので、導入に開発やコーディングが必要なものではありません。
導入と言う私のタスクも、うちの部署のサービスにあったXSLT部分を書くだけで、コーディングや開発は一切私のミッションには入っていません。
私の今の仕事は広報やマーケティング、特に最近はSEO施策の検討とかで、個人の本音の希望は別として、ミッションは技術屋ではありません。
さんざん今まで書いてきてるのでずっと読んでいただいている方にはご存知いただけているでしょうが、この記事だけ読むと上記部分の書きようが悪しいせいで勘違いされるかもしれないので、一応書いておきます。
という感じで、脳に障害のあるっぽい中二病野郎を近日全力でDISり倒すための布石を一応打っておきます。
Apache2.0から搭載されたフィルタを使えばできます。
mod_perl経由だとよく分かりません。
っていうか
XMLSchemaとかXSLTとか
完全に理解して実用してる人って
世の中に何人いるんだーとか思う時があります。
>まちゅさん
情報ありがとうございます。
今のフレームワークはできたばかりなので、入社したての私がたかだか1件案件に適用しただけでアーキテクチャ改造等は切り出しにくいのですが、
もし社内で今後フレームワークをアップデートしようとするような機運がでてくれば、この記事のようなことも提案してみようと思います。
>まぐろさん
私も全然XSLTは使いこなしているレベルではないです。
本気で使いこなしていればapply-template使いになるんでしょうが、call-templateの嵐で...(私に限らずみんなですが)。
![[ここギコ!]](http://kokogiko.net/logo.png)



・「定義できない」とのたまうものを自説根拠の説明の中で延々と使う不誠実(笑)(むにゅう!)
・絵文字標準化でのキャリア批判に思うこと(kokogiko)
・文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択(むにゅう!)
・絵文字標準化でのキャリア批判に思うこと(ひゅ〜)
・絵文字標準化でのキャリア批判に思うこと(kokogiko)
・文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択(kokogiko)
・文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択(むにゅう!)
・文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択(むにゅう!)
・文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択(むにゅう!)