ポータルサーバーという名前に縛られてしまうと、ポータル構築の案件だけにしか、適用できないような印象を与えてしまう気がするけど、実際にはポータル構築案件でなくても、ウェブアプリ開発でユーザー認証・管理が必要な案件に対して、適用すれば、ポータルサーバーを適用するメリット(ユーザー管理作り必要はなく、ポータル機能をそのまま利用して、開発で楽をできる)はあると思う。多くの場合、ウェブアプリでユーザー管理は必要になると思うので、適用範囲は広い(はず?)です。そんな感じで、ポータルサーバーという名前にとらわれず、ユーザー管理とか作るので楽をしたいなら、PALポータルとか利用していただければ、と思う今日この頃であります 🙂
投稿者: shinsuke
デコレータ内でポートレットを直接呼び出す
ポートレットをレイアウトポートレットで管理されているところ以外に表示する方法について。tigrisレイアウトデコレータでやっているけど、レイアウトデコレータで(たとえば、header.vm などに)
$jetspeed.renderPortletEntity("theClock","j2-admin::DateTimePortlet")
というように記述すると、ポートレットを貼り付けることができる。ただし、一時的なフラグメントを生成して、表示するためか、フォームの送信などのアクションを処理することはできない。つまり、単純にポートレットを描画だけしたいときなどに利用可能。
JSR 286 Portlet Specification 2.0 (PLT.11 – PLT.11.1.1.13)
続き・・・
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スクリプトかもしれないから、ポートレットがクライアントで単純にクエリーパラメータを追加するなと言っている。
今日はここまで・・・(進んでない)。