2016-11-01 12 views
1

ItemResolverの後にカスタムパイプラインプロセッサを挿入して、ドロップダウンリストからコンテンツエディタで選択した新しいアイテムを現在のコンテキストアイテムに上書きします。リダイレクトなしでsitecoreアイテムを変更する

私は私のウェブサイトを通じて、私のプロセッサを介して通常のリクエストを経由してそのダイナミックな項目に移動し、私は私のコンテキスト項目を変更すると、それはSTIL同じ項目レンダリングされます:私が発行した場合、不思議

public override void Process(HttpRequestArgs args) 
{ 
    // some code 
    Context.Item = dropLink.TargetItem; 
} 

をアイテムのAPIを介して要求、サイトコアは、ここで成功し

//api call 
Context.Item = Context.Database.SelectSingleItem("fast:/sitecore/content/mysite/dynamicitem"); 

項目は私の設定ファイルで変更します。

<pipelines> 
<httpRequestBegin> 
    <processor patch:after="* @type='Sitecore.Pipelines.HttpRequest.ItemResolver, Sitecore.Kernel']" type="MyDll.Web.Pipelines.LandingPageResolver,MyDll.Web" /> 
</httpRequestBegin> 
</pipelines> 
+0

itemresolverの前にパッチを適用することはできますか? –

+0

同じプロセッサでは、いくつかのAPI呼び出しを行い、項目が影響を受けると言っていますか?また、dropLink.TargetItemの代わりにSelectSingleItemを実行すると、API呼び出しなしでSelectSingleItemをテストできますか? – RvanDalen

+0

私はプロセッサでAPI呼び出しを行いません。たとえば、ブラウザからアイテムのAPI呼び出しを発行し、プロセッサ内でコンテキストアイテムをランダムに変更して、コンテキストアイテムを正常に変更できます。 SelectSingleItemでテストしましたが、成功しませんでした。 – vel

答えて

3

MVCを使用しているので、別のパイプラインセットを使用して項目が解決されます(そのため)、その代わりにパッチを適用する必要があります。

mvc.getPageItemパイプラインにおけるGetFromRouteUrlプロセッサは、次に、最終的Context.Itemに設定されている要求されたURLに一致するアイテムにargs.Resultを設定し、それは、本質的にURLに基​​づいて、「正しい」の項目に戻ってアイテムをリセットし、その変更を上書きあなたは以前に作った。

mvc.getPageItemに必要なプロセッサを追加して、コンテキストアイテムがすでに解決されているかどうかを確認する必要があります。

ItemResolverでコードを更新し、すでにカスタムロジックを使用して解決している、これは二回解決ロジックを実行する必要がなくなりますことを示すブール値を格納します。

public override void Process(HttpRequestArgs args) 
{ 
    // some code 
    Context.Item = dropLink.TargetItem; 
    Context.Items["custom::ItemResolved"] = true; 
} 

はあなたかどうかを確認する新しいクラスを作成します。

public class CheckItemResolved: GetPageItemProcessor 
{ 
    public override void Process(GetPageItemArgs args) 
    { 
    if (args.Result == null) 
    { 
     var resolved = Sitecore.Context.Items["custom::ItemResolved"]; 
     if (MainUtil.GetBool(resolved, false)) 
     { 
      // item has previously been resolved 
      args.Result = Sitecore.Context.Item; 
     } 
    } 

    return; 
    } 
} 

そして、このパッチを当てる:

<pipelines> 
    <mvc.getPageItem> 
    <processor type="MyProject.Custom.Pipelines.CheckItemResolved, MyProject.Custom" 
     patch:before="*[@type='Sitecore.Mvc.Pipelines.Response.GetPageItem.GetFromRouteUrl, Sitecore.Mvc']" /> 
    </mvc.getPageItem> 
</pipelines> 
カスタム・ロジックは、すでに項目を解決しました

直後のパイプラインはGetFromFromUrl()であり、通常はアイテムを再解決してargs.Resultと設定します。これをContext.Itemに戻すことで、プロセッサは早期に切り離され、以前のロジックだけが残されます。

MVC and Pipelines in the documentationについてさらに詳しく知ることができます。

+0

こんにちは、ありがとうございました。私はそのブールフラグでトリックを使用し、今私はCheckItemResolvedクラスの中でそのフラグをチェックしています。解決済みの項目が見つかった場合は、args.Result = Context.Item;を実行します。なぜあなたのコードスニペットで(args.Result!= null)このチェックを行うかわからない。私の場合、そのResultは常にnullです。ちょうど私が理解できるスニペットか、それともプロダクションコードなのかはわかりません。再度、感謝します! – vel

+0

すごくうれしいです。チェックはコードと関連がありますので、必要に応じて調整してください。 'argsの設定。Result = Context.Item; 'は完全に有効ですが、次のプロセッサ(' GetFromOldContext')はまったく同じことをします。したがって、nullに設定します。 – jammykam

関連する問題