6

クライアントから、ポートレット 1.0 仕様と Websphere Portal Server 6.0 を使用するように依頼されたプロジェクトがあります。私はこれまでポートレットを扱ったことはありませんでしたが、ポートレットについて聞いたことがあるのは、常に悪い批判でした。それらを使用するという明白な理由以外に、どのような理由がありますか? 理由がない場合、それらを回避するためにどのような引数を使用できますか?

4

3 に答える 3

9

Javaポートレットの開発にいくつかの仕事（私の現在のものを含む）を持っている人として、私はそれらを使用しないと思います。

ここに問題があります：

選択しているポータルの既存の機能を使用したいだけの場合は、ポータルを使用してください。

ポートレットの使用が、異種の情報をすばやく確認できる、小さくて軽量な、主に読み取り専用のWebベースのダッシュボードを構築することだけである場合は、それで問題ありません。

しかし、あなた（または組織図の上位にいる人）がポートレットをページに多数の異なるWebアプリを配置し、すべてを「正常に機能させる」方法と考えている場合、あなたは傷ついた世界に向かっています。 。ポートレットは、高度に制限された自己完結型の機能の島であり、ページ上の小さな正方形のWebアプリではありません。

私のポートレットベースのジョブはすべてこの間違いを犯しており、トンネルの終わりには光がありません。ポートレット開発者として、これは通常のWebアプリで行うことに慣れていることの小さなリストであり、ポートレットでは確実に行うことはできません。

  • 他のページへのURLを生成します。これを行うには、ベンダー固有の方法が必要です。これは、Portlet APIでは、URLを生成したポートレットをターゲットとするURLしか生成できないためです。
  • HTTPヘッダーを読み取って設定するか、HTTP応答コードを設定します（ポートレットが配置されるページを所有していないため、リダイレクトやHTTPキャッシングは行われません）
  • 生成されたページのすべての識別子に名前空間を付ける必要があります。これは、HTMLID属性とJavaScript関数名を意味します。一意性を確保するために名前空間を実行時に決定する必要があるため、これらのJavascript関数を、ポートレットの応答本文に存在する必要がある別のブラウザーキャッシュ可能ファイルに常駐させることはできません。

ポートレットは、90年代半ばから後半（AJAX以前）のWeb開発の状態に合わせて設計されたように感じます。ただし、要求/応答サイクルを完全に制御できることを前提とした今日のWeb開発環境（AJAX、単一ページのリッチWebアプリなど）には適していません。

于 2012-08-10T21:14:37.210 に答える
5

私がポートレットで抱えている問題は、EJB と同じ問題を思い起こさせます。

  • ポートレットでは、特別なサーバーでのみホストおよび実行できる特別なコードを記述する必要があります。
  • すべてのポートレット サーバー ベンダーはカスタムの拡張機能/構成/追加機能を備えているため、サーバー ベンダーを変更することは簡単ではありません。
  • ポートレットは、使用したい人の 90% が必要としない機能をカバーするには複雑すぎるようです。

Hibernate to portlet の EJB としてGoogle Gadgetsのようなものをお勧めします -

  • Javascript フレームワーク - サーバー側の部分は、任意のサーバーでホストされる任意の言語で記述できます。
  • より使いやすく
  • 多くのポータル サーバーがサポートしており、それほど複雑ではなく、ベンダーが実装 (および拡張) する仕様ではないため、ベンダー間での移植性が高くなります。
于 2009-07-18T11:15:35.350 に答える
3

ポートレットは、柔軟性が約束されているため、ビジネスにとって魅力的です。顧客はページ上のコンポーネントを微調整および再配置できます。主にコンテンツを提供している場合、ポートレットはそれを行う効果的な手段です。

私の意見では、ポータルは、純粋なコンテンツ、機能的に独立したポートレット、または単純に関連したポートレットを集約するのに適しています (たとえば、あるポートレットのリストからアイテムを選択すると、別のポートレットを更新して詳細を表示します)。ポートレットは、複数のページ/場所に非常に簡単に構成できるため、再利用も可能です。

問題が発生する可能性があるのは、複数のステップと相互作用を伴う複雑なビジネス機能を分解しようとするときです。このシナリオでは、ポートレットの粒度を決定することは、科学というよりは芸術であり、ポートレット間の相互作用を慎重に検討する必要があります。

また、UI の柔軟性も考慮する必要があります。ポートレット ビルディング ブロックのセットがある場合、ビジネスはそれらのブロックを再配置できることを明確にする必要がありますが、ポートレット間でアイテムを移動するには書き直しが必要です。たとえば、送信ボタンをあるポートレットからページの下部に移動するのは簡単ではありません。

つまり、要約すると、何をしようとしているのか、およびコンポーネントをどれだけ再利用すると予想されるかによって決まると思います。IT 部門がサーブレットに組み込む技術コンポーネントを作成して再利用を管理する方が簡単な場合もあれば、ポートレットがビジネスに最適な場合もあります。正解はありません。何を達成しようとしているのかを慎重に検討する必要があります。ポートレットを選択する場合は、ライフサイクル全体を受け入れる必要があり、それらを回避したいという誘惑を避ける必要があります。ポートレットのすべてのオーバーヘッドと制限により、利点を理解することができずに、すぐに悪い場所にいることに気付く可能性があります。

于 2009-07-18T10:23:41.633 に答える