2010-09-02 13 views
4

J'ai une page sitecore avec une liste déroulante ASP, et les données du formulaire sont renseignées à partir de la valeur sélectionnée de la liste déroulante. Lorsque l'élément sélectionné de la liste déroulante est modifié, une publication est déclenchée. Dans la publication, le nouvel élément sélectionné est ajouté à la chaîne de requête et l'utilisateur est redirigé (pour la connectivité).Sitecore: Activation du comportement de publication des blocs de caching HTML

J'ai récemment activé la mise en cache HTML (pour toutes les sous-couches, "Vary by querystring"), et maintenant tout à coup, ce mécanisme ne fonctionne plus. Ce qui semble arriver, c'est que je sélectionne un nouvel élément de liste déroulante, la page semble afficher (bien que si je débogue, aucun de mes points d'arrêt ne soit touché). Après cela, si je change à nouveau l'élément sélectionné, je peux voir dans Firebug le message "__doPostBack n'est pas défini", ce qui semble indiquer que le JavaScript généré par ASP n'est pas ajouté à la page.

Répondre

4

L'activation de la mise en cache pour une sous-couche signifie que vous contournez entièrement le code et que Sitecore ne fait que diffuser le même code HTML que celui précédemment généré. Donc, il se comporte comme prévu. En d'autres termes, cela ne semble pas être un scénario où vous pouvez tirer parti de la mise en cache de sous-calage.

+0

Cela signifie-t-il que vous ne pouvez jamais utiliser la mise en cache de sous-calage lorsque vous effectuez une publication? –

+0

Voir http://intothecore.cassidy.dk/2008/07/say-goodbye-to-sitecore-53.html et http://intothecore.cassidy.dk/2008/07/return-to-not-so- cacheable-control-in.html. Les deux sont spécifiques à la version 5.3, mais j'ai le sentiment que la position de Sitecore est - ce comportement défectueux est "par conception". Cependant, il existe plusieurs façons de travailler avec. –

+2

Cette réponse est correcte. Travailler comme prévu. Vous pourriez être en mesure de mettre en cache d'autres fragments de la page, ou si la performance est encore un problème, refactoriser pour utiliser jQuery + JSON AJAX au lieu d'une publication. – techphoria414

0

Comme indiqué précédemment, ce comportement est attendu précisément parce que la page est extraite du cache. Vous pouvez toujours prendre en charge la mise en cache pour les charges non postback, mais le moyen le plus simple que j'ai trouvé est de détecter la publication avec du code dans Global.asax et de passer en conséquence, comme dans l'exemple ci-dessous.



    public override string GetVaryByCustomString(HttpContext context, string custom) 
    { 
     if (context.Request.RequestType.Equals("POST")) 
     { 
      context.Response.Cache.SetNoServerCaching(); 
      return "POST " + DateTime.Now.Ticks + " " + context.Request.RawUrl; 
     } 

     switch (custom) 
     { 
      case "RAWURL": 
       return context.Request.RawUrl; 
      default: 
       return ""; 
     } 
    } 

Ensuite, vous pouvez accrocher ce aux directives du cache de sortie dans vos commandes:

<% @ OutputCache durée = "3600" VaryByParam = "none" VaryByCustom = "RAWURL" % >

Notez que si vous le faites de cette façon, vous perdez la possibilité de varier en fonction de la source de données d'un contrôle.