2007年04月10日

Viewは完全にロジックから切り離してApacheモジュールとかで面倒見たらどうだろうか

Posted by nene2001 at 13:55 / Tag(Edit): template apache architecture / 3 Comments: Post / View / 0 TrackBack / Google Maps このエントリーを含むはてなブックマーク

うちの部署が公開するサービスの構築に、社内の技術資産流用の一環として、隣の部署が開発したフレームワークを導入*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り倒すための布石を一応打っておきます。 

Related query words in Google & Yahoo
Related Books from Amazon
Trackback to this entry
TrackBack URL :
Trackbacks
トラックバックはありません。
Comments

Apache2.0から搭載されたフィルタを使えばできます。
mod_perl経由だとよく分かりません。

Posted by: まちゅ at 2007年04月10日 14:41

 っていうか
XMLSchemaとかXSLTとか
完全に理解して実用してる人って
世の中に何人いるんだーとか思う時があります。

Posted by: まぐろ@東2 at 2007年04月10日 22:14

>まちゅさん
情報ありがとうございます。
今のフレームワークはできたばかりなので、入社したての私がたかだか1件案件に適用しただけでアーキテクチャ改造等は切り出しにくいのですが、
もし社内で今後フレームワークをアップデートしようとするような機運がでてくれば、この記事のようなことも提案してみようと思います。

>まぐろさん
私も全然XSLTは使いこなしているレベルではないです。
本気で使いこなしていればapply-template使いになるんでしょうが、call-templateの嵐で...(私に限らずみんなですが)。

Posted by: kokogiko at 2007年04月15日 09:02
Post a comment












Remember personal info? 
2007年04月
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          

About Me

Navigation

Search
Google
Web
kokogiko.net
Archives
Recent Entries
Recent Comments
Recent Trackbacks
姫路のオモシロ寿司屋(ここギコ!)
0系こだまとひかりレールスターに乗ってきた ドクターイエローも見た
姫路のオモシロ寿司屋(ここギコ!)
位置情報ベース広告AdLocalへ一般からも入札が可能に
「定義できない」とのたまうものを自説根拠の説明の中で延々と使う不誠実(笑)(ここギコ!)
文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択
現代アイヌの政治運動は利権獲得のためのようだな。(むにゅう!の平和大好き! はてな基地)
文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択
的外れですた恥ずかしい Googleは世界標準の絵文字を作ろうとしてるわけではない、少なくとも、今のところ(ここギコ!)
絵文字標準化でのキャリア批判に思うこと
すごい職場の活性法(これが答えだ)
人員がクラスタ化できている職場と言うのはうらやましい そろそろ限界です
文化は変わっていくのは当たり前だからこそ、今問われているのはリアルタイムの選択(ここギコ!)
大和民族の定義云々について
歴史のダイナミズムの元では右翼こそ変わらなければならない(ここギコ!)
右翼はアイヌや沖縄を包摂する論理を構築すべきではないのか
右翼はアイヌや沖縄を包摂する論理を構築すべきではないのか(ここギコ!)
大和民族の定義云々について
政治と祭祀が不可分と考えるなら、全ての祭祀を引き受けるのが筋(ここギコ!)
大和民族の定義云々について
Hatena bookmarked
My del.icio.us

Banners

Syndication
Powered by
Get it!!