日本語版
最新ニュース
企業

コンテンツ グラフの最適化 – 検索とナビゲーションと同様に計算されたゲッター プロパティを同期します

最近はOptimizely CMSを使ってブログを書き直しています。このプロセス中に、Optimizely が提供する新しくリリースされたテクノロジーを試してみたいと思いました。今日は、Content Graph に関する私の経験について少しお話します。 もちろん、検索とナビゲーションを使用することも考えましたが、私の意見では、最終的には検索とナビゲーションに完全に置き換わるものを学んだことは有益だったと思います。 検索とナビゲーションを使用すると、コンテンツ タイプ自体のプロパティだけでなく、計算されたプロパティ、つまりゲッターのみが使用されたプロパティも同期できることを、Optimizely 開発者の大部分がよく知っています。次の例はそれを示しています (FirstPublishedDate を参照)。 検索とナビゲーションを使用する場合、このプロパティにはインデックスが作成され、任意のクエリで使用できるようになります。また、その計算フィールドを使用して結果を並べ替えたり、検索とナビゲーションの C# クライアントで利用できる方法でコンテンツ タイプの特定の要素を表すさまざまな方法を含めたりするなど、さまざまな優れたトリックを実行できることも意味します。複雑な型は実際には強力ではないため、より単純化された便利なデータ形式を返すために、ゲッターのみのプロパティを追加することがよくあります。 したがって、コンテンツ グラフでも同じことができると思いましたが、残念ながら、今のところはできません。しかし、Optimizely はサポート リクエストを通じて、開発者がカスタマイズしてコンテンツ タイプのデータ同期を拡張できる機能を追加する計画があることを私に確認しました。それまでの間、私はゲッター プロパティを同期できるようにする非常に...しかし非常にハック的な回避策を考案しました。解決策に進む前に、何ができるのか、何ができないのかをもう少し理解するために、少し説明します。 スケジュール ジョブ「Optimizely Graph コンテンツ同期ジョブ」は、主に次のことを実行します。 すべての既存のコンテンツ タイプをスキャンし、コンテンツ グラフに同期します。それらの定義を使用して、コンテンツが独自のエンジンの下で持つべき構造を認識します。 次に、CMS 内のすべての既存コンテンツをスキャンし、コンテンツ グラフ内のすべてのデータを同期します。 これは私たちが興味を持っているステップです コンテンツ タイプを拡張し、ゲッターのみのプロパティの同期を可能にするソリューションを模索しているときに、次の点を尊重する必要があることに気付きました。 あなたの財産 できない ゲッターのみであっても、セッターを配置する必要があります。それ以外の場合、そのプロパティは考慮されないためです。 本物…

コンテンツ グラフの最適化 – 検索とナビゲーションと同様に計算されたゲッター プロパティを同期します

1729403292
2024-10-18 21:13:00

最近はOptimizely CMSを使ってブログを書き直しています。このプロセス中に、Optimizely が提供する新しくリリースされたテクノロジーを試してみたいと思いました。今日は、Content Graph に関する私の経験について少しお話します。

もちろん、検索とナビゲーションを使用することも考えましたが、私の意見では、最終的には検索とナビゲーションに完全に置き換わるものを学んだことは有益だったと思います。

検索とナビゲーションを使用すると、コンテンツ タイプ自体のプロパティだけでなく、計算されたプロパティ、つまりゲッターのみが使用されたプロパティも同期できることを、Optimizely 開発者の大部分がよく知っています。次の例はそれを示しています (FirstPublishedDate を参照)。

検索とナビゲーションを使用する場合、このプロパティにはインデックスが作成され、任意のクエリで使用できるようになります。また、その計算フィールドを使用して結果を並べ替えたり、検索とナビゲーションの C# クライアントで利用できる方法でコンテンツ タイプの特定の要素を表すさまざまな方法を含めたりするなど、さまざまな優れたトリックを実行できることも意味します。複雑な型は実際には強力ではないため、より単純化された便利なデータ形式を返すために、ゲッターのみのプロパティを追加することがよくあります。

したがって、コンテンツ グラフでも同じことができると思いましたが、残念ながら、今のところはできません。しかし、Optimizely はサポート リクエストを通じて、開発者がカスタマイズしてコンテンツ タイプのデータ同期を拡張できる機能を追加する計画があることを私に確認しました。それまでの間、私はゲッター プロパティを同期できるようにする非常に…しかし非常にハック的な回避策を考案しました。解決策に進む前に、何ができるのか、何ができないのかをもう少し理解するために、少し説明します。

スケジュール ジョブ「Optimizely Graph コンテンツ同期ジョブ」は、主に次のことを実行します。

  • すべての既存のコンテンツ タイプをスキャンし、コンテンツ グラフに同期します。それらの定義を使用して、コンテンツが独自のエンジンの下で持つべき構造を認識します。
  • 次に、CMS 内のすべての既存コンテンツをスキャンし、コンテンツ グラフ内のすべてのデータを同期します。 これは私たちが興味を持っているステップです

コンテンツ タイプを拡張し、ゲッターのみのプロパティの同期を可能にするソリューションを模索しているときに、次の点を尊重する必要があることに気付きました。

  • あなたの財産 できない ゲッターのみであっても、セッターを配置する必要があります。それ以外の場合、そのプロパティは考慮されないためです。 本物 CMS プロパティであるため、インデックス作成中に無視されます。あ 本物 プロパティは、「CMS -> 設定 -> コンテンツ タイプ」メニューに表示されます。
  • そこで、単に次を使用してセッターを追加しました this.SetPropertyValue() この限界を乗り越えるために。

プロパティを Optimizely データベースに同期すると、コンテンツ グラフのインデックス作成ジョブがまだプロパティを無視する部分が発生します。 Optimizely の逆コンパイルされたコードを読んでいると、現在のビジネス ロジックは次のとおりであることがわかりました。 のみ CMS データベース内に保存されたデータに依存するということは、最終的には 全て ジョブは内部コンテンツ タイプ テーブル内のデータを直接取得するだけであるため、コード内で定義された要素は完全に無視されます。

さて、ここで私は動的型を構築するというアイデアを思いつきました。 「Optimizely.ContentGraph.Cms.NetCore」アセンブリの「内部」型と対話できる動的アセンブリを作成する必要がありました。最終的には、目的の動作を同期ジョブに追加できるように IL コードを作成する必要がありました。簡潔に言うと、解決策が必要な場合は、これが私の GitHubリポジトリ 小さな例を挙げて説明します。動的タイプは「ContentGraphContentConverter」から継承され、IoC コンテナの下の元のタイプを置き換えます。 「Convert」メソッドでは、モデルを直接返す代わりに、拡張機能 AddReadonlyProperties を呼び出しています。これにより、戻り値をカスタマイズできるようになります。

コーディングを楽しんでください!

#コンテンツ #グラフの最適化 #検索とナビゲーションと同様に計算されたゲッター #プロパティを同期します

執筆者について: nipponese

Nipponese News編集部は、国内外のニュースを日本語で分かりやすくお届けします。