Taglibs are intended to be the savior for JSP. They are billed as the
way to allow one to extend JSP so that there is a nice MVC abstraction
while still adding functionality to the base "language". This is where
Struts has concentrated a good portion of its efforts by providing a
nice taglib library for people to use.
taglib は、JSP のための救世主になるべく生み出されました。
MVC をうまく抽象化しつつ、基本「言語」に機能をさらに加えられるように、
JSP を拡張できる方法として宣伝されています。
この利点から、Struts では、ユーザがすぐれた taglib ライブラリを使えるようにすることに、
相当注力しました。
The advantage of using taglibs is that they allow you to extend the
"language" syntax of JSP to provide the things that are missing from it,
but are available in Java. In other words, instead of encouraging people
to embed Java code within their pages, this has been now abstracted to
encouraging people to embed XML tags in their page. How is this any
better than what ColdFusion did with their product? JSP is on the
cutting edge of re-inventing the broken wheel. Yea!
taglib を使う利点は、JSP 「言語」の構文を拡張することで、JSP にはないけれども、
Java なら実現可能な機能を提供できることです。
言い換えると、ページ内に Java コードを埋め込むことを推奨する代わりに、
ページ内に XML タグを埋め込むことを推奨するという方向に抽象化されたのです。
これは ColdFusion で行われたことより、どのくらい良くなるのでしょうか?
JSP で行われているのは、壊れた車輪の再発明の極致です。いや本当に。
This is an example that shows how logic would be embedded into your JSP
page. It is borrowed directly from the Struts documentation.
これは、ロジックが JSP ページにどのように埋め込まれるかを示す例です。
Struts のドキュメントから直接拝借しています。
 |
