カテゴリー: Portlet

続き・・・

PLT.11 Portlet Requests

リクエストオブジェクトは、processAction、processEvent、serveResource、renderメソッドに渡される。

PLT.11.1 PortletRequest Interface

PortletRequest は、すべてのリクエストインタフェースの共通機能を定義する。

PLT.11.1.1 Request Parameters

以下のメソッドでアクセスする。

• getParameter
• getParameterNames
• getParameterValues
• getParameterMap

特に目新しいことはないと思う。

PLT.11.1.1.1 Form and Query Parameters

フォームのデータがPOSTで送信される場合、コンテンツタイプがapplication/x-www-form-urlencodedなら、そのデータはポートレットのリクエストパラメータに投入される。リクエストパラメータに投入されてしまったら、リクエストオブジェクトの入力ストリームではアクセスはできない。POSTでのデータがパラメータセットに含まれないときには、ActionRequest/ResourceRequestの入力ストリームでアクセスできる。

GETで送信される場合、フォームのデータは送信されたPortlet URLに付け足され、ポートレットのリクエストパラメータとしてアクセスできる。(うーん、何か表現が曖昧な気が・・・)

いくつかのポータル実装では、内部状態をURLクエリー文字列の一部としてエンコードしてないかもしれない。なので、GETによるフォームをサポートしてないかもしれないので注意されたし。(JSR 168 のときも J2 ではオプションを指定しないと、GETが取れない気がする)

ポートレットURLが必要とするURLを生成するECMAスクリプトかもしれないから、ポートレットがクライアントで単純にクエリーパラメータを追加するなと言っている。

今日はここまで・・・(進んでない)。

続き・・・

PLT.9.4 Custom Window States

カスタムウィンドウ状態の例は以下のようにdescription、window-stateになった。

<portlet-app>
...
<custom-window-state>
<description>Occupies 50% of the portal page</description>
<window-state>half_page</window-state>
</custom-window-state>
...
</portlet-app>

PLT.9.5 Defining Window State Support

ポータルは事前定義のNORMAL, MAXIMIZED, MINIMIZED をサポートする。宣言されていないカスタムウィンドウ状態は呼び出さない。配備記述子では以下のように定義される。

<supports>
<mime-type>text/html</mime-type>
<portlet-mode>edit</portlet-mode>
<portlet-mode>help</portlet-mode>
<window-state>half-page</window-state>
...
</supports>
<supports>
<mime-type>text/vnd.wap.wml</mime-type>
<portlet-mode>help</portlet-mode>
...
</supports>

以上の例では、HTMLについては、事前定義のウィンドウ状態に加えて、HALF-PAGEウィンドウ状態をサポートすることになる。WMLは、事前定義のウィンドウ状態のみのサポートになる。

ポータルがサポートしていないウィンドウ状態については、無視か、マッピングしない。

PLT.10 Portlet Context

PortletContextはポートレットの実行でのポートレットアプリケーションのポートレットの表示を定義している。PortletContextを利用すると、ログ、リソースや実行時のオプションにアクセスできたり、他のポートレットやサーブレットでアクセスできる属性を入れることができる。実行時のオプションというのが新しい点だろうか。

PLT.10.4 Portlet Container Runtime Options

ポートレットは、ポートレットアプリケーションレベルまたはポートレットレベルで追加の実行時オプションを定義できる。ポートレットアプリケーションレベルのオプションはすべてのポートレットに適用され、ポートレットレベルのオプションは固有のポートレットに適用され、ポートレットアプリケーションレベルのオプションを上書きする。

実行しているポートレットのPortletContextのgetContainerRuntimeOptionsメソッドを通して、コンテナ実行時オプションを取得する。このメソッドは、Mapを返してくる。portlet.xmlに設定されていなければ、空のMapになる。

PLT.10.4.1 Runtime Option javax.portlet.escapeXml

1.0のときは、URLのXMLエスケープについては、定義されていなかった。なので、XMLエスケープされているURLを想定しなくてもよかった。2.0では、それらを動かすには、javax.portlet.escapeXml実行時オプションが必要。定義は以下のような感じ。

<portlet>
…
<container-runtime-option>
　<name>javax.portlet.escapeXml</name>
　　<value>false</value>
</container-runtime-option>
</portlet>

PLT.10.4.2 Runtime Option javax.portlet.renderHeaders

renderフェーズでヘッダーを書く必要があるポートレットは、この実行時オプションを利用する。デフォルトは、false。詳細はPLT11.1.1.3.3。例、

<portlet>
…
<container-runtime-option>
<name>javax.portlet.renderHeaders</name>
<value>true</value>
</container-runtime-option>
</portlet>

PLT.10.4.3 Runtime Option javax.portlet.includedPortletSessionScope

JSP内のセッション変数はアプリケーションスコープのポートレットセッションにマップされるけど、それが調整可能になるみたい。そのためにこの実行時オプションを利用する。

<portlet>
…
<container-runtime-option>
<name>javax.portlet.includedJSPPortletSessionScope</name>
<value>PORTLET_SCOPE</value>
</container-runtime-option>
</portlet>

ポートレット開発者は、すべてのポートレットコンテナが以上の機能を提供できるというわけではないことに注意されたし。これに依存すると、実行時にポートレットコンテナで制限となるかも。

今日はここまで・・・