5

Java ベースの CMS を検討しています (はい、Java です。スクリプト言語から離れようとしています)。

Magnolia と Jahia のコミュニティ エディションを実際に使用した経験のある人はいますか?モジュールを作成しやすいのはどちらですか?全体的な経験は?

  • コンテンツ編集者向け
  • 開発者 (モジュールを作成する) 向け
  • 変更要求を処理するのがいかに簡単か (これまたはそれをページ foo/bar に追加できますか)

rvt

4

7 に答える 7

3

免責事項: 私は Jahia CTO です。この回答が StackOverflow 標準で受け入れられることを願っています。それ以外の場合は、今すぐ許可してください。改善します。私は最初、答えに対する直接のコメントとして答えたかったのですが、それは不可能のようです。

GKrost によってリストされた短所に対処したいと思います。そのうちのいくつかはもはや正確ではありません (これが書かれているため、Jahia の少なくとも 1 つのメジャー バージョンがリリースされているため)、他のものは正しくありません。

ジャヒアの短所：

JCR は、特に mysql を使用する場合、大規模な (10000 以上のページ、> 50000 のコンテンツ要素) サイトのボトルネックのようです。バンドルされている Java-In-Memory-DB ははるかに高速です。

実際には、JCR は単なる仕様であるため、これとは何の関係もありません。基礎となる JCR 実装について話しているのですが、この場合は Jackrabbit です。HSQLDB ( http://hsqldb.org )などのインメモリ データベースのパフォーマンスに勝るものがないことは事実ですが、エンタープライズ向けに設計されていないため、このようなデータベースを運用環境で使用することもお勧めしません。クラスタリング環境などの展開。推奨されないもう 1 つの理由は、CMS と同じ JVM で貴重なヒープ領域を使い果たしてしまうことです。これは、データが大きくなるにつれて問題になります。

サイズ制限に関しては、10000 ページ以上は確かに非常に大きなサイトであり、ほとんどのインストールがこのサイズに達することはめったにありませんが、データを分散する方法は複数あります。10000+ は、主に Jahia 6.5 以前のバージョンの CMS に適用される制限でもありますが、現在はそれを超える可能性があります。50000 個のコンテンツ要素に関しては、この制限は正しくありません。より多くのコンテンツを含むインストールを展開しましたが、ボトルネックが導入されないようにするためにコンテンツ設計構造が重要であることは事実ですが、これはそこにあるすべての CMS に当てはまり、シャーディングが適切に行われなければならない ElasticSearch などのテクノロジーにも当てはまります。パフォーマンスの問題を回避することができました。

Jahias Lucene のバージョンが古い

Jahia のデフォルトの Lucene バージョンは、実際には、基盤となる Jackrabbit JCR 実装によって使用されるものです。OSGi モジュールの開発を可能にする Jahia 7 の時点で、JCR バックエンドが必要とするものに干渉することなく、別のバージョンの Lucene または ElasticSearch を独自のバンドル内に埋め込むことができます。私の知る限り、これは Magnolia などの非 OSGi CMS では不可能です (ただし、OSGi ベースの Web フレームワークである Apache Sling を使用する Adob​​e では可能です)。

独自のアプリ/モジュールを開発する場合は、JSP を使用する必要があり、JSF を使用することはできません (Jahia は Spring Webflow を統合する計画がありますが、それがいつなのかはわかりません ...)

実際には、JSP/Groovy/Velocity など、Java Scripting API でサポートされている言語を使用できます。Spring Webflow は現在利用可能な Jahia 7 に統合されており、すべての管理モジュールは Spring WebFlow ( http://www.jahiaone.com/home/program/session/MVC-in-Jahia7-Using-SpringWebFlow )を使用して完全に開発されています。 . JSP に関しては、独自のビューのほとんどに Java コードが含まれていないため、スクリプト作成を必要とせずにビューを簡単に開発できるようにする強力なタグ ライブラリを提供しています。JSF 統合も可能ですが、すぐに使用できるものではなく、JSF を既存のサーブレット コントローラーに統合する方法をよく理解している必要があります。

反応時間に関しては、サポートが遅い

これは単に真実ではありません。私たちの SLA は非常に明確であり、常にそれを尊重してきました: http://www.jahia.com/services/technical-assistance . ただし、合計サポート時間は、顧客の応答速度にも依存します。

重大なバグに対するホットフィックス/パッチに数週間かかる場合があります

これは 2 年前まではそうでしたが、それ以来、毎月のホットフィックス リリース システムを導入しており、セキュリティ上の問題が発生した場合にはそれが加速されます。

過去のバージョンをエクスポート/インポートする機能はありません。唯一の方法は、基礎となるデータベースから手動でコピーすることです

これは確かに設計によるものです。ほとんどのインポート/エクスポート操作は、バージョンを処理しないように設計されています。これは、運用前環境から運用環境への移行、またはその逆に使用されることが最も多いためです。同じオブジェクトをインポートするときにコンテンツ オブジェクトのバージョンが存在する場合、それらは消去されません。ただし、JCR を使用してバージョンをエクスポートすることは可能ですが、これはそのままでは提供されません。バックアップの目的で、システム レベルでバックアップすることをお勧めします。

Jahia はクラスターとして機能するように設計されていますが、ユーザー セッションを複製することはできません。つまり、ユーザーが認証されているクラスター ノードがダウンした場合、ユーザーは再ログインする必要があります。

これはもはや真実ではありませんが、以前はそうでした。Jahia 6.5 より前では、セッションはシリアル化できませんでしたが、これはもはや当てはまりません。したがって、これは主にアプリケーション サーバー構成の制限であり、デフォルトではセッションを複製するように構成されていません。実際には、クラスタ ノードの障害は発生しないはずであり、障害が発生した場合は小さな制限が予想されるため、これは (あまり) 問題ではありません。

クラスタ ノードは、DB とファイル システムを共有する必要があります。データベースをクラスター化することはできません。Jahia は (技術的に) MySQL Cluster をサポートしていません。(背景: MySQL Cluster でサポートされていない BLOB/CLOB にインデックスを配置します)

これも正しくないと思います。MySQL に設定したすべてのインデックスを再確認しましたが、BLOB/TEXT またはそれらの長いバージョンには設定していません。また、ほとんどのクラスター展開では、クライアントは通常、Oracle のほうがそのようなソリューションとして確立されているため、Oracle を使用することを好みます。Jahia は、クラスタリングもサポートする PostgreSQL や Microsoft SQL Server などの他の強力なデータベースもサポートしています。

一般的なドキュメントには改善の余地があり、JavaDoc/ソース ドキュメントは基本的に存在しません

私はこれに同意します。ドキュメントは常に改善することができ、私たちは常にそれに取り組んでいます。JavaDoc はhttp://downloads.jahia.com/downloads/jahia/digitalfactory7.0.0/digital-factory-root-7.0.0.0-javadoc/で入手できます。また、ソース コードのドキュメントは、私たちが常に取り組んでいるものです。

弱いコミュニティ; jahia フォーラムの回答のほとんどは、jahia の従業員からのものです。

ただし、これはほとんどの場合真実ですが、同時に多くの統合は、残念ながら参加する時間や機会​​がないパートナーからのものです. これが、Jahiaの従業員が空き時間に回答する理由ですが、ほとんどの質問には回答があります。もちろん、私たちは常にコミュニティを拡大する新しい方法を探しており、最初のユーザー カンファレンス JahiaOne は、最も楽観的な予測を上回りました。フォーラムでは、現在ユーザーが戻ってくるインセンティブがないため、毎月のダイジェストを追加するのは良いことだと思います.

利用可能な公開テンプレートはありません (jahia のものを除く)

コメントはありません。可能な限り汎用的で完全なデフォルト テンプレートをいくつか提供していますが、すべての貢献を歓迎します。

于 2014-05-23T08:54:39.337 に答える
1

ジャヒアの長所:

  • Java ベースの CMS で利用可能な最高のユーザー インターフェイス/バックエンド/管理
  • Jahiaは常に製品を改善しています
  • インストールが簡単で、小さなサイトを立ち上げて実行する
  • 独自の構造を定義する場合、JCR により非常に柔軟です。

ジャヒアの短所：

  • JCR は、大規模 (10000 以上のページ、> 50000 のコンテンツ要素) サイト、特に mysql を使用する場合のボトルネックのようです。バンドルされている Java-In-Memory-DB ははるかに高速です。
  • Jahias Lucene のバージョンが古い
  • 独自のアプリ/モジュールを開発する場合は、JSP を使用する必要があり、JSF を使用することはできません (Jahia は Spring Webflow を統合する計画がありますが、それがいつなのかはわかりません ...)
  • 反応時間に関しては、サポートが遅い
  • 重大なバグに対するホットフィックス/パッチに数週間かかる場合があります
  • 過去のバージョンをエクスポート/インポートする機能はありません。唯一の方法は、基礎となるデータベースから手動でコピーすることです
  • Jahia はクラスターとして機能するように設計されていますが、ユーザー セッションを複製することはできません。つまり、ユーザーが認証されているクラスター ノードがダウンした場合、ユーザーは再ログインする必要があります。
  • クラスター ノードは、DB とファイル システムを共有する必要があります。データベースをクラスター化することはできません。Jahia は (技術的に) MySQL Cluster をサポートしていません。(背景: MySQL Cluster でサポートされていない BLOB/CLOB にインデックスを配置します)
  • 一般的なドキュメントには改善の余地があり、JavaDoc/ソース ドキュメントは基本的に存在しません
  • 弱いコミュニティ; jahia フォーラムの回答のほとんどは、jahia の従業員からのものです。
  • 利用可能な公開テンプレートはありません (jahia のものを除く)
于 2013-02-14T11:49:07.893 に答える
1

昨年、私たちは自分たちでこの選択をしなければなりませんでした。Jahia と Magnolia の両方をインストールし、包括的な比較を行った後、Magnolia を選択しました。どちらも似ていますが、Jahia よりも Magnolia でモジュールを作成する方が開発者にとって簡単でした。Magnolia では、jsp テンプレートを編集してカスタマイズを行います。Jahia では、開発者がバッキング Java クラスを作成し、そのクラスをコンパイルしてデプロイする必要があるなど、より複雑です。

Magnolia を選んだ後、コンテンツ エディターの使いやすさとパフォーマンスに非常に満足しています (Magnolia はページを gzip で圧縮し、パフォーマンスのためにキャッシュに保存します)。 .com。表示されるものはすべて、コンテンツ エディターが変更できるマグノリア テンプレートに基づいています。

于 2011-02-01T18:27:59.397 に答える
0

マグノリアよりジャヒアを選びました。

  • 役割の明確な分離：ウェブマスター、一時的な編集、開発者、寄稿者、編集者
  • モジュールを簡単に作成できるため、Jahiaをクリーンな方法で拡張できます
  • 編集モードは、ページ上のコンポーネントのドラッグアンドドロップで非常にクールです
  • 高価すぎない。エンタープライズサポートは非​​常に優れています
  • 彼らの有給の訓練は良いです

短所：-コミュニティは非常に小さいようです-オンラインドキュメントはそれほど多くなく、フォーラムはあまり活発ではありません-開始するにはトレーニングが必要です

于 2013-02-13T00:42:22.530 に答える
0

以下は、私が Apache Roller メーリング リストで行った関連する質問からの Jahia に関するフィードバックです。

http://web.archiveorange.com/archive/v/PxZtPQyYMTldSEuEePMb

于 2011-01-29T19:15:09.327 に答える
0

JCR の問題は、最適化に関する技術文書があまりないことです。ほとんどの場合、JCR はどの RDBMS よりも優れたパフォーマンスを発揮します。ただし、階層構造に精通し、約 1000 を超える子ノードを持つべきではないことを知っておくことが重要です (したがって、階層を構造化します)。JCR 内で 400 万人を超えるユーザーのパーソナライズされたデータをマスターしています。

その観点から見ると、すべてが JCR 内に構築されているため、Magnolia の方がセットアップが優れています。Magnolia は Web アプリ インスタンスとして実行され、あるインスタンスから別のインスタンスにコンテンツを簡単にデプロイできます。Magnolia は、私たちが「コンテンツ中心」の CMS と呼んでいるものです。これは、コンテンツがページ上で直接編集され、それが表示される場所で直接編集されることを意味します。もちろん、いわゆる「ルックアップ コンテンツ」、つまり Web 階層外の 1 つの場所で作成され、Web サイトの複数の場所で再利用されるコンテンツ (別名「ソフト参照コンテンツ」) を作成することは可能です。

Jahia は間違いなく非常に興味深いソリューションですが、RDBMS に依存しなければならない (したがって不要な統合依存関係がある) ことは、エンタープライズ ソリューションにとって大きな「欠点」です。スケーリングも簡単ではありませんが、Magnolia ではいつでも新しい「パブリッシュ」(または「レンダリング」) インスタンスをセットアップして、パフォーマンスとセキュリティ (フェイルセーフ) を向上させることができます。

于 2013-02-23T17:16:14.470 に答える
0

今のところ、私たちはジャヒアと一緒に行きました。与えられた理由は、ウェブサイトの編集部分がより見栄えが良く、コンテンツ編集者にとってより簡単に見えるからです. また、新しいテンプレートを作成し、jQuery を追加して、これを Jahia 内で機能させる方が簡単であることも自分自身に不満です。

Magnolia では、コンテンツ リポジトリを直接編集している (pgAdmin でデータベース テーブルを編集するなど) という感覚がずっとありましたが、Magnolia の「ツリー」は、自分が行ったことが良いかどうかを教えてくれませんでした。多くの推測が含まれていました。無効な値を入力しても、magnolia は問題なくそれを受け入れます。

Jahia の経験に関する最新情報: これまでのところ、Jahia には非常に満足しています。現時点では、単一のサーバーで約 4000 人のユーザーに対して問題なく実行しています。現在のデータセットでは、速度も問題ではありません。jahia のサポートはかなり良いです。他の人が数週間投稿したものよりもはるかに優れています。私は通常、1 ～ 2 日 (契約によると 3 日) で正式なサポートを受け取ります。 、通常1時間以内に、彼らはとてもフレンドリーな人々です.

于 2011-02-25T20:22:45.413 に答える