|
|
|
<%@ page language="java" %>
<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
<!-- Is the number guess right? -->
<logic:equal parameter="number" value="7">
You guessed right! You win a high speed blender!
</logic:equal>
<!-- If the number guessed was wrong -->
<logic:notEqual parameter="number" value="7">
<!-- Less Than -->
<logic:lessThan parameter="number" value="7">
A little higher...
</logic:lessThan>
<!-- Greater Than -->
<logic:greaterThan parameter="number" value="7">
A little lower...
</logic:greaterThan>
</logic:notEqual>
|
|
|
|
|
|
|
|
|
<%@ page language="java" %>
<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
<!-- Is the number guess right? -->
<logic:equal parameter="number" value="7">
You guessed right! You win a high speed blender!
</logic:equal>
<!-- If the number guessed was wrong -->
<logic:notEqual parameter="number" value="7">
<!-- Less Than -->
<logic:lessThan parameter="number" value="7">
A little higher...
</logic:lessThan>
<!-- Greater Than -->
<logic:greaterThan parameter="number" value="7">
A little lower...
</logic:greaterThan>
</logic:notEqual>
|
|
|
|
|
The same example using Velocity would be written like this:
同じ例を Velocity で書くと以下のようになります。
|
|
|
|
<!-- Is the number guess right? -->
#if ( $number == 7 )
You guessed right! You win a high speed blender!
#end
<!-- If the number guessed was wrong -->
#if ( $number != 7 )
<!-- Less Than -->
#if ( $number < 7 )
A little higher...
<!-- Greater Than -->
#elseif ( $number > 7 )
A little lower...
#end
#end
|
|
|
|
|
|
|
|
|
<!-- Is the number guess right? -->
#if ( $number == 7 )
You guessed right! You win a high speed blender!
#end
<!-- If the number guessed was wrong -->
#if ( $number != 7 )
<!-- Less Than -->
#if ( $number < 7 )
A little higher...
<!-- Greater Than -->
#elseif ( $number > 7 )
A little lower...
#end
#end
|
|
|
|
|
Of course this could be written even cleaner as:
もちろん以下のようにさらに簡潔に記述することもできます。
|
|
|
|
#if($number == 7)
You guessed right! You win a high speed blender!
#elseif( $number < 7 )
lower
#else
higher
#end
|
|
|
|
|
|
|
|
|
#if($number == 7)
You guessed right! You win a high speed blender!
#elseif( $number < 7 )
lower
#else
higher
#end
|
|
|
|
|
This really falls into a preferences situation. In other words, which
syntax would someone prefer to use? It seems as though the amount of
typing required to implement the taglibs approach would be a major
deciding factor for many people. One reason is that the more typing that
needs to be done, the more chances for errors. Lets continue with
another example taken from the Struts documentation:
これは結局のところ好みの問題になります。
言い換えると、どちらの構文を使うのを好むかということです。
多くの人はタイピング回数を理由にtaglibを使っているようですが、
タイピングの量が多いほど、エラーの可能性も高くなりますよね。
さて、Struts のドキュメントから引用した別の例に移りましょう。
|
|
|
|
<%@ page language="java" %>
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
<%
java.util.ArrayList list = new java.util.ArrayList();
list.add("First");
list.add("Second");
list.add("Third");
list.add("Fourth");
list.add("Fifth");
pageContext.setAttribute("list", list, PageContext.PAGE_SCOPE);
%>
<logic:iterate id="myCollectionElement" name="list">
Element Value: <bean:write name="myCollectionElement" /><br />
</logic:iterate>
|
|
|
|
|
It is clear from the Struts example above that the whole strict MVC
model has been broken again because a call to
java.util.ArrayList and creating an Object is embedding
Java code within a template. Compound that with the idea that one needs
to place that ArrayList into the pageContext
is even more confusing. Not only that but the designer has to remember
to use a bunch of cryptic code at the top of the file that makes
references to some taglib document as well as declare a prefix
attribute. Why do things need to be so overly complicated?
上記の Struts の例で厳密な MVC モデル全体が再び壊れたのは明らかです。
java.util.ArrayList の呼び出しとオブジェクトの作成処理が
テンプレート内に Java コードとして埋め込まれているからです。それに加えて、
pageContext に ArrayList
を設定するという考え方は混乱を招きます。それだけでなく、
デザイナは、ファイルの最初にある、taglib 文書の参照とか、prefix 属性の宣言といった、
分けのわからないコードを忘れないようにしなければなりません。
なぜ、物事をそんなに複雑にする必要があるのでしょう？
The same example using Velocity would be written like this:
同じ例を Velocity で書くと以下のようになります。
|
|
|
|
#set ( $list = ["First", "Second", "Third", "Fourth", "Fifth"] )
#foreach ( $item in $list )
Element Value: $item<br />
#end
|
|
|
|
|
Moving on with examples, we come back to the previous sample application provided in Jason
Hunter's book that was shown before. This time it has been implemented
entirely within the Struts framework.
色々な例を見てきましたが、先述の Jason Hunter の書籍で提供されている、
前の方のページで紹介したサンプル・アプリケーション
に戻ってみましょう。
今度は Struts フレームワークで完全に実装されています。
|
|
|
|
<%-- toolview-tag.jsp --%>
<%@ taglib uri="/WEB-INF/struts.tld" prefix="struts" %>
<%
String title = "Tool Listing";
String deck = "A list of content creation tools";
String desc = "Without tools, people are nothing more than animals.";
%>
<%@ include file="/header.jsp" %>
<%@ page session="false" %>
<%@ page errorPage="/errorTaker.jsp" %>
<%-- Fetch the tools array as a request attribute --%>
<jsp:useBean id="tools" class="Tool[]" scope="request"/>
<struts:iterate id="tool" collection="<%= tools %>">
<HR SIZE=2 ALIGN=LEFT>
<H3>
<%-- Automatically HTML-escapes values --%>
<struts:property name="tool" property="name" />
<% if (((Tool)tool).isNewWithin(45)) { %>
<FONT COLOR=#FF0000><B> (New!) </B></FONT>
<% } else if (((Tool)tool).isUpdatedWithin(45)) { %>
<FONT COLOR=#FF0000><B> (Updated!) </B></FONT>
<% } %>
</H3>
<A HREF="<struts:property name="tool" property="homeURL"/>">
<struts:property name="tool" property="homeURL"/></A><BR>
<%-- Assume don't want HTML in comments --%>
<struts:property name="tool" property="comments" />
</struts:iterate>
<%@ include file="/footer.jsp" %>
|
|
|
|
|
At this point, we now have a combination of standard JSP tags as well as
Struts specific tags. The use of Struts has appeared to clean things up
significantly with regards to embedded scriptlets. Note that quite a
few of JSP's warts are still shining through. Is it as easy to grok
as the Velocity version?
今度は、標準の JSP タグと Struts 固有のタグの組み合わせになっています。
Struts を使うことで、埋め込みスクリプトレットについてはすごくきれいになったようです。
しかしながら、JSP の欠点がまだかなり残っているのに注意してください。
Velocity 版と同じくらい理解しやすいでしょうか？
Velocity comes in with a simpler soluton that is designed around the
idea of a few core template tags. A scripting language is something like
PHP which may require months of usage to completely master. A template
language is something that can be mastered in just a few hours. This is
what differentiates Velocity from being a scripting language vs. a
template language.
Velocity では、いくつかの中心的なテンプレートタグという考え方を元に設計された、
もっと単純な解決策を提供します。
スクリプト言語は、PHPのように、完全にマスターするには
何ヵ月も使用しないといけないかも知れません。
テンプレート言語は、たった２、３時間でマスターできます。
これこそが、テンプレート言語に対するスクリプト言語と Velocity を差別化する点です。
For example, Velocity has the following core template tags (otherwise
known as "directives"):
例えば、Velocity には以下の中心的なテンプレートタグ (別名「指示子」) があります。
|
|
|
|
#if
#else
#elseif
#foreach
#set
#parse
#include
|
|
|
|
|
It is possible to add more #directives to Velocity either by adding them
directly to the parser or adding them through an API. It is also
possible to use a neat feature of Velocity called Velocimacro's which
are documented here.
# 指示子を直接パーサに追加するか、APIを通して追加するかのどちらかの
方法で、より多くの # 指示子を Velocity に加えることもできます。
Velocimacro と呼ばれる Velocity のすぐれた機能も使えます。
Velocimacro については、こちらで
文書化されています。
Some people suggest that the benefit to JSP and Struts is that it simply
extends HTML, which is something that designers already understand. This
is a powerful argument. However, the reality is that HTML is not a
template language. In other words, there is no logic in HTML. For
example, it is not possible to embed conditional statements (like in the
very first example above) into HTML.
一部の人が示唆するように、JSP と Struts の利点は、
デザイナがすでに理解している HTML を分かりやすく拡張していることにあります。
これは説得力のある意見だと思います。しかし、実際問題として、
HTML はテンプレート言語ではありません。つまり、HTMLにはロジックがありません。
例えば、(上の最初の例でのように) 条件文を HTML に埋め込むことはできません。
What this means is that Taglibs allow developers to infinitely extend
HTML to become much much more than it previously was. Almost like
inventing another scripting language. This is reminiscent the early
browser wars where each company was implementing their own browser tags.
Netscape went so far as to invent the <blink> tag. What did we
learn from that? Is that really a good thing? Sure, standardizing
taglibs is a great idea. Will it ever become widely adopted? We sure
hope so.
これがどういうことかというと、taglib では開発者が HTML を元の形とは全然違うように
いくらでも拡張できるということです。
これでは別のスクリプト言語を作るのとほとんど変わりません。このことは、
ブラウザ戦争の初期に、各社が独自タグを実装していたのを思い起こさせます。
Netscape は、<blink> タグを発明するまでになりました。
このことから学んだことは何でしょうか? それは、本当に良いことなのでしょうか?
確かに、taglib の標準化は素晴らしい考えですが、広く採用されることになるのでしょうか?
そうなることを心から願っています。
One last point to make about using a HTML syntax is that this really
pigeon holes JSP and Struts into simply being a tool for creating
dynamic HTML/XML/WML (ie: tag markup) code. Velocity on the other hand
is designed to take as input any type of text (Java, SQL, HTML, etc) and
output anything as a result of running it through its processing engine.
HTML 構文を使うことについての最後のポイントは、これによって、JSP と Struts は
HTML / XML / WML (つまりタグによるマークアップ) を動的に生成するツールとして
限定されてしまうということです。
それに対して、Velocity はどんな種類のテキスト (Java、SQL、HTML など) でも
入力として受け取り、処理エンジンを通して実行した結果はどんなものでも
出力できるような設計になっています。
You make the decision.
[どちらを選ぶかは] あなたが判断してください。
[ Sample App <- Previous |
Next -> Embedded Usage ]
[ サンプル・アプリ <- 前 |
次 -> 組み込みでの使用 ]
