2002-06-10 (Mon)

_ Viewにどこまでロジックを書くか

mikiさんのご指摘どおりなのですが、私の中で答えが出ていません。「数を表示するとき、10を超えたら赤く書く」を実装する場合、結論としてはcase by caseなのですが、次の3通りのやり方があると思います。Velocity文法をまだ理解していないので、書き方は適当です。

(1)ViewでIF文
if ($int>10)
  <font color="red">$int</font>
else
  $int
(2)RangeIntegerクラスを作り、そこでIF文
if ($rangeInteger.isOutOfRange)
  <font color="red">$rangeInteger.toString</font>
else
  $rangeInteger.toString
(3)RangeIntegerクラスとOutOfRangeクラスを作り、fontタグを含めてそこに書き、継承や多態で処理。
$rangeInteger.toString

_ で、「今」の私の好みは(3)[ないし(2)]です。(1)ではありません。「10を超えたら赤く書く」はある意味ロジックと捉えます。もちろん赤を青に変更しやすいようなロジックとして実装するのですが。その心は、ViewはTestCaseしにくいからです。なるべくTestCaseとして実装できるようにし(私の言葉ではユニットテスト可能性[TestCaseablity(笑)])、Viewは極めて軽く、が早く・安いコーディングかなと思っています。もちろんcase by caseというか、refactoring次第なのですが。

_ telnetの接続が遅い&操作しないと切れる

遅いのはDNSの逆引きに時間がかかっているのかもしれません。クライアントDNSの逆引きを設定してみましょう。

環境変数TMOUTで、タイムアウト秒数を設定します。0で無限大。

本日のツッコミ(全5件) [ツッコミを入れる]
_ miki (2002-06-10 (Mon) 23:05)

VelocityはWebデザイナのような非JavaプログラマにViewを書かせることが可能であるという点こそメリットがあると思います。ですから、(2)(3)はVelocityでももちろん実現可能ですが、Webデザイナが理解できないという点で「らしくない」と思います。Velocityのマクロはオブジェクト指向ではありませんし、凝ったことはできませんが、非常に単純です。私にとってはこの単純さとわかりやすさこそが魅力です。スクリプトがTestCaseにのりにくいのは確かにそうです。

_ miki (2002-06-11 (Tue) 09:17)

VelocityではJavaオブジェクトをスクリプトでアクセスできるようにするため、Java側でVelocityContextにkeyとvalueをセットします。VelocityContext context = new VelocityContext(); context.put("date", new Date())のような感じです。スクリプト側では$dateでアクセスできます。つまり、View内で複雑なロジックが必要ならばJava側でそれを吸収することが可能です。今回の例では<font color="$intColor">$int</font>とすることもできるわけです。

_ ASIP (2002-06-12 (Wed) 07:18)

#WebデザイナにVelocityスクリプトの習得を強要はできないし、Viewがロジックの塊というのも良くないと思うので、「View内で複雑なロジックが必要ならばJava側でそれをできるだけ吸収する」のがやはり最良の方法だと思います。

_ miki (2002-06-12 (Wed) 11:33)

文字が赤くなるという例が悪かったようです。もちろん不要なロジックの記述は避けるべきですが、HTMLのタグを動的に切替える場合にはif文は必要です。同様に、動的なテーブル作成のような場合はfor文は避けられませんね。これらをJava側で書いたらHTMLのタグがJavaのコードに現れてしまう。Viewに固有の情報を操作するにはView側でやるしかありません。Velocityはこの切り分けにVelocity変数を使っています。JSPはこのあたりが混然一体となっています。カスタムタグを使うという手ももちろんありますが、カスタムタグを修正したい場合や、タグ自身が足りない場合はデザイナはお手上げです。

_ ASIP (2002-06-12 (Wed) 14:03)

タグをJavaのコードに埋め込まないことを前提として「View内で複雑なロジックが必要ならばJava側でそれをできるだけ吸収する」のが最良の方法と書いたつもりだったのですが、記述が足りなかったようです。カスタムタグはデザイナとのコラボレーションを考えた場合、度外視すべき技術だと思います。

[]