From svnnotify @ sourceforge.jp Mon Nov 17 17:27:02 2008
From: svnnotify @ sourceforge.jp (svnnotify @ sourceforge.jp)
Date: Mon, 17 Nov 2008 17:27:02 +0900
Subject: [Jetspeed-japan-trans] [62] update translate.
Message-ID: <1226910422.375385.4887.nullmailer@users.sourceforge.jp>
Revision: 62
http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi?root=jetspeed-japan&view=rev&rev=62
Author: karma
Date: 2008-11-17 17:27:02 +0900 (Mon, 17 Nov 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-10-24 09:38:07 UTC (rev 61)
+++ jetspeed-2-trans/trunk/ja/xdocs/j1-migration.xml 2008-11-17 08:27:02 UTC (rev 62)
@@ -2018,24 +2018,45 @@
- There is a big difference with the navigational aspects, or menus, between Jetspeed-1 and Jetspeed-2.
Jetspeed-1 restricts menus navigation to navigation amongst tabs. Tabs are defined within a PSML page.
Tabs are simply subcontainers in the PSML page, defined by the portlets element.
Whereas Jetspeed-1 does support navigation to other pages, the Tabbing Menus do not directly support it without
writing a specific portlet to act as an external link.
+ Jetspeed 1 と Jetspeed 2 の間には,ナビゲーションの外観やメニューに大きな違いがあります.Jetspeed 1 は,メニューナビゲーションを タブ 間のナビゲーションに制限しています.タブは PSML ページ内で定義されます.タブは,portlets 要素で定義される,PSML ページの単なる子のコンテナです.Jetspeed 1 が他のページへのナビゲーションをサポートするのに対して,タブメニューは外部リンクとして動作する特定のポートレットを書かない限りは,それを直接はサポートしません.
+ Jetspeed-2 menu navigations map directly onto the Portal Site. Thus menu tabs represent portal resources.
Menus in Jetspeed-2 can point to folders, pages or links. This more naturally allows the user to navigate
over the entire portal site.
+ Jetspeed 2 のメニューナビゲーションは,ポータルサイト上に直接マッピングされます.それゆえ,メニュータブはポータルリソースを表します.Jetspeed 2 のメニューは,フォルダやページやリンクを指し示すことができます.このことは,より自然にユーザが全ポータルサイト内を移動することが可能になります.
+ When migrating PSML files from Jetspeed-1 to Jetspeed-2, depending on whether you use advanced Jetspeed-1 controllers such as
Card or Tab controllers, you may find that the pages do not port to Jetspeed-2 very well. In consideration of the lack of migration tools,
this leaves two immediate options:
+ Jetspeed 1 から Jetspeed 2 へ PSML を移行する場合,カードやタブコントローラと言った Jetspeed 1 の進んだ機能を使っているかどうかで,Jetspeed 2 への移行が出来る,出来ないが分かるでしょう.移行ツールがないことを考慮して,以下の二つのオプションを当面残してあります.
+
+
+
- Jetspeed 1 と Jetspeed 2 の間には,ナビゲーションの外観やメニューに大きな違いがあります.Jetspeed 1 は,メニューナビゲーションを タブ 間のナビゲーションに制限しています.タブは PSML ページ内で定義されます.タブは,portlets 要素で定義される,PSML ページの単なる子のコンテナです.Jetspeed 1 が他のページへのナビゲーションをサポートするのに対して,タブメニューは外部リンクとして動作する特定のポートレットを書かない限りは,それを直接はサポートしません. + Jetspeed 1 と Jetspeed 2 の間には,ナビゲーションの外観やメニューに大きな違いがあります.Jetspeed 1 は,メニューナビゲーションを タブ 間のナビゲーションに制限しています.タブは PSML ページ内で定義されます.タブは,portlets 要素で定義される,PSML ページの単なる子のコンテナです.Jetspeed 1 が (訳注:ここは Jetspeed 2 の誤りであると思われます.) 他のページへのナビゲーションをサポートするのに対して,タブメニューは外部リンクとして動作する特定のポートレットを書かない限りは,それを直接はサポートしません.
Jetspeed-2 menu navigations map directly onto the Portal Site. Thus menu tabs represent portal resources.
@@ -2059,17 +2059,33 @@
- Jetspeed-2 defines an XML API for populating the initial "Seed" data for your portal.
Populating your seed data via the XML API provides an alternative to populating database data with database-specific and hard to read SQL scripts.
Additionally, the XML API can be used for importing and exporting data, or backing up and restoring from your Jetspeed-2 database.
+ Jetspeed 2 には,あなたのポータルに初期「種」データを注入するための XML API が定義されています.あなたの種データを XML API 経由で注入することは,データベース特有のデータを注入したり,難しい SQL スクリプトを読む代わりとなります.加えて,XML API はデータをインポート,エクスポートしたり,あなたの Jetspeed 2 データベースをバックアップしたりリストアしたりするのにも使えます.
+
The XML API also provides a migration path over the maintenance cycle of your Jetspeed portal.
The XML API was first implemented in version 2.1. To migrate your data from version 2.1 to 2.2, (if there are any database schema changes),
the XML API can be used to migrate (by exporting and importing) across versions.
+ XML API は,あなたの Jetspeed ポータルのメンテナンスサイクル全体での移行パスも提供します.XML API は,最初にバージョン 2.1 で実装されました.バージョン 2.1 から 2.2 へデータを移行するために,XML API を両バージョンで使って (エクスポートとインポートを行うことにより) 移行を行うことが可能です.
+ As of 2.1, the Jetspeed API supports the following elements:
+ 2.1 時点で,Jetspeed API は,以下の要素をサポートします.
+ Reference for Jetspeed-2 XML schemas:
+
Element
@@ -2117,6 +2133,54 @@
+
+
+
+ 要素
+ 説明
+
+
+ MimeTypes
+ ポータルがサポートする text/html や text/xhtml などのような Mime Types.
+
+
+ メディアタイプ
+ ポータルがサポートする html, xml, wml 等のようなメディアタイプ.
+
+
+ 機能
+ ポータルにアクセスするウェブクライアントに共通の機能.
+
+
+ クライアント
+ ポータルがサポートするウェブクライアント.
+
+
+ ロール
+ ポータルの初期設定で定義される全てのロール.
+
+
+ グループ
+ ポータルの初期設定で定義される全てのグループ.
+
+
+ ユーザ
+ ポータルの初期設定で定義される全てのユーザ.最少で admin と guest(anon) ユーザ.
+
+
+ パーミッション
+ ポータルに対する初期定義される J2EE セキュリティポリシー.パーミッションはデフォルトではオフになっていることに注意.
+
+
+ プロファイリングルール
+ ポータルに初期で定義されるすべてのプロファイリングルール.例えば role fallback, user-role-fallback, j1-emulation, default-j2, subsites などのような.
+
+
+
+
+
この移行のガイドは,Jetspeed のバージョン 1 からバージョン 2 への移行に役立つでしょう.現状,移行のためのツールはありません.また,バージョン 1 からバージョン 2 への,ポータルのリソースを変換するような移行ツールを作成する予定もありません.この文書は,移行のためのガイドラインのみを提供します. +
この移行のガイドは、Jetspeed のバージョン 1 からバージョン 2 への移行に役立つでしょう。現状、移行のためのツールはありません。また、バージョン 1 からバージョン 2 への、ポータルのリソースを変換するような移行ツールを作成する予定もありません。この文書は、移行のためのガイドラインのみを提供します。
- 新しいポータルの標準 (Portlet API) の開発で,共通のポートレットのメタファが,バージョン 1 の Turbine ベースのものから大幅に変わりました.プログラミング API は完全に変わっています.もはや XREG ファイルはありません.代わりに標準の配備記述子があります.バージョン 1 とは直接結びつかない,ポートレットアプリケーション,ポートレット設定,ユーザ属性,初期パラメータのような,ポートレット標準により導入された新しいコンセプトがあります.移行ツールを作成することは,膨大な仕事を引き受ける事になります.Jetspeed の開発チームは,この投資を行う態勢にはありません.以下のガイドラインを読むと,容易に Jetspeed 1.x から Jetspeed 2 への移行が出来るでしょう.構造の違いの概要を掴むために,For Jetspeed 1 Users という文書を参照してください. + 新しいポータルの標準 (Portlet API) の開発で、共通のポートレットのメタファが、バージョン 1 の Turbine ベースのものから大幅に変わりました。プログラミング API は完全に変わっています。もはや XREG ファイルはありません。代わりに標準の配備記述子があります。バージョン 1 とは直接結びつかない、ポートレットアプリケーション、ポートレット設定、ユーザ属性、初期パラメータのような、ポートレット標準により導入された新しいコンセプトがあります。移行ツールを作成することは、膨大な仕事を引き受ける事になります。Jetspeed の開発チームは、この投資を行う態勢にはありません。以下のガイドラインを読むと、容易に Jetspeed 1.x から Jetspeed 2 への移行が出来るでしょう。構造の違いの概要を掴むために、For Jetspeed 1 Users という文書を参照してください。
The table below gives you an idea of how to migrate. We will cover each subject in more detail further on in this document.
以下の表は,移行方法のアイデアを与えます.この表のそれぞれの項目については後で述べます.
+以下の表は、移行方法のアイデアを与えます。この表のそれぞれの項目については後で述べます。
| 1.x Feature | 2.x Feature | Description | |
|---|---|---|---|
| 1.x の機能 | 2.x の機能 | 説明 | |
| J1 ポートレットの Java コード | ポートレット API 標準のコード | -Java コードを新しい仕様に従って書き直す.Turbine の動きを標準の processAction に置き換える事,Rundata を PortletRequest/Response に置き換える必要があります. | Java コードを新しい仕様に従って書き直す。Turbine の動きを標準の processAction に置き換える事、Rundata を PortletRequest/Response に置き換える必要があります。 |
| XREG ポートレットレジストリ | portlet.xml 配備記述子 | -若干大きな違いがあります.<portlet-entry> を <portlet> エントリに,<parameter> を <preference> もしくは <init-param> に移行してください. | +若干大きな違いがあります。<portlet-entry> を <portlet> エントリに、<parameter> を <preference> もしくは <init-param> に移行してください。 |
| J1 PSML | J2 PSML | -タブからフォルダ,ページに移行してください.新しいタグ文法に移行してください. | +タブからフォルダ、ページに移行してください。新しいタグ文法に移行してください。 |
| XREG セキュリティレジストリ | Security Constraintsセキュリティ制約 | -J1 のセキュリティ制約フォーマットを J2 セキュリティ制約フォーマットに移行してください. | +J1 のセキュリティ制約フォーマットを J2 セキュリティ制約フォーマットに移行してください。 |
| J1 コントローラ | J2 レイアウト | -コントローラは廃止予定で非推奨となりました.新しい Jetspeed 2 のレイアウトポートレットを使うことを推奨します.もし,移植が必要であれば,VM コードの HTML 部分が移植出来るかもしれません.しかし,コンテキストモデルの変数は移植出来ないでしょう. | +コントローラは廃止予定で非推奨となりました。新しい Jetspeed 2 のレイアウトポートレットを使うことを推奨します。もし、移植が必要であれば、VM コードの HTML 部分が移植出来るかもしれません。しかし、コンテキストモデルの変数は移植出来ないでしょう。 |
| J1 コントロール | J2 ポートレットデコレータ | -コントロールは廃止予定で非推奨になりました.新しい Jetspeed 2 のポートレットデコレータを使用することを推奨します.もし,移植が必要であれば,VM コードの HTML 部分が移植出来るでしょう.しかし,コンテキストモデルの変数は移植出来ないでしょう. | +コントロールは廃止予定で非推奨になりました。新しい Jetspeed 2 のポートレットデコレータを使用することを推奨します。もし、移植が必要であれば、VM コードの HTML 部分が移植出来るでしょう。しかし、コンテキストモデルの変数は移植出来ないでしょう。 |
| J1 レイアウト,スクリーン,ナビゲーション | +|||
| J1 レイアウト、スクリーン、ナビゲーション | J2 ページ (レイアウト) デコレータ | -全て廃止予定で非推奨となりました.スタート地点として,あなた自身のページデコレータを書くために,新しい Jetspeed 2 のページ (レイアウト) デコレータを使うことを推奨します.VM コードの HTML 部分は移植出来るでしょう.しかし,コンテキストモデルの変数は移植出来ないでしょう. | +全て廃止予定で非推奨となりました。スタート地点として、あなた自身のページデコレータを書くために、新しい Jetspeed 2 のページ (レイアウト) デコレータを使うことを推奨します。VM コードの HTML 部分は移植出来るでしょう。しかし、コンテキストモデルの変数は移植出来ないでしょう。 |
Jetspeed 2 / ポートレット API を作成する際のもっとも重要な違いには,Jetspped ポータルからポートレットコードを分離しなければいけない,というものがあります.Jetspeed 1 では,全てのユーザーコード,ポートレットのビジネスロジックは Jetspeed 1 の実装と一緒に,一つの大きな war ファイルにパッケージされていました.ポートレット API は,このポータルの実装とポートレットが混ざりあっているのを,はっきりと廃止しました.Jetspeed 2 は,それ自身一つのウェブアプリケーションとしてパッケージされています.Jetspeed 2 のためのポートレットを開発する場合,あなたは自身のポートレットを開発し,それをパッケージングする必要があります.ポートレットのクラスと配備記述子は,ポートレットアプリケーションとして,一つの war ファイルの中に全てパッケージされていなければいけません.ポートレットアプリケーションは,配備記述子,portlet.xml と,一つまたはそれ以上のポートレットを含みます.ポートレットアプリケーションは,ウェブアプリケーションの拡張です.portlet.xml は,一つ以上のポートレットの定義を保持します.portlet.xml は,Jetspeed 1 で使われた xreg ファイルに似ています. +
Jetspeed 2 / ポートレット API を作成する際のもっとも重要な違いには、Jetspped ポータルからポートレットコードを分離しなければいけない、というものがあります。Jetspeed 1 では、全てのユーザーコード、ポートレットのビジネスロジックは Jetspeed 1 の実装と一緒に、一つの大きな war ファイルにパッケージされていました。ポートレット API は、このポータルの実装とポートレットが混ざりあっているのを、はっきりと廃止しました。Jetspeed 2 は、それ自身一つのウェブアプリケーションとしてパッケージされています。Jetspeed 2 のためのポートレットを開発する場合、あなたは自身のポートレットを開発し、それをパッケージングする必要があります。ポートレットのクラスと配備記述子は、ポートレットアプリケーションとして、一つの war ファイルの中に全てパッケージされていなければいけません。ポートレットアプリケーションは、配備記述子、portlet.xml と、一つまたはそれ以上のポートレットを含みます。ポートレットアプリケーションは、ウェブアプリケーションの拡張です。portlet.xml は、一つ以上のポートレットの定義を保持します。portlet.xml は、Jetspeed 1 で使われた xreg ファイルに似ています。
- この節では,どのように Jetspeed 1 ポートレットから JSR-168 Java 標準のポートレットへの変換を行うのかを,実際に示してみます.以下のようなステップが必要となります. + この節では、どのように Jetspeed 1 ポートレットから JSR-168 Java 標準のポートレットへの変換を行うのかを、実際に示してみます。以下のようなステップが必要となります。
- Jetspeed 1 のポートレットの実装は,普通,2 つの異なる Java ソースファイルに分かれています. + Jetspeed 1 のポートレットの実装は、普通、2 つの異なる Java ソースファイルに分かれています。
- ポートレットのソースコードは,MVC パターンの View 部分を処理します.getContent メソッドは,ポートレットのコンテンツを描画するために呼ばれる,Jetspeed 1 の標準メソッドです.Jetspeed 2 とポートレット API において,これと一致するメソッドは doView, doEdit, doHelp です.ポートレット API の用語で,ポートレットの処理のこのフェーズは,描画フェーズ (render 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, @@ -196,7 +196,7 @@
- Turbine アクションは,ポートレット処理のアクションフェーズを実行します.ポートレット API 標準のアクションフェーズの間,他の全てのポートレットの描画は,アクションが終わるまで遮断されます.これは Jetspeed 1/Turbine モデルでも同様です. + Turbine アクションは、ポートレット処理のアクションフェーズを実行します。ポートレット API 標準のアクションフェーズの間、他の全てのポートレットの描画は、アクションが終わるまで遮断されます。これは Jetspeed 1/Turbine モデルでも同様です。
あなたのポートレットの移行を始めるのに最も良い方法は,JSR-168 準拠の新しいポートレットを作成することです.単純に,ポートレット API が規定している GenericPortlet インターフェースを継承する,新しい Java クラスを作成してください.Apache Portals や Spring MVC から提供されるフレームワークやブリッジを利用することも可能です.以下の例は,直接 Portlet API を使って書いています.このコードは,ポートレットを作成する時のスケルトンに使えます. +
あなたのポートレットの移行を始めるのに最も良い方法は、JSR-168 準拠の新しいポートレットを作成することです。単純に、ポートレット API が規定している GenericPortlet インターフェースを継承する、新しい Java クラスを作成してください。Apache Portals や Spring MVC から提供されるフレームワークやブリッジを利用することも可能です。以下の例は、直接 Portlet API を使って書いています。このコードは、ポートレットを作成する時のスケルトンに使えます。
- 更にポータルブリッジや他のフレームワークについて調べるには,以下を参照してください. + 更にポータルブリッジや他のフレームワークについて調べるには、以下を参照してください。
- ポートレットのソースコードは,ポートレットのライフサイクルの Init フェーズを扱います.Init フェーズは Java Portlet API と Jetspeed 1 で非常に良く似ています.ここに Jetspeed 1 ポートレットの init メソッドの例を挙げてみます. + ポートレットのソースコードは、ポートレットのライフサイクルの Init フェーズを扱います。Init フェーズは Java Portlet API と Jetspeed 1 で非常に良く似ています。ここに Jetspeed 1 ポートレットの init メソッドの例を挙げてみます。
- Portlet API (Jetspeed 2) にも同等のメソッドがあって,PortletConfig パラメータの存在が違うことに注意してください (例外クラスが同じ名前ですが,まったく違うクラスです.片方は Jetspeed 1 のもの,他方は 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 サービスにアクセスします.例えば,
+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 フェーズでハンドルを取得します.
+Jetspeed 2 では、Jetspeed サービスにアクセスする標準的な方法は、init フェーズでハンドルを取得します。
- Jetspeed 1 では,getContent メソッドは,ポートレットのコンテンツを描画します.Jetspeed 1 の描画フェーズは,Jetspeed 1 ポートレットインターフェースで定義されたポートレットの getContent メソッドによって実装されています. + Jetspeed 1 では、getContent メソッドは、ポートレットのコンテンツを描画します。Jetspeed 1 の描画フェーズは、Jetspeed 1 ポートレットインターフェースで定義されたポートレットの getContent メソッドによって実装されています。
-getContent メソッドが処理するたった一つのパラメータは RunData パラメータです.RunData は Turbine ウェブフレームワーク の一部分です.RunData は基本的に,他の Turbine 特有の情報と一緒に,サーブレットのリクエストとレスポンスを包むラッパーです.Jetspeed 2 に対するポートレットを書く時は,Portlet API を使って書きます. +getContent メソッドが処理するたった一つのパラメータは RunData パラメータです。RunData は Turbine ウェブフレームワーク の一部分です。RunData は基本的に、他の Turbine 特有の情報と一緒に、サーブレットのリクエストとレスポンスを包むラッパーです。Jetspeed 2 に対するポートレットを書く時は、Portlet API を使って書きます。
-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 があります. +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. @@ -481,7 +481,7 @@
-コンテンツを描画するとき,Jetspeed 1 は ECS と呼ばれる HTML 構築キットを使います.全ての描画は,Turbine と ECS を通じて行われます. +コンテンツを描画するとき、Jetspeed 1 は ECS と呼ばれる HTML 構築キットを使います。全ての描画は、Turbine と ECS を通じて行われます。
When rendering content in Jetspeed-2, the Portlet API uses a streaming interface:
-Jetspeed 2 では,コンテンツを描画するとき,ポートレット API はストリーミングインターフェースを使います. +Jetspeed 2 では、コンテンツを描画するとき、ポートレット API はストリーミングインターフェースを使います。
-もちろん,Jetspeed 1 か Jetspeed 2 のどちらでも JSP や Velocity を使うことは出来ます.Jetspeed 1 では,良く行われている事に,Jetspeed 1 GenericMVCPortlet またはその派生物,VelocityPortlet または JspPortlet の利用があります.VelocityPortlet と JspPortlet は両方共,GenericMVCPortlets です.ここに,その親に Velocity を設定した GenericMVCPortlet を継承した WeatherPortlet の xreg の例があります. +もちろん、Jetspeed 1 か Jetspeed 2 のどちらでも JSP や Velocity を使うことは出来ます。Jetspeed 1 では、良く行われている事に、Jetspeed 1 GenericMVCPortlet またはその派生物、VelocityPortlet または JspPortlet の利用があります。VelocityPortlet と JspPortlet は両方共、GenericMVCPortlets です。ここに、その親に Velocity を設定した GenericMVCPortlet を継承した WeatherPortlet の xreg の例があります。
テンプレートパラメータは weather と名づけられています.これは Velocity MVC portlet なので,Jetspeed 1 は WEB-INF/templates/vm/portlets/html ディレクトリ以下に weather.vm が見つかることを知っています.MVC ポートレットは自動的に,ポートレットを描画するために,この Velocity テンプレートの割り当てを処理するでしょう.ここに,Velocity テンプレートの実際のコンテンツがあります.この場合,ポートレットの Java コードを書く必要はなく,実際のテンプレートを書くだけで良いことに注意してください.
+テンプレートパラメータは weather と名づけられています。これは Velocity MVC portlet なので、Jetspeed 1 は WEB-INF/templates/vm/portlets/html ディレクトリ以下に weather.vm が見つかることを知っています。MVC ポートレットは自動的に、ポートレットを描画するために、この Velocity テンプレートの割り当てを処理するでしょう。ここに、Velocity テンプレートの実際のコンテンツがあります。この場合、ポートレットの Java コードを書く必要はなく、実際のテンプレートを書くだけで良いことに注意してください。
-Jetspeed 2 とポートレット API では,ポートレットに処理を移譲するために,Velocity ブリッジ,もしくは JSP ブリッジを使うことが出来ます.この最も簡単なケースは,自身の呼び出しに JSP か Velocity サーブレットを割り当てるケースです.ここに,doView から JSP を割り当てる例があります. +Jetspeed 2 とポートレット API では、ポートレットに処理を移譲するために、Velocity ブリッジ、もしくは JSP ブリッジを使うことが出来ます。この最も簡単なケースは、自身の呼び出しに JSP か Velocity サーブレットを割り当てるケースです。ここに、doView から JSP を割り当てる例があります。
そして,ここに Velocity ブリッジを継承した WeatherPortlet の例があります.ここではポートレット API の User Preferences 機能を使っています.ここでは直接ディスパッチャーを作成していないにも関わらず,フレームワークが自動的にそれを実行していることに注意してください. +
そして、ここに Velocity ブリッジを継承した WeatherPortlet の例があります。ここではポートレット API の User Preferences 機能を使っています。ここでは直接ディスパッチャーを作成していないにも関わらず、フレームワークが自動的にそれを実行していることに注意してください。
And here is the Velocity template to render the portlet content:
そして,ここにポートレットのコンテンツを描画するための Velocity テンプレートがあります.
+そして、ここにポートレットのコンテンツを描画するための Velocity テンプレートがあります。
-ポートレット API は,ポートレットページの処理の間の実行フェーズをいくつか定義しています.アクションフェーズは,ポートレットの描画フェーズの前に実行されるように設計されています.1 つのポートレットだけを対象にした,1 つのアクションフェーズしか存在出来ません.アクションフェーズが完了すると,ページ上の全てのポートレットの描画フェーズが実行出来ます.したがって,アクションフェーズはブロッキングフェーズと言えます.これは,ページ上の各ポートレットの描画フェーズが始まる前に完了していなければいけない事を意味します.アクションは通常,MVC フレームワークの Model を操作する,ある種のユーザとの対話のようなものです.それは,ユーザがフォームに入力を行い,モデルが更新されたり,レコードが追加されたり消去されたりするというようなものです.このアクションの概念は,Turbine と Jetspeed 1 から Jetspeed 2 とポートレット API への移植をかなりうまく行います.Turbine がアクションごとに 1 クラスという概念を持つのに対して,ポートレット API は,全てのアクションを,ポートレットのメソッドを通して行うエントリポイントを持ちます.Spring MVC フレームワークのようなフレームワークは,アクションごとに一つのメソッドを持つモデルに対する,より良い抽象概念を提供します. +ポートレット 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 がアクションを定義します. +ここで再び Jetspeed 1 の WeatherPortlet を見ましょう。まず、xreg がアクションを定義します。
-通常,Jetspeed 1 の webapp クラスローダ空間に置かれるアクションクラスを実装する必要があります.ここに WeatherAction のコードを示します.これは,Jetspeed 1 のフレームワーククラスである VelocityPortletAction を継承したものです. +通常、Jetspeed 1 の webapp クラスローダ空間に置かれるアクションクラスを実装する必要があります。ここに WeatherAction のコードを示します。これは、Jetspeed 1 のフレームワーククラスである VelocityPortletAction を継承したものです。
-Jetspeed 1 には,簡単にポートレットを作成するのを妨げる,良くない構造がいくつかありました.ここで我々は,実際に context.put ステートメントを持つ Velocity コンテキストを実装することにより,コードの View の一部分を実装しています.buildNormalContext で実装したすべてのコードは,ポートレット API の doView メソッドに移植しなくてはならない事に注意してください.実際のポートレットを,どのようにして 1 番目のパラメータとして,buildNormalContext メソッドに渡さなければならないのかに注意してください. +Jetspeed 1 には、簡単にポートレットを作成するのを妨げる、良くない構造がいくつかありました。ここで我々は、実際に context.put ステートメントを持つ Velocity コンテキストを実装することにより、コードの View の一部分を実装しています。buildNormalContext で実装したすべてのコードは、ポートレット API の doView メソッドに移植しなくてはならない事に注意してください。実際のポートレットを、どのようにして 1 番目のパラメータとして、buildNormalContext メソッドに渡さなければならないのかに注意してください。
アクションクラス中に,do で始まるメソッドとして実装される実際のコードは,ポートレット API の processAction メソッドへ移植する必要があります. +
アクションクラス中に、do で始まるメソッドとして実装される実際のコードは、ポートレット API の processAction メソッドへ移植する必要があります。
-Turbine は,doInsert メソッドと,eventSubmit_ プレフィックスを持つ Velocity テンプレートのアクションと関連付けます. +Turbine は、doInsert メソッドと、eventSubmit_ プレフィックスを持つ Velocity テンプレートのアクションと関連付けます。
-ここにポートレット API (Jetspeed 2) での同等のものがあります. +ここにポートレット API (Jetspeed 2) での同等のものがあります。
-ポートレット API は,processAction メソッドに 2 つのパラメータを用意しています. +ポートレット API は、processAction メソッドに 2 つのパラメータを用意しています。
-Request parameters are accessed via RunData in Jetspeed-1:
- Jetspeed 1 では,リクエストパラメータは RunData 経由でアクセスします. + Jetspeed 1 では、リクエストパラメータは RunData 経由でアクセスします。
With the Portlet API, portlet request parameters are accessed via the ActionRequest:
- ポートレット API では,ポートレットのリクエストパラメータは,ActionRequest 経由でアクセスします. + ポートレット API では、ポートレットのリクエストパラメータは、ActionRequest 経由でアクセスします。
With the Portlet API, you can check the Portlet Mode or Window State:
- ポートレット API では,ポートレットモードとウィンドウの状態をチェック出来ます. + ポートレット API では、ポートレットモードとウィンドウの状態をチェック出来ます。
- 基本的なポートレット API には,Jetspeed 1 のように,アクションとメソッドをマッピングする方法がありません.もし,このような振る舞いをしたいのであれば,Spring MVC Portlet framework を使うことをおすすめします.ここで,フォームからのポートレットのリクエストパラメータを使って,特定のアクションにマップする実例を挙げます. + 基本的なポートレット API には、Jetspeed 1 のように、アクションとメソッドをマッピングする方法がありません。もし、このような振る舞いをしたいのであれば、Spring MVC Portlet framework を使うことをおすすめします。ここで、フォームからのポートレットのリクエストパラメータを使って、特定のアクションにマップする実例を挙げます。
- ポートレット API は,セッションへのポートレットの状態の保存を標準でサポートしています.ポートレットセッションは,Turbine/Jetspeed 1 の setTemp メソッド,もしくはサーブレット API に備わっているセッションのサポートと同様のものです.セッションは,現在のユーザのセッションと関係した持続的な状態です.ポートレット API によってサポートされる 2 種類のセッションの状態があります. + ポートレット API は、セッションへのポートレットの状態の保存を標準でサポートしています。ポートレットセッションは、Turbine/Jetspeed 1 の setTemp メソッド、もしくはサーブレット API に備わっているセッションのサポートと同様のものです。セッションは、現在のユーザのセッションと関係した持続的な状態です。ポートレット API によってサポートされる 2 種類のセッションの状態があります。
- Jetspeed 1 で Turbine RunData API を使って,どのようにセッション変数を取得し,設定するかを以下に示します.Jetspeed 1 でも Jetspeed 2 でも,セッションに格納するオブジェクトはシリアライズしなければいけないことに注意してください. + Jetspeed 1 で Turbine RunData API を使って、どのようにセッション変数を取得し、設定するかを以下に示します。Jetspeed 1 でも Jetspeed 2 でも、セッションに格納するオブジェクトはシリアライズしなければいけないことに注意してください。
In here is the equivalent in Jetspeed-2 using the Portlet API:
Jetspeed 2 で,ポートレット API を使って同等の事をする例を以下に示します.
+Jetspeed 2 で、ポートレット API を使って同等の事をする例を以下に示します。
- ポートレット API には,第 2 の状態保持メカニズムが準備されています.それはユーザ設定 (User Preferences) です.ユーザ設定は,ユーザ毎 / ポートレット毎に保存される情報欄です.Jetspeed 1 で同等のものは,ポートレットインスタンスデータです.これは,Jetspeed 1 ポートレットレジストリに,名前と値のペアでパラメータとして XML 要素として保存されます.Jetspeed 1 の XREG ファイルで,以下のようなものを見つけることが出来ます. + ポートレット API には、第 2 の状態保持メカニズムが準備されています。それはユーザ設定 (User Preferences) です。ユーザ設定は、ユーザ毎 / ポートレット毎に保存される情報欄です。Jetspeed 1 で同等のものは、ポートレットインスタンスデータです。これは、Jetspeed 1 ポートレットレジストリに、名前と値のペアでパラメータとして XML 要素として保存されます。Jetspeed 1 の XREG ファイルで、以下のようなものを見つけることが出来ます。
- ポートレット API では,portlet.xml 配備記述子内で,設定のデフォルト値を定義できます.ユーザ固有の値は,Jetspeed 設定データベースに保存されます.以下に,配備記述子に定義される設定のデフォルト値の例を示します. + ポートレット API では、portlet.xml 配備記述子内で、設定のデフォルト値を定義できます。ユーザ固有の値は、Jetspeed 設定データベースに保存されます。以下に、配備記述子に定義される設定のデフォルト値の例を示します。
- Jetspeed 1 は,設定値情報にアクセスするために,ポートレットごとに PortletInstance インターフェースが準備されています.Jetspeed 2 では,設定情報はユーザごと,インスタンスごとであるのに対して,インターフェースの PortletInstance 経由でアクセスされる Jetspeed 1 の設定情報は,インスタンス (ポートレットウィンドウ) ごとに特有なだけとなります.これらの値は,ポートレットウィンドウに関連付けられた PSML ファイルに保存されます.ユーザがページを配置して,そのページに対してデフォルトのメカニズムを使ったとき,この値はユーザ特有であることに注意してください. + Jetspeed 1 は、設定値情報にアクセスするために、ポートレットごとに PortletInstance インターフェースが準備されています。Jetspeed 2 では、設定情報はユーザごと、インスタンスごとであるのに対して、インターフェースの PortletInstance 経由でアクセスされる Jetspeed 1 の設定情報は、インスタンス (ポートレットウィンドウ) ごとに特有なだけとなります。これらの値は、ポートレットウィンドウに関連付けられた PSML ファイルに保存されます。ユーザがページを配置して、そのページに対してデフォルトのメカニズムを使ったとき、この値はユーザ特有であることに注意してください。
With Jetspeed-1, here we can retrieve PortletInstance data:
- Jetspeed 1 で,PortletInstance データを取得する方法を以下に示します. + Jetspeed 1 で、PortletInstance データを取得する方法を以下に示します。
- Jetspeed 2 のポートレット API では,ポートレット設定をもっと直接的な方法で使用できます. + Jetspeed 2 のポートレット API では、ポートレット設定をもっと直接的な方法で使用できます。
The Jetspeed-1 Registries hold the following information:
- Jetspeed 1 レジストリは以下のような情報を保持します. + Jetspeed 1 レジストリは以下のような情報を保持します。
This section will guide you through how to migrate each of these registries from Jetspeed-1 to Jetspeed-2
このセクションでは,これらの登録を Jetspeed 1 から Jetspeed 2 へどのように移行するかを案内します.
+このセクションでは、これらの登録を Jetspeed 1 から Jetspeed 2 へどのように移行するかを案内します。
Jetpeed-1 requires that all portlets are defined in an XML file known as an XREG file (XML Registry). Jetspeed-2 stores its portlet registry in the database. @@ -1285,7 +1285,7 @@
- Jetspeed 1 では,すべてのポートレットは XREG ファイル (XMLレジストリ) として知られている XML ファイルに定義する必要があります.Jetspeed 2 では,データベースにポートレットの登録を保管します.Jetspeed 1 では,XML レジストリは,ファイルシステム上の Jetspeed の webapp 以下の WEB-INF/conf 以下にあります.そこに 1 つ以上のポートレット登録のエントリがあります.ポートレットは全て,エレメントタイプ portlet-entry で定義されています. + Jetspeed 1 では、すべてのポートレットは XREG ファイル (XMLレジストリ) として知られている XML ファイルに定義する必要があります。Jetspeed 2 では、データベースにポートレットの登録を保管します。Jetspeed 1 では、XML レジストリは、ファイルシステム上の Jetspeed の webapp 以下の WEB-INF/conf 以下にあります。そこに 1 つ以上のポートレット登録のエントリがあります。ポートレットは全て、エレメントタイプ portlet-entry で定義されています。
Migrating your Jetspeed-1 portlet registries to Jetspeed-2 registries requires writing a new Portlet API standard portlet.xml definition file. We do not provide an XSLT transform to do this for you. @@ -1296,7 +1296,7 @@
- Jetspeed 1 のポートレットレジストリを Jetspeed 2 レジストリに移行するには,新しいポートレット標準の portlet.xml 定義ファイルを書く必要があります.我々は,この作業を行うための XSLT 変換は準備しません.portlet.xml は Java ポートレット標準で定義されているにも関わらず,Jetspeed では Jetspeed ポータル特有の仕様を定義する追加情報を書く事ができます.jetspeed-portlet.xml に Jetspeed 特有の保持できます.XREG 要素のうち,いくつかは portlet.xml にマッピングできます.その他は,以下の表にあるように jetspeed-portlet.xml にマッピングできます.以下の表は portlet-entry 要素のそれぞれの XML 属性を,ポートレット API の portlet.xml もしくは jetspeed-portlet.xml の同等のものに,どのようにマッピングするかについて述べています.この表で,XML 属性から,portlet.xml もしくは jetspeed-portlet.xml 内のどの XML 要素にマッピングするのかについて説明しています. + Jetspeed 1 のポートレットレジストリを Jetspeed 2 レジストリに移行するには、新しいポートレット標準の portlet.xml 定義ファイルを書く必要があります。我々は、この作業を行うための XSLT 変換は準備しません。portlet.xml は Java ポートレット標準で定義されているにも関わらず、Jetspeed では Jetspeed ポータル特有の仕様を定義する追加情報を書く事ができます。jetspeed-portlet.xml に Jetspeed 特有の保持できます。XREG 要素のうち、いくつかは portlet.xml にマッピングできます。その他は、以下の表にあるように jetspeed-portlet.xml にマッピングできます。以下の表は portlet-entry 要素のそれぞれの XML 属性を、ポートレット API の portlet.xml もしくは jetspeed-portlet.xml の同等のものに、どのようにマッピングするかについて述べています。この表で、XML 属性から、portlet.xml もしくは jetspeed-portlet.xml 内のどの XML 要素にマッピングするのかについて説明しています。
| name | portlet-name | -ポートレット名.この名前はポートレットアプリケーションごとにユニークである必要がありますが,システム全体ではユニークである必要はありません. | +ポートレット名。この名前はポートレットアプリケーションごとにユニークである必要がありますが、システム全体ではユニークである必要はありません。 |
| hidden | - | ポートレット API に同等の物はなく,適用できません. | +ポートレット API に同等の物はなく、適用できません。 |
| type | - | ポートレット API に同等の物はなく,適用できません. | +ポートレット API に同等の物はなく、適用できません。 |
| parent | - | ポートレット API に同等の物はなく,適用できません. | +ポートレット API に同等の物はなく、適用できません。 |
| application | - | ポートレット API に同等の物はなく,適用できません. | +ポートレット API に同等の物はなく、適用できません。 |
ポートレット XREG の変換を続け,portlet-entry 要素の XML 要素を変換する方法を見ていきましょう.以下の表は,それぞれの XML 要素をポートレット API の同等の物にマップする方法について述べています. +
ポートレット XREG の変換を続け、portlet-entry 要素の XML 要素を変換する方法を見ていきましょう。以下の表は、それぞれの XML 要素をポートレット API の同等の物にマップする方法について述べています。
- Jetspeed 1 は,セキュリティ制約の XML 定義言語をサポートしています.それは,Jetspeed 2 の XML でのセキュリティ制約の定義に非常に良く似ています.Jetspeed 1 は,全てのセキュリティの定義を,XREG ファイル (XML レジストリ) として知られる XML ファイル内に定義する必要があります.Jetspeed 2 は,セキュリティレジストリは XML ファイル,もしくはデータベースに保持します.Jetspeed 1 では,XML レジストリは Jetspeed webapp の WEB-INF/conf 以下のファイルシステム上にあります.1 つ以上のセキュリティレジストリのエントリが存在します.全てのセキュリティ制約は security-entry タイプの要素で定義します. + Jetspeed 1 は、セキュリティ制約の XML 定義言語をサポートしています。それは、Jetspeed 2 の XML でのセキュリティ制約の定義に非常に良く似ています。Jetspeed 1 は、全てのセキュリティの定義を、XREG ファイル (XML レジストリ) として知られる XML ファイル内に定義する必要があります。Jetspeed 2 は、セキュリティレジストリは XML ファイル、もしくはデータベースに保持します。Jetspeed 1 では、XML レジストリは Jetspeed webapp の WEB-INF/conf 以下のファイルシステム上にあります。1 つ以上のセキュリティレジストリのエントリが存在します。全てのセキュリティ制約は security-entry タイプの要素で定義します。
- あなたの Jetspeed 1 のセキュリティ制約レジストリを Jetspeed 2 レジストリに移行するには,新しい page.security XML 定義ファイルを書く必要があります.我々は移行のための XSLT ファイルは準備しません.以下の表は,security-entry 要素の XML 属性をポートレット API の portlet.xml,もしくは jetspeed-portlet.xml ファイルの同等のものにマッピングする方法を述べたものです.この表で XML 属性から portlet.xml もしくは jetspeed-portlet.xml の XML 要素へのマッピングをしていることに注意してください. + あなたの Jetspeed 1 のセキュリティ制約レジストリを Jetspeed 2 レジストリに移行するには、新しい page.security XML 定義ファイルを書く必要があります。我々は移行のための XSLT ファイルは準備しません。以下の表は、security-entry 要素の XML 属性をポートレット API の portlet.xml、もしくは jetspeed-portlet.xml ファイルの同等のものにマッピングする方法を述べたものです。この表で XML 属性から portlet.xml もしくは jetspeed-portlet.xml の XML 要素へのマッピングをしていることに注意してください。
- ウェブクライアントとメディアタイプの登録は,既に Jetspeed 2 に移植され,コアシステムの一部となっています.Jetspeed 2 は,これらの登録をデータベースに保存します.しかし,これらのテーブルは,以下の種データのセクションで述べるように,種データを使ってデータ登録できます. + ウェブクライアントとメディアタイプの登録は、既に Jetspeed 2 に移植され、コアシステムの一部となっています。Jetspeed 2 は、これらの登録をデータベースに保存します。しかし、これらのテーブルは、以下の種データのセクションで述べるように、種データを使ってデータ登録できます。
- 登録されたスキンは,直接は Jetspeed 2 には移行は出来ません.Jetspeed 2 は,より標準的な CSS ベースのスキンアプローチに移行しました.スキンで利用出来るテクニックには以下の 2 つがあり,それらを組み合わせることが可能です. + 登録されたスキンは、直接は Jetspeed 2 には移行は出来ません。Jetspeed 2 は、より標準的な CSS ベースのスキンアプローチに移行しました。スキンで利用出来るテクニックには以下の 2 つがあり、それらを組み合わせることが可能です。
- コントローラは Jetspeed 2 では廃止予定となりました.Java のコードに変換するための直接のマッピングはありません.代わりに,新しいレイアウトポートレットに書き換えるか,単純に,非常にフレキシブルな Jetspeed 付属の既存のレイアウトポートレットの一つを使うかのどちらかにする必要があります.Jetspeed のデフォルトのレイアウトポートレットは,複数列のグリッド,ポートレットのネスト,ポートレットカスタマイザを使った完全なカスタマイズをサポートします. + コントローラは Jetspeed 2 では廃止予定となりました。Java のコードに変換するための直接のマッピングはありません。代わりに、新しいレイアウトポートレットに書き換えるか、単純に、非常にフレキシブルな Jetspeed 付属の既存のレイアウトポートレットの一つを使うかのどちらかにする必要があります。Jetspeed のデフォルトのレイアウトポートレットは、複数列のグリッド、ポートレットのネスト、ポートレットカスタマイザを使った完全なカスタマイズをサポートします。
- コントロールは Jetspeed 2 で廃止予定となりました.Java のコードに変換するための直接のマッピングはありません.代わりに,新しいポートレットデコレータに書き換えるか,より簡単に,非常にフレキシブルな Jetspeed 付属の既存のポートレットデコレータの一つを使うかのどちらかにする必要があります. + コントロールは Jetspeed 2 で廃止予定となりました。Java のコードに変換するための直接のマッピングはありません。代わりに、新しいポートレットデコレータに書き換えるか、より簡単に、非常にフレキシブルな Jetspeed 付属の既存のポートレットデコレータの一つを使うかのどちらかにする必要があります。
@@ -1749,7 +1749,7 @@ can contain pages or more subfolders.- Jetspeed のサイトマップは,ポータルの全ページのナビゲーションスペースを定義します.バージョン 1 と 2 は,階層構造のファイルシステム風のサイトマップを持ちます.両方のバージョン共に,ルートフォルダの / を持ち,サブフォルダのツリーを持ちます.それぞれのサブフォルダは,ページやサブフォルダを持つことが出来ます. + Jetspeed のサイトマップは、ポータルの全ページのナビゲーションスペースを定義します。バージョン 1 と 2 は、階層構造のファイルシステム風のサイトマップを持ちます。両方のバージョン共に、ルートフォルダの / を持ち、サブフォルダのツリーを持ちます。それぞれのサブフォルダは、ページやサブフォルダを持つことが出来ます。
- Jetspeed 2 では,良く定義されるポータルリソースがありますが,Jetspeed 1 に同等のものがあるとは限りません. + Jetspeed 2 では、良く定義されるポータルリソースがありますが、Jetspeed 1 に同等のものがあるとは限りません。
| 2.x | 1.x | ファイル |
|---|---|---|
| ページ | ページ | A .psml ファイル. |
| フォルダ | -- | フォルダ毎に一つ存在する folder.metadata ファイル.Jetspeed 1 は該当なし. |
| リンク | -- | .link ファイル.Jetspeed 1 は該当なし. |
| メニュー | -- | メニューは folder.metadata ファイルで定義します.Jetspeed 1 は該当なし. |
| ページ | ページ | A .psml ファイル。 |
| フォルダ | -- | フォルダ毎に一つ存在する folder.metadata ファイル。Jetspeed 1 は該当なし。 |
| リンク | -- | .link ファイル。Jetspeed 1 は該当なし。 |
| メニュー | -- | メニューは folder.metadata ファイルで定義します。Jetspeed 1 は該当なし。 |
- 両方のバージョン共で,利用可能な予約済みのディレクトリがあります.そのネーミングは少し違います.Jetspeed 2 で,アンダースコア (_) で始まるディレクトリは,全てコントロール用のディレクトリとみなされ,プロファイラ (後述) が,ユーザ名やユーザのロール名のような実行時基準を基に,特別なディレクトリを配置するのに使われます.Jetspeed 1 には,プロファイリングルール内にハードコードされた,予約済み (コントロール) ディレクトリの固定名があります. + 両方のバージョン共で、利用可能な予約済みのディレクトリがあります。そのネーミングは少し違います。Jetspeed 2 で、アンダースコア (_) で始まるディレクトリは、全てコントロール用のディレクトリとみなされ、プロファイラ (後述) が、ユーザ名やユーザのロール名のような実行時基準を基に、特別なディレクトリを配置するのに使われます。Jetspeed 1 には、プロファイリングルール内にハードコードされた、予約済み (コントロール) ディレクトリの固定名があります。
| 1.x | 2.x | |
|---|---|---|
| user | _user | 全ユーザのフォルダを保持します. |
| role | _role | 全ロールのフォルダを保持します. |
| group | _group | 全グループのフォルダを保持します. |
| user | _user | 全ユーザのフォルダを保持します。 |
| role | _role | 全ロールのフォルダを保持します。 |
| group | _group | 全グループのフォルダを保持します。 |
| {mediatype} | _mediatype | mime/mediatype ごとのコンテンツ |
| {language} | _lanaguage | 言語ごとのコンテンツ |
| {country} | _country | カントリーコードごとのコンテンツ |
- プロファイリングのアルゴリズムは,リクエストに対して表示するページを正しく見つけます.J1 には,ページを見つけるための 2 つのハードコードされたアルゴリズムだけがあります. + プロファイリングのアルゴリズムは、リクエストに対して表示するページを正しく見つけます。J1 には、ページを見つけるための 2 つのハードコードされたアルゴリズムだけがあります。
- これらの設定は,システム全体に有効で,ポータル基盤ごとに変更しなければいけません.J1 は,メディアタイプ,言語,国の順の明確なコンテナ順を期待します. + これらの設定は、システム全体に有効で、ポータル基盤ごとに変更しなければいけません。J1 は、メディアタイプ、言語、国の順の明確なコンテナ順を期待します。
@@ -1846,7 +1846,7 @@
- J2 は,実行時のユーザ情報を取得し,プロファイリングルールを使うことで,ルール内に定義されたアルゴリズムに基ずくルールを見つけます.J2 のプロファイリングルールは,ユーザごとに定義されます.しかし,システム全体に共通なプロファイリングルールも持ちます. + J2 は、実行時のユーザ情報を取得し、プロファイリングルールを使うことで、ルール内に定義されたアルゴリズムに基ずくルールを見つけます。J2 のプロファイリングルールは、ユーザごとに定義されます。しかし、システム全体に共通なプロファイリングルールも持ちます。
- Jetspeed 1 では,全てのポートレットは XREG ファイル (XML レジストリ) である XML ファイル内で定義する必要がありました.Jetspeed 2 では,ポートレットのレジストリはデータベース内に保管されます.Jetspeed 1 では,PSML ファイルは,WEB-INF/psml 以下の Jetspeed の webapp フォルダ以下に保管出来ます.Jetspeed 2 では,PSML ファイルは,WEB-INF/pages もしくは WEB-INF/min-pages 以下の Jetspeed の webapp フォルダ以下に保管出来ます.Jetspeed 2 は,PSML ファイルをデータベース内に保管する機能もサポートしています. + Jetspeed 1 では、全てのポートレットは XREG ファイル (XML レジストリ) である XML ファイル内で定義する必要がありました。Jetspeed 2 では、ポートレットのレジストリはデータベース内に保管されます。Jetspeed 1 では、PSML ファイルは、WEB-INF/psml 以下の Jetspeed の webapp フォルダ以下に保管出来ます。Jetspeed 2 では、PSML ファイルは、WEB-INF/pages もしくは WEB-INF/min-pages 以下の Jetspeed の webapp フォルダ以下に保管出来ます。Jetspeed 2 は、PSML ファイルをデータベース内に保管する機能もサポートしています。
Migrating your Jetspeed-1 PSML files to Jetspeed-2 PSML files requires porting the files manually, or writing a database conversion utility or XSLT transform. We do not provide an XSLT transform to do this for you. @@ -1865,7 +1865,7 @@
- Jetspeed 1 の PSML ファイルを Jetspeed 2 の PSML ファイルに変換するには,ファイルを手で変換するか,データベースの変換ユーティリティを書くか,XSLT 変換を書く必要があります.我々は,変換を実行出来るような XSLT 変換は準備しません.以下の表は,それぞれの XML 要素や属性が Jetspeed 1 と Jetspeed 2 でどのようにマップされるのかを説明しています. + Jetspeed 1 の PSML ファイルを Jetspeed 2 の PSML ファイルに変換するには、ファイルを手で変換するか、データベースの変換ユーティリティを書くか、XSLT 変換を書く必要があります。我々は、変換を実行出来るような XSLT 変換は準備しません。以下の表は、それぞれの XML 要素や属性が Jetspeed 1 と Jetspeed 2 でどのようにマップされるのかを説明しています。
| portlets | page | -PSML ページ内の全てのコンテンツの中でもっとも外側のコンテナ. | +PSML ページ内の全てのコンテンツの中でもっとも外側のコンテナ。 |
| portlets @ id | page @ id | -このページに対するシステム全体でユニークな識別子. | +このページに対するシステム全体でユニークな識別子。 |
| metainfo/title | title | -ページのタイトル. | +ページのタイトル。 |
| security-ref | security-constraints/security-constraints-ref | -セキュリティ制約参照 (Jetspeed 1 では 0..1,Jetspeed 2 では 0..n) | +セキュリティ制約参照 (Jetspeed 1 では 0..1、Jetspeed 2 では 0..n) |
| control | defaults/portlet-decorator | -あなたのコントロールを J2 ポートレットデコレータに変換する必要があるか,もしくは少なくとも名前から Jetspeed 2 の既存のデコレータのマッピングを行う必要があります.もしくはグローバルなポートレットデコレータを使い,この任意の設定を無視する事も出来ます. | +あなたのコントロールを J2 ポートレットデコレータに変換する必要があるか、もしくは少なくとも名前から Jetspeed 2 の既存のデコレータのマッピングを行う必要があります。もしくはグローバルなポートレットデコレータを使い、この任意の設定を無視する事も出来ます。 |
| controller | defaults/layout-decorator | -あなたの Turbine コントローラ,画面ナビゲーションを J2 のレイアウト (ページ) デコレータに変換する必要があるか,もしくは少なくとも名前から Jetspeed 2 の既存のページデコレータへのマッピングを行う必要があります.グローバルなポートレットデコレータを使い,この任意の設定を無視することも可能です. | +あなたの Turbine コントローラ、画面ナビゲーションを J2 のレイアウト (ページ) デコレータに変換する必要があるか、もしくは少なくとも名前から Jetspeed 2 の既存のページデコレータへのマッピングを行う必要があります。グローバルなポートレットデコレータを使い、この任意の設定を無視することも可能です。 |
| portlets/portlets/... | page/fragment/..., type="layout" | -フラグメントもしくはポートレットのサブコンテナ.Jetspeed 2 では,フラグメントはコンテナかポートレット定義かの両方が可能です.layout タイプのフラグメントだけが,さらにフラグメントとコンテナを保持するコンテナとなることが出来ます. | +フラグメントもしくはポートレットのサブコンテナ。Jetspeed 2 では、フラグメントはコンテナかポートレット定義かの両方が可能です。layout タイプのフラグメントだけが、さらにフラグメントとコンテナを保持するコンテナとなることが出来ます。 |
| portlets/portlets/controller | page/fragment @ type=layout @ name={layout-name} | -コントローラは大体,name 属性によって名前の付いた,type = layout のフラグメントにマップされます.レイアウトはポートレットとして実装されており,PA::portlet-name として指定しなければいけません. + | コントローラは大体、name 属性によって名前の付いた、type = layout のフラグメントにマップされます。レイアウトはポートレットとして実装されており、PA::portlet-name として指定しなければいけません。 |
| portlets/entry | page/fragment/fragment @ type="portlet" | -ページ内のポートレットウィンドウ. | +ページ内のポートレットウィンドウ。 |
| entry @ id | fragment @ id | -システム全体でユニークなポートレットウィンドウの ID. | +システム全体でユニークなポートレットウィンドウの ID。 |
| entry @ parent | fragment @ name | -ポートレットレジストリ参照.Jetspeed 2 では,ポートレットの名前は PA::portlet-name として指定しなければいけません. | +ポートレットレジストリ参照。Jetspeed 2 では、ポートレットの名前は PA::portlet-name として指定しなければいけません。 |
| entry/layout/property @ name="column"@value={column} | fragment/property @ name="column"@value={column} | -列の位置を含むプロパティ. | +列の位置を含むプロパティ。 |
| entry/layout/property @ name="row"@value={row} | fragment/property @ name="row"@value={row} | -行の位置を含むプロパティ. | +行の位置を含むプロパティ。 |
- Jetspeed 1 と Jetspeed 2 の間には,ナビゲーションの外観やメニューに大きな違いがあります.Jetspeed 1 は,メニューナビゲーションを タブ 間のナビゲーションに制限しています.タブは PSML ページ内で定義されます.タブは,portlets 要素で定義される,PSML ページの単なる子のコンテナです.Jetspeed 1 が (訳注:ここは Jetspeed 2 の誤りであると思われます.) 他のページへのナビゲーションをサポートするのに対して,タブメニューは外部リンクとして動作する特定のポートレットを書かない限りは,それを直接はサポートしません. + Jetspeed 1 と Jetspeed 2 の間には、ナビゲーションの外観やメニューに大きな違いがあります。Jetspeed 1 は、メニューナビゲーションを タブ 間のナビゲーションに制限しています。タブは PSML ページ内で定義されます。タブは、portlets 要素で定義される、PSML ページの単なる子のコンテナです。Jetspeed 1 が (訳注:ここは Jetspeed 2 の誤りであると思われます。) 他のページへのナビゲーションをサポートするのに対して、タブメニューは外部リンクとして動作する特定のポートレットを書かない限りは、それを直接はサポートしません。
Jetspeed-2 menu navigations map directly onto the Portal Site. Thus menu tabs represent portal resources. @@ -2036,7 +2036,7 @@
- Jetspeed 2 のメニューナビゲーションは,ポータルサイト上に直接マッピングされます.それゆえ,メニュータブはポータルリソースを表します.Jetspeed 2 のメニューは,フォルダやページやリンクを指し示すことができます.このことは,より自然にユーザが全ポータルサイト内を移動することが可能になります. + Jetspeed 2 のメニューナビゲーションは、ポータルサイト上に直接マッピングされます。それゆえ、メニュータブはポータルリソースを表します。Jetspeed 2 のメニューは、フォルダやページやリンクを指し示すことができます。このことは、より自然にユーザが全ポータルサイト内を移動することが可能になります。
When migrating PSML files from Jetspeed-1 to Jetspeed-2, depending on whether you use advanced Jetspeed-1 controllers such as @@ -2045,7 +2045,7 @@
- Jetspeed 1 から Jetspeed 2 へ PSML を移行する場合,カードやタブコントローラと言った Jetspeed 1 の進んだ機能を使っているかどうかで,Jetspeed 2 への移行が出来る,出来ないが分かるでしょう.移行ツールがないことを考慮して,以下の二つのオプションを当面残してあります. + Jetspeed 1 から Jetspeed 2 へ PSML を移行する場合、カードやタブコントローラと言った Jetspeed 1 の進んだ機能を使っているかどうかで、Jetspeed 2 への移行が出来る、出来ないが分かるでしょう。移行ツールがないことを考慮して、以下の二つのオプションを当面残してあります。
- Jetspeed 2 には,あなたのポータルに初期「種」データを注入するための XML API が定義されています.あなたの種データを XML API 経由で注入することは,データベース特有のデータを注入したり,難しい SQL スクリプトを読む代わりとなります.加えて,XML API はデータをインポート,エクスポートしたり,あなたの Jetspeed 2 データベースをバックアップしたりリストアしたりするのにも使えます. + Jetspeed 2 には、あなたのポータルに初期「種」データを注入するための XML API が定義されています。あなたの種データを XML API 経由で注入することは、データベース特有のデータを注入したり、難しい SQL スクリプトを読む代わりとなります。加えて、XML API はデータをインポート、エクスポートしたり、あなたの Jetspeed 2 データベースをバックアップしたりリストアしたりするのにも使えます。
@@ -2077,13 +2077,13 @@
- XML API は,あなたの Jetspeed ポータルのメンテナンスサイクル全体での移行パスも提供します.XML API は,最初にバージョン 2.1 で実装されました.バージョン 2.1 から 2.2 へデータを移行するために,XML API を両バージョンで使って (エクスポートとインポートを行うことにより) 移行を行うことが可能です. + XML API は、あなたの Jetspeed ポータルのメンテナンスサイクル全体での移行パスも提供します。XML API は、最初にバージョン 2.1 で実装されました。バージョン 2.1 から 2.2 へデータを移行するために、XML API を両バージョンで使って (エクスポートとインポートを行うことにより) 移行を行うことが可能です。
As of 2.1, the Jetspeed API supports the following elements:
- 2.1 時点で,Jetspeed API は,以下の要素をサポートします. + 2.1 時点で、Jetspeed API は、以下の要素をサポートします。
| MimeTypes | -ポータルがサポートする text/html や text/xhtml などのような Mime Types. | +ポータルがサポートする text/html や text/xhtml などのような Mime Types。 |
| メディアタイプ | -ポータルがサポートする html, xml, wml 等のようなメディアタイプ. | +ポータルがサポートする html, xml, wml 等のようなメディアタイプ。 |
| 機能 | -ポータルにアクセスするウェブクライアントに共通の機能. | +ポータルにアクセスするウェブクライアントに共通の機能。 |
| クライアント | -ポータルがサポートするウェブクライアント. | +ポータルがサポートするウェブクライアント。 |
| ロール | -ポータルの初期設定で定義される全てのロール. | +ポータルの初期設定で定義される全てのロール。 |
| グループ | -ポータルの初期設定で定義される全てのグループ. | +ポータルの初期設定で定義される全てのグループ。 |
| ユーザ | -ポータルの初期設定で定義される全てのユーザ.最少で admin と guest(anon) ユーザ. | +ポータルの初期設定で定義される全てのユーザ。最少で admin と guest(anon) ユーザ。 |
| パーミッション | -ポータルに対する初期定義される J2EE セキュリティポリシー.パーミッションはデフォルトではオフになっていることに注意. | +ポータルに対する初期定義される J2EE セキュリティポリシー。パーミッションはデフォルトではオフになっていることに注意。 |
| プロファイリングルール | -ポータルに初期で定義されるすべてのプロファイリングルール.例えば role fallback, user-role-fallback, j1-emulation, default-j2, subsites などのような. | +ポータルに初期で定義されるすべてのプロファイリングルール。例えば role fallback, user-role-fallback, j1-emulation, default-j2, subsites などのような。 |
| @@ -2182,8 +2182,14 @@ |
Reference for Jetspeed-2 XML schemas:
++ Jetspeed 2 の XML スキーマのリファレンスです。 +
+| Jetspeed-2 PSML | @@ -2210,10 +2216,42 @@http://portals.apache.org/jetspeed-2/2.1/schemas/jetspeed-portlet.xsd |
| Jetspeed-2 PSML | +http://portals.apache.org/jetspeed-2/2.1/schemas/psml.xsd | +
| Jetspeed-2 Folder Metadata | +http://portals.apache.org/jetspeed-2/2.1/schemas/folder-metadata.xsd | +
| Jetspeed-2 Seed Data | +http://portals.apache.org/jetspeed-2/2.1/schemas/j2-seed.xsd | +
| Jetspeed-2 Security Constraints | +http://portals.apache.org/jetspeed-2/2.1/schemas/page-security.xsd | +
| Jetspeed-2 Links | +http://portals.apache.org/jetspeed-2/2.1/schemas/link.xsd | +
| Jetspeed-2 Extended Portlet Descriptor | +http://portals.apache.org/jetspeed-2/2.1/schemas/jetspeed-portlet.xsd | +
The best place to get started is to create your own custom portal. This process is defined online at Apache. The Jetspeed Tutorial will take you through the initial steps of setting up your own (custom) Jetspeed portal, including setting up XML seed data, PSML, custom decorations and portlet applications.
++ はじめに、あなた自身のカスタムポータルを作成すると良いでしょう。このプロセスは、Apache でオンライン上で定義されます。Jetspeed チュートリアル は、あなた自身の (カスタム) Jetspeed ポータルの第一歩にあなたを導くでしょう。それには、XML 種データ、PSML、カスタムデコレーション、ポートレットアプリケーションの設定も含まれます。 +