これを行うことはできますか？はい、残念ながら、それは本当に汚れている可能性があり、開発とテストに多分余分な時間がかかります。
問題
カスタムマクロを作成することを決定したときに注意すべき最初の事はあなたのマクロの実行を使用すると、アイテムコンテキストを持っていないだろうし、あなたのサイトのコンテキストshellあることを行っているときということです。
Sitecore.Context.Site：shellSitecore.Context.Item：つまりnull
これは、あなたがそれことをあなたのコンテキスト項目が実際に何であるかを判断する方法、あるいはサイトを持っていないことを意味します属する。
さらに悪いことに、コンテキストデータベースがcoreになることに注意してください。
Sitecore.Context.Database：つまりcore
これは、コンテキストデータベース、サイトおよびアイテムを解決し、その後にあなたのためのSessionで項目を格納するカスタムプロセッサを必要としていることを意味しつかいます。
ソリューションコンセプト
あなたは仕事にこれを取得するために、2つのことを行う必要があります：
- あなた
のために「コンテキスト」の項目を解決し、保存するカスタムプロセッサを作成します。
- Sitecoreクエリを受け入れる代替
rootパラメータをサポートするカスタムツリーマクロを作成します。
コンテンツエディタソリューション
[コンテンツエディタでこの仕事をしたい場合は、アイテムのフィールドが表示されたときに実行パイプラインを活用する必要があります。私はこれについていくつかの調査を行い、<getContentEditorFields>パイプラインに一番簡単に追加すると思います。
コンテンツ作成者がコンテンツエディタ内のアイテムに移動すると、このパイプラインが実行されてすべてのフィールドが表示されるという考えがあります。このパイプラインが実行されている間、あなたのプロセッサはあなたのマクロで使用するためにアイテムをつかんでセッションに保存します。
私はこれをテストしていませんが、そのコンセプトはうまくいくはずです。しかし、このソリューションの最大の欠陥は、エクスペリエンスエディタでは機能しないことです。
経験エディタソリューション
OPでの説明に基づいて、私は、このソリューションは、あなたのために働くだろうとは思わないが、私は念のためにそれが含まれています。
コンテンツ作成者がパーソナライゼーションなどのエクスペリエンスエディタでこのルールを使用していることが分かっている場合は、エクスペリエンスエディタのコンテンツオーサリングフローを利用してコンテキストを解決できます。
コンテンツ作成者がエクスペリエンスエディタのそのページに移動すると、典型的なSitecoreパイプラインが実行され、具体的には<httpRequestProcessed>パイプラインを使用して、コンテキストアイテムを解決して保存することができますsc_itemidクエリ文字列パラメータ。
私は上記をテストしていないこと、そしてこのソリューションをoriginal sourceから変更したことに注意してください。ロジックは健全ですが、最大の欠点は、これがコンテンツエディタでは機能しないことです。現実には、これはツリーのコンテキスト項目まで横断することから、あなたのコンテンツ制作者を救うために実行する作業のトンであるということである
結論
。彼らの経験ではより良いと思っています。選択した項目は子/子孫でなければなりませんが、コストはかなり高いです。
このような実装が本当に必要な場合は、代わりに自分の条件/アクションに子/子孫チェックを組み込むことをおすすめします。選択した項目が子/子孫でない場合は、ルールを中止し、エラーをログに記録し、ユーザーにエラーポップアップを表示します。それは同じUXではありませんが、それは汚れたハックと何時間もかかる必要はありません。