One of the most important differences in writing Jetspeed-2/Portlet API portlets is that you must package your portlet code separate from the Jetspeed portal. In Jetspeed-1, all the user code, the portlet business logic, is packaged in one big war file mixed in with the Jetspeed-1 implementation. The Portlet API clearly abolishes this practice of mixing the portal implementation with @@ -133,23 +134,50 @@ A portlet application is an extension of a web application. The portlet.xml holds the definitions of one or more portlets and is analogous to the xreg files used in Jetspeed-1.
+Jetspeed 2 / ポートレット API を作成する際のもっとも重要な違いには，Jetspped ポータルからポートレットコードを分離しなければいけない，というものがあります．Jetspeed 1 では，全てのユーザーコード，ポートレットのビジネスロジックは Jetspeed 1 の実装と一緒に，一つの大きな war ファイルにパッケージされていました．ポートレット API は，このポータルの実装とポートレットが混ざりあっているのを，はっきりと廃止しました．Jetspeed 2 は，それ自身一つのウェブアプリケーションとしてパッケージされています．Jetspeed 2 のためのポートレットを開発する場合，あなたは自身のポートレットを開発し，それをパッケージングする必要があります．ポートレットのクラスと配備記述子は，ポートレットアプリケーションとして，一つの war ファイルの中に全てパッケージされていなければいけません．ポートレットアプリケーションは，配備記述子，portlet.xml と，一つまたはそれ以上のポートレットを含みます．ポートレットアプリケーションは，ウェブアプリケーションの拡張です．portlet.xml は，一つ以上のポートレットの定義を保持します．portlet.xml は，Jetspeed 1 で使われた xreg ファイルに似ています． +
In this section we demonstrate how to convert a Jetspeed-1 portlet to a JSR-168 Java Standard Portlet. This involves the following steps:
++ この節では，どのように Jetspeed 1 ポートレットから JSR-168 Java 標準のポートレットへの変換を行うのかを，実際に示してみます．以下のようなステップが必要となります． +
+- Converting the Portlet Init Java Code
- Converting the Portlet getContent Java Code
- Converting a Turbine Action
-
+
- ポートレットの初期化の Java コードの変換 +
- ポートレットの getContent Java コードの変換 +
- Turbine アクションの変換 +
Jetspeed-1 portlet implementations are normally separated between two different Java source files.
++ Jetspeed 1 のポートレットの実装は，普通，2 つの異なる Java ソースファイルに分かれています． +
+- The Portlet Source Code
- The Turbine Action Source Code
-
+
- ポートレットのソースコード +
- Turbine のアクションソースコード +
The Portlet Source Code handles the View part of the MVC pattern. The getContent method is the standard method in Jetspeed-1 to call to render the content of a portlet. The corresponding methods @@ -158,9 +186,18 @@ should not perform any business logic or other manipulation on the Model. All model manipulation should be left to the action phase
++ ポートレットのソースコードは，MVC パターンの View 部分を処理します．getContent メソッドは，ポートレットのコンテンツを描画するために呼ばれる，Jetspeed 1 の標準メソッドです．Jetspeed 2 とポートレット API において，これと一致するメソッドは doView, doEdit, doHelp です．ポートレット API の用語で，ポートレットの処理のこのフェーズは，描画フェーズ (render phase) として知られています．描画フェーズの間，ポートレットは，いかなるビジネスロジックやモデルの他の操作を行うべきではありません．全てのモデル操作は，アクションフェーズに委ねるべきです． +
+The Turbine Action performs the action phase of the portlet processing. During the action phase of the Portlet API standard, rendering of all other portlets is blocked until the action completes. This is also true in the Jetspeed-1/Turbine model.
++ Turbine アクションは，ポートレット処理のアクションフェーズを実行します．ポートレット API 標準のアクションフェーズの間，他の全てのポートレットの描画は，アクションが終わるまで遮断されます．これは Jetspeed 1/Turbine モデルでも同様です． +
The best place to get started in migrated your portlet is to create a new JSR-168 standard portlet. Simply create a new Java class inheriting from the GenericPortlet interface provided by the Portlet API. From svnnotify ＠ sourceforge.jp Wed Jun 18 19:23:43 2008 From: svnnotify ＠ sourceforge.jp (svnnotify ＠ sourceforge.jp) Date: Wed, 18 Jun 2008 19:23:43 +0900 Subject: [Jetspeed-japan-trans] [46] update translate Message-ID: <1213784623.780300.24113.nullmailer@users.sourceforge.jp> Revision: 46 http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi?root=jetspeed-japan&view=rev&rev=46 Author: karma Date: 2008-06-18 19:23:43 +0900 (Wed, 18 Jun 2008) Log Message: ----------- update translate Modified Paths: -------------- jetspeed-2-trans/trunk/ja/xdocs/j1-migration.xml -------------- next part -------------- Modified: jetspeed-2-trans/trunk/ja/xdocs/j1-migration.xml =================================================================== --- jetspeed-2-trans/trunk/ja/xdocs/j1-migration.xml 2008-06-17 07:23:37 UTC (rev 45) +++ jetspeed-2-trans/trunk/ja/xdocs/j1-migration.xml 2008-06-18 10:23:43 UTC (rev 46) @@ -198,13 +198,18 @@
Turbine アクションは，ポートレット処理のアクションフェーズを実行します．ポートレット API 標準のアクションフェーズの間，他の全てのポートレットの描画は，アクションが終わるまで遮断されます．これは Jetspeed 1/Turbine モデルでも同様です．
-The best place to get started in migrated your portlet is to create a new JSR-168 standard portlet. Simply create a new Java class inheriting from the GenericPortlet interface provided by the Portlet API. You can also use one of the frameworks or bridges available from Apache Portals or Spring MVC. The example below writes directly to the Portlet API. The code below can be used a skeleton for writing a portlet.
+あなたのポートレットの移行を始めるのに最も良い方法は，JSR-168 準拠の新しいポートレットを作成することです．単純に，ポートレット API が規定している GenericPortlet インターフェースを継承する，新しい Java クラスを作成してください．Apache Portals や Spring MVC から提供されるフレームワークやブリッジを利用することも可能です．以下の例は，直接 Portlet API を使って書いています．このコードは，ポートレットを作成する時のスケルトンに使えます． +
+To find out more about Portals Bridges and other Frameworks, explore these links:
++ 更にポータルブリッジや他のフレームワークについて調べるには，以下を参照してください． +
+- Portals Bridges
- JSF Bridge @@ -250,6 +298,14 @@
- Velocity Bridge
- Spring Portlet MVC
From svnnotify ＠ sourceforge.jp Thu Jun 26 13:54:57 2008 From: svnnotify ＠ sourceforge.jp (svnnotify ＠ sourceforge.jp) Date: Thu, 26 Jun 2008 13:54:57 +0900 Subject: [Jetspeed-japan-trans] [47] update translate Message-ID: <1214456097.512941.12352.nullmailer@users.sourceforge.jp> Revision: 47 http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi?root=jetspeed-japan&view=rev&rev=47 Author: karma Date: 2008-06-26 13:54:57 +0900 (Thu, 26 Jun 2008) Log Message: ----------- update translate Modified Paths: -------------- jetspeed-2-trans/trunk/ja/xdocs/j1-migration.xml -------------- next part -------------- Modified: jetspeed-2-trans/trunk/ja/xdocs/j1-migration.xml =================================================================== --- jetspeed-2-trans/trunk/ja/xdocs/j1-migration.xml 2008-06-18 10:23:43 UTC (rev 46) +++ jetspeed-2-trans/trunk/ja/xdocs/j1-migration.xml 2008-06-26 04:54:57 UTC (rev 47) @@ -307,23 +307,43 @@
The Portlet Source code handles the Init phase of a portlet lifecycle. The init phase is very similar in both the Java Portlet API and in Jetspeed 1. Here we have an example of the init method of a Jetspeed-1 portlet:
++ ポートレットのソースコードは，ポートレットのライフサイクルの Init フェーズを扱います．Init フェーズは Java Portlet API と Jetspeed 1 で非常に良く似ています．ここに Jetspeed 1 ポートレットの init メソッドの例を挙げてみます． +
+The equivalent method in the Portlet API (Jetspeed-2) would be, note the difference being the PortletConfig parameter (although the exception classes are named the same, they are entirely different classes, one from Jetspeed-1, the other from the Portlet API):
++ Portlet API (Jetspeed 2) にも同等のメソッドがあって，PortletConfig パラメータの存在が違うことに注意してください (例外クラスが同じ名前ですが，まったく違うクラスです．片方は Jetspeed 1 のもの，他方は Portlet API のものです)． +
+In Jetspeed-1, you would normally access Turbine Services with static acccessors, for example:
+Jetspeed 1 では，通常，静的なアクセサで Turbine サービスにアクセスします．例えば，
+In Jetspeed-2, Jetspeed Services the standard way to access Jetspeed Services is to get a handle in the init phase, for example:
+Jetspeed 2 では，Jetspeed サービスにアクセスする標準的な方法は，init フェーズでハンドルを取得します．
+In Jetspeed-1, the getContent method renders the content of your portlet. The render phase of Jetspeed-1 is implemented by the getContent method of your Portlet as defined by the Jetspeed-1 Portlet interface.
++ Jetspeed 1 では，getContent メソッドは，ポートレットのコンテンツを描画します．Jetspeed 1 の描画フェーズは，Jetspeed 1 ポートレットインターフェースで定義されたポートレットの getContent メソッドによって実装されています． +
+The only parameter passed in to the getContent method is a RunData parameter. RunData is a part of the Turbine web framework. RunData is basically a wrapper around the Servlet request and response, along with other Turbine-specific information. When writing portlets for Jetspeed-2, you write to the Portlet API.
++getContent メソッドが処理するたった一つのパラメータは RunData パラメータです．RunData は Turbine ウェブフレームワーク の一部分です．RunData は基本的に，他の Turbine 特有の情報と一緒に，サーブレットのリクエストとレスポンスを包むラッパーです．Jetspeed 2 に対するポートレットを書く時は，Portlet API を使って書きます． +
+The doView method is the Portlet API equivalent of the getContent method of the Jetspeed-1 API. The Portlet API has the concept of portlet modes. There are three default portlet modes view, edit, and help. For each of these modes, there are three methods you can override in your portlet: doView, doEdit and doHelp. @@ -387,6 +470,10 @@ yourself by reading the Portlet specification as well as any articles or books on the subject. A good book to get started on the Portlet API is Portlets and Apache Portals.
++doView メソッドは，Jetspeed 1 API の getContent メソッドと同等の，ポートレット API のメソッドです．ポートレット API は ポートレットのモード の概念を持ちます．view, edit, help の 3 つのデフォルトのポートレットモードがあります．これらのモードそれぞれに対して，あなたのポートレットがオーバーライド出来る 3 つのメソッドがあります．doView, doEdit, doHelp です．Jetspeed 1 では，RunData パラメータ 1 つだったところが，ポートレットAPI では，より Servlet API 的な RenderRequest と RenderResponse の 2 つのパラメータを持つことに注意してください．あなたのアプリケーションを移行する最も大きな部分の 1 つが RunData を RenderRequest と RenderReponse に変換する事でしょう．移行を始める前に，Portlet API のトレーニングコースを受講するか，ポートレット仕様を自分で読んだ上に，関連する記事や書籍を読んで，API を学ぶ事をおすすめします．ポートレット API を学び始めるのに良い書籍に，Portlets and Apache Portals があります． +
When rendering content, Jetspeed 1 makes use of a HTML construction kit called ECS. All rendering goes through Turbine and ECS.
The return type of the getContent method is a ConcreteElement, which is defined in the ECS API. Here is the typical way to
generate output from a portlet in Jetspeed-1:
From karma ＠ jazz.email.ne.jp Thu Jun 26 14:01:21 2008
From: karma ＠ jazz.email.ne.jp (KATOH Yasufumi)
Date: Thu, 26 Jun 2008 14:01:21 +0900
Subject: [Jetspeed-japan-trans] typo? in j1-migration.xml
Message-ID:
doView メソッドは，Jetspeed 1 API の getContent メソッドと同等の，ポートレット API のメソッドです．ポートレット API は ポートレットのモード の概念を持ちます．view, edit, help の 3 つのデフォルトのポートレットモードがあります．これらのモードそれぞれに対して，あなたのポートレットがオーバーライド出来る 3 つのメソッドがあります．doView, doEdit, doHelp です．Jetspeed 1 では，RunData パラメータ 1 つだったところが，ポートレットAPI では，より Servlet API 的な RenderRequest と RenderResponse の 2 つのパラメータを持つことに注意してください．あなたのアプリケーションを移行する最も大きな部分の 1 つが RunData を RenderRequest と RenderReponse に変換する事でしょう．移行を始める前に，Portlet API のトレーニングコースを受講するか，ポートレット仕様を自分で読んだ上に，関連する記事や書籍を読んで，API を学ぶ事をおすすめします．ポートレット API を学び始めるのに良い書籍に，Portlets and Apache Portals があります．
When rendering content, Jetspeed 1 makes use of a HTML construction kit called ECS. All rendering goes through Turbine and ECS.
The return type of the getContent method is a ConcreteElement, which is defined in the ECS API. Here is the typical way to
generate output from a portlet in Jetspeed-1:
+コンテンツを描画するとき，Jetspeed 1 は ECS と呼ばれる HTML 構築キットを使います．全ての描画は，Turbine と ECS を通じて行われます．
+ When rendering content in Jetspeed-2, the Portlet API uses a streaming interface:
+Jetspeed 2 では，コンテンツを描画するとき，ポートレット API はストリーミングインターフェースを使います．
+ Of course you can use JSPs or Velocity with either Jetspeed-1 or Jetspeed-2.
With Jetspeed-1, the common practice is to make use of the Jetspeed-1 GenericMVCPortlet or one of its derivitives,
the VelocityPortlet or the JspPortlet. Both the VelocityPortlet and JspPortlet are really just GenericMVCPortlets.
Here is the xreg example of a WeatherPortlet which extends the GenericMVCPortlet by setting its parent to Velocity
+もちろん，Jetspeed 1 か Jetspeed 2 のどちらでも JSP や Velocity を使うことは出来ます．Jetspeed 1 では，良く行われている事に，Jetspeed 1 GenericMVCPortlet またはその派生物，VelocityPortlet または JspPortlet の利用があります．VelocityPortlet と JspPortlet は両方共，GenericMVCPortlets です．ここに，その親に Velocity を設定した GenericMVCPortlet を継承した WeatherPortlet の xreg の例があります．
+ The template parameter is named weather. Since this is a Velocity MVC portlet, Jetspeed-1 knows to look under
the WEB-INF/templates/vm/portlets/html directory to find weather.vm. The MVC portlet will automatically handle
the details of dispatching to this Velocity template to render your portlet. Here is the actual contents of the velocity template.
Note that we don't have to write any portlet Java code in this case, but only the actual template.
テンプレートパラメータは weather と名づけられています．これは Velocity MVC portlet なので，Jetspeed 1 は WEB-INF/templates/vm/portlets/html ディレクトリ以下に weather.vm が見つかることを知っています．MVC ポートレットは自動的に，ポートレットを描画するために，この Velocity テンプレートの割り当てを処理するでしょう．ここに，Velocity テンプレートの実際のコンテンツがあります．この場合，ポートレットの Java コードを書く必要はなく，実際のテンプレートを書くだけで良いことに注意してください． With Jetspeed-2 and the Portlet API, we can make use of the Velocity Bridge or the JSP Bridge to delegate to portlets.
The simplest case is just dispatching the call yourself to the JSP or Velocity servlet. Here is an example of dispatching to a JSP from the doView:
+Jetspeed 2 とポートレット API では，ポートレットに処理を移譲するために，Velocity ブリッジ，もしくは JSP ブリッジを使うことが出来ます．この最も簡単なケースは，自身の呼び出しに JSP か Velocity サーブレットを割り当てるケースです．ここに，doView から JSP を割り当てる例があります．
+ And here is an example of the WeatherPortlet extending the Velocity Bridge, and making use of the Portlet API User Preferences feature,
note that we do not directly create a dispatcher here, but the framework will do that automatically:
そして，ここに Velocity ブリッジを継承した WeatherPortlet の例があります．ここではポートレット API の User Preferences 機能を使っています．ここでは直接ディスパッチャーを作成していないにも関わらず，フレームワークが自動的にそれを実行していることに注意してください．
+ And here is the Velocity template to render the portlet content: そして，ここにポートレットのコンテンツを描画するための Velocity テンプレートがあります．
+#else
+
+#end
+]]>
+
+#end
+]]>
+
The Portlet API defines several phases of execution during the processing of a portlet page. The action phase is designed to be executed
From shinsuke ＠ yahoo.co.jp Thu Jun 26 18:21:52 2008
From: shinsuke ＠ yahoo.co.jp (Shinsuke SUGAYA)
Date: Thu, 26 Jun 2008 18:21:52 +0900
Subject: [Jetspeed-japan-trans] typo? in j1-migration.xml
In-Reply-To:
The Portlet API defines several phases of execution during the processing of a portlet page. The action phase is designed to be executed before the render phase of a portlet. There can only be one action phase targeting only one portlet. Once the action phase completes, then the render phase for all portlets on a page can be executed. Thus the action phase is said to be a blocking phase, meaning that it must @@ -737,16 +738,38 @@ action, the Portlet API has an entry point for all actions to come through as a method on your portlet. Frameworks such as the Spring MVC framework provide better abstractions for modeling one method per action.
++ポートレット API は，ポートレットページの処理の間の実行フェーズをいくつか定義しています．アクションフェーズは，ポートレットの描画フェーズの前に実行されるように設計されています．1 つのポートレットだけを対象にした，1 つのアクションフェーズしか存在出来ません．アクションフェーズが完了すると，ページ上の全てのポートレットの描画フェーズが実行出来ます．したがって，アクションフェーズはブロッキングフェーズと言えます．これは，ページ上の各ポートレットの描画フェーズが始まる前に完了していなければいけない事を意味します．アクションは通常，MVC フレームワークの Model を操作する，ある種のユーザとの対話のようなものです．それは，ユーザがフォームに入力を行い，モデルが更新されたり，レコードが追加されたり消去されたりするというようなものです．このアクションの概念は，Turbine と Jetspeed 1 から Jetspeed 2 とポートレット API への移植をかなりうまく行います．Turbine がアクションごとに 1 クラスという概念を持つのに対して，ポートレット API は，全てのアクションを，ポートレットのメソッドを通して行うエントリポイントを持ちます．Spring MVC フレームワークのようなフレームワークは，アクションごとに一つのメソッドを持つモデルに対する，より良い抽象概念を提供します． +
+Lets again look at the WeatherPortlet with Jetspeed-1. First the xreg defines the actions:
++ここで再び Jetspeed 1 の WeatherPortlet を見ましょう．まず，xreg がアクションを定義します． +
+We must then implement the action class which are usually placed in the Jetspeed-1 webapp class loader space. Here is the code for the WeatherAction, which extends a Jetspeed-1 framework class VelocityPortletAction:
++通常，Jetspeed 1 の webapp クラスローダ空間に置かれるアクションクラスを実装する必要があります．ここに WeatherAction のコードを示します．これは，Jetspeed 1 のフレームワーククラスである VelocityPortletAction を継承したものです． +
+In Jetspeed-1 there is some really bad architecture interfering with easily writing portlets. Here in our action, we are actually implementing the View portion of our code by populating the