Liferayポータルに統合するために、アプリケーションをポートレットとして開発することを検討しています。 Springフレームワークを使用して通常のWebアプリケーションを開発するのではなく、そのようなアプリケーションを開発する際に重大な欠点や制限がありますか？Liferayのポートレットを開発する際の制限/不利益
Liferayは、すべてのコンテンツがポートレットとして追加されることを要求しているようです。私が思うもう一つの選択肢は、アプリケーションの一部だけでLiferayを使用し、通常のWebアプリケーションとして開発された他の自己開発コンテンツに外部リンクを追加することです。しかし、Liferayと他のWebアプリケーションとの間で、複数のユーザー認証メカニズムと何らかのクロスサイト認証が必要になります。
どちらが最善の方法ですか？
（免責事項：私はLiferayの開発者の一人です）
私は両方のオプションは、あなたのニーズに応じて、良いと思います。スタンドアロンWebアプリケーションの開発経験はありますが、ポートレットの開発経験がない場合は、前者を選択するとより早く開始できます。欠点は、独自のユーザーと権限システムを実装する必要があり、Liferayが提供するポータルサービスを活用できないことです。この代替方法を使用する場合は、通常のWARファイルをLiferayにデプロイできることに注意してください.irameを使用してアプリを表示する単純なポートレットが自動的に作成されます。これにより、Liferayのページにポートレットと一緒にスタンドアロンのアプリケーションを置くことができます。
Liferay用のポートレットを開発すると、提供するポータルサービスを利用し始めると、その成果が上がり始めます。ポートレットを開発することから始めて、自分のユーザーシステムを開発することを忘れて、Liferayが提供するもの（これは非常に強力です）を使用してください。パーミッション、コメント、タグ付け、分類、データスコープなどの他のサービスを使用して、短時間で完全なアプリケーションを開発することもできます。欠点は、これを初めて行うときにはいくつかの新しいことを学ばなければならないが、2度目の方がはるかに速くなるということです。
私は役立つことを願っています。
私はずっとLiferayのようなポータルを共有インフラストラクチャと同じように考えるべきだと考えました。これらは、アプリケーション、共有サービス（認証など）、および標準的な配置方法にアクセスする共通の方法を提供しますが、パフォーマンスを犠牲にしています。
このアプリケーション以外のアプリケーションをポータルにデプロイする場合は、2回目にこれらの共有サービスを開発する必要がないため、時間とコストの節約につながるため、おそらく適切です。それ以降のアプリケーションは、このアプリケーションと同様の外観で動作します。
しかし、これが唯一のアプリケーションであれば、ポータルのオーバーヘッドはそれほど価値がないので、通常のWebアプリケーションを使う方がよいです。
LiferayはCMS機能を持ち、Alfrescoなどの外部CMSプラットフォームと統合することができます。
私は内部アプリケーションのためにLiferayを約2年間使用してきました。私たちは最初のリリースの前に開発サイクルを通して何度も同じ議論をしました。 Liferayと数回戦わなければなりませんでした。なぜなら、時にはポートレット環境のために、時にはLiferayのために、知識が不足していることがあるからです。
ポータルから取得できる複数のアプリケーションのレイアウトオプションが必要な場合は、確実にLiferayを使用する必要があります。単一のアプリケーションを作成しているのであれば、おそらくLiferayを使用しないでしょう。私はいくつかのLiferayといくつかのハイブリッドがはるかに最悪の選択だと思う。
Liferayを最大限に活用しているわけではありませんが、これが初めてのLiferayアプリであれば、学習曲線のせいではないでしょう。もともとは、アプリケーションのさまざまな側面でさまざまなポートレットを用意したいと考えていましたが、開発中のポートレット間の良好な通信メカニズムがないため（JSR-286以前）、単一のアプリケーションを作成しました。私たちがそのボートで終わったので、私たちが本当に使っているのはユーザー管理機能なので、私たちはLiferayなしで行ってもらいたいと思います。
私たちはJSFとfacelets（新しい技術の両方を使用しているので、痛みは自己寛解している可能性があります）を使用していますが、私たちはそれをうまく使いこなしていますが、ポートレットで正しく機能するようにする。通常のWebアプリケーション環境では起こらなかったことがあります。多くのフレームワークでは、ポートレットのサポートは後で考慮されるようです。これは明らかにLiferay特有のものではなく、ポートレット環境内で作業することの単なる副産物です。
Spring MVC、Struts、Faces、Wicketを使用しているWebアプリケーションでは、すべてのことをより詳細に制御できますが、さらに多くのものを実装する必要があります。
ポートレットでは、JSR-168および/またはJSR-286の条件に従うことになります。ポータルコンテナはユーザー認証のようないくつかの機能を提供しますが、ユーザー認証用のポータル全体が非常に重すぎます。私はポータルのパワーが、単一のアプリケーションを提示するのではなく、複数のアプリケーションのビューをカスタマイズできるようにしているのを見ています。
ポートレットに関連する仕様を確認し、ニーズに合っているかどうかを確認する必要があります。
http://developers.sun.com/portalserver/reference/techart/jsr168/
のLiferayと一般的なポートレットは、アプリケーションの非常に特定のクラスに最適です。 IT部門で働いていて、複数の部門のために、または複数の部門でアプリケーションを組み合わせる必要がある場合は、ポートレットを使用することができます。理論的には、異なるベンダーからのポートレットをドロップすることができ、それらはすべて同じ環境内で調和して生きていきます。しかし
次
1）のいずれかが一つのチーム 2）によって完全に作成されたアプリケーションを構築する場合は、サブセットではありません要件 3）の要件を持っているため、単一のソースを持っていますポートレット・コンテナで使用可能な機能のうちの1つ。 4）グラフィックデザイナーは、ポータルスタイルのアプリケーションの範囲内で暮らすことを望んでいません。
次に、Springのようなものを貼り付けることは、道のりだろう。
Springとその多くのサブプロジェクトは、ポートレットによって提供される多くの共有サービスとインフラストラクチャを提供しますが、オープンで柔軟な方法で提供されます。あなたはあなたが望むものを選んで選ぶことができます。
ポートレットは、認証と認可、ナビゲーション、およびレイアウトの点で、多くの設計上の決定を行います。あなたのアプリケーションのために持っている計画がそれらの決定の外にある場合は、あなたが望むことをやろうとする回避策を作るのに多くの時間を費やします。
Liferayは非常に強力なシステムです。準備ができている多くのサービスとアプリケーションがありますが、最大の欠点はドキュメントがないことです。コードを見ているだけのことはすべて知ることは不可能だと私の意見では、専門家にはLiferayに行かないでください。
+1のドキュメントが不足しているため、Liferayはドキュメンテーションのためにひどいです。 – Jakub
Man、このソリューションをチェックしてください。Netbeans IDE + PoralPack3.0プラグイン+ Liferay 5.2バンドル。ここでのPortal Packは、エンティティまたはデータベース構造を定義できるservice.xmlファイル用の素敵なGUIエディタを提供し、同じGUIからポートレット内で使用できるサービスコードを生成することができます。詳細情報については
は下記のリンクをチェックしてください。 http://www.liferay.com/web/satyaranjan/blog/-/blogs/portal-pack-:-write-database-portlet-using-service-builder-plug-in
Liferayのジュースは - 1.純粋なビジネスロジックに焦点を当てて、すべての低レベルのものをLRに残すことができます。 2.すべてのLR機能はカスタマイズ可能で、完全に互換性のあるポートレットを独自に作成することができます。 –
を誰もが、トローリング/炎としてこれを服用しないでください。これは、私がLiferayコミュニティーが取り組むべきだと感じるものであり、Liferayを使用することを考えている人は誰も知っているはずです。
短所：ドキュメントはありません。例えば、Hibernateのドキュメンテーションのような遠隔的なものはありません。空のjavadock（コードにコメントはありません）、フォーラムや古いバージョン（役に立たない）の書籍に回答したものがあります。
この回答は1歳でしたが、私は幾分同意しましたが、文書化の努力に従えば、この間に多くの変化がありました。 https://www.liferay.com/de/documentationの文書が改訂され、wikiとforumがかなり活発になっています。それは複雑なシステムです、ドキュメントは常に改善することができますが、それはまた多くを行っています。問題は、開発やその他の詳細に慣れていれば、冬眠よりも多くのことを理解する必要があることです。はい、javadocはありませんが、コードは厳密なコーディング標準に従っているので、これに慣れていればそれを読んで理解する方法があります。 –
コードが厳密なコーディング標準に準拠していても、いずれのシステムでもJavadocが完全に不足していると、管理やアーキテクチャが貧弱であるか、コードベースがまったく変更または理解されないように設計されています。 – jevon
本当に「共有」サービスであれば、とにかくもう一度書く必要はありません。いくつかの統合作業がありますが、2回目の実装よりもはるかに小さいはずです。 – digitaljoel