Post-Cache Substitution
Post-Cache Substitution
The post-cache substitution feature (which is new in ASP.NET 2.0) revolves around a single method
that has been added to the HttpResponse class. The method is WriteSubstitution(), and it accepts a
single parameter—a delegate that points to a callback method that you implement in your page
class. This callback method returns the content for that portion of the page.
Here’s the trick: when the ASP.NET page framework retrieves the cached page, it automatically
triggers your callback method to get the dynamic content. It then inserts your content into the
cached HTML of the page. The nice thing is that even if your page hasn’t been cached yet (for example,
it’s being rendered for the first time), ASP.NET still calls your callback in the same way to get the
dynamic content. In essence, the whole idea is that you create a method that generates some
dynamic content, and by doing so you guarantee that your method is always called, and its content
is never cached.
The method that generates the dynamic content needs to be static. That’s because ASP.NET
needs to be able to call this method even when there isn’t an instance of your page class available.
(Obviously, when your page is served from the cache, the page object isn’t created.) The signature
for the method is fairly straightforward—it accepts an HttpContext object that represents the current
request, and it returns a string with the new HTML. Here’s an example that returns a date with
bold formatting:
private static string GetDate(HttpContext context)
{
return "<b>" + DateTime.Now.ToString() + "</b>";
}
To get this in the page, you need to use the Response.WriteSubstitution() method at some
point:
protected void Page_Load(object sender, EventArgs e)
{
Response.Write("This date is cached with the page: ");
Response.Write(DateTime.Now.ToString() + "<br />");
Response.Write("This date is not: ");
Response.WriteSubstitution(new HttpResponseSubstitutionCallback(GetDate));
}
Now, even if you apply caching to this page with the OutputCache directive, the date will still
be updated for each request. That’s because the callback bypasses the caching process. Figure 11-2
shows the result of running the page and refreshing it several times.
The problem with this technique is that post-cache substitution works at a lower level than the
rest of your user interface. Usually, when you design an ASP.NET page, you don’t use the Response
object at all—instead, you use web controls, and those web controls use the Response object to
generate their content. One problem is that if you use the Response object as shown in the previous
example, you’ll lose the ability to position your content with respect to the rest of the page. The only
realistic solution is to wrap your dynamic content in some sort of control. That way, the control can
use Response.WriteSubstitution() when it renders itself.
However, if you don’t want to go to the work of developing a custom control just to get the postcache
substitution feature, ASP.NET has one shortcut—a generic Substitution control that uses this
technique to make all its content dynamic. You bind the Substitution control to a static method
that returns your dynamic content, exactly as in the previous example. However, you can place the
Substitution control alongside other ASP.NET controls, allowing you to control exactly where the
dynamic content appears.
Here’s an example that duplicates the earlier example using markup in the .aspx portion of
the page:
This date is cached with the page:
<asp:Label ID="lblDate" runat="server" /><br />
This date is not:
<asp:Substitution ID="Substitution1" runat="server" MethodName="GetDate" />
Unfortunately, at design time you won’t see the content for the Substitution control.
Remember, post-cache substitution allows you to execute only a static method. ASP.NET still
skips the page life cycle, which means it won’t create any control objects or raise any control events.
If your dynamic content depends on the values of other controls, you’ll need to use a different technique
(such as data caching), because these control objects won’t be available to your callback.
The post-cache substitution feature (which is new in ASP.NET 2.0) revolves around a single method
that has been added to the HttpResponse class. The method is WriteSubstitution(), and it accepts a
single parameter—a delegate that points to a callback method that you implement in your page
class. This callback method returns the content for that portion of the page.
Here’s the trick: when the ASP.NET page framework retrieves the cached page, it automatically
triggers your callback method to get the dynamic content. It then inserts your content into the
cached HTML of the page. The nice thing is that even if your page hasn’t been cached yet (for example,
it’s being rendered for the first time), ASP.NET still calls your callback in the same way to get the
dynamic content. In essence, the whole idea is that you create a method that generates some
dynamic content, and by doing so you guarantee that your method is always called, and its content
is never cached.
The method that generates the dynamic content needs to be static. That’s because ASP.NET
needs to be able to call this method even when there isn’t an instance of your page class available.
(Obviously, when your page is served from the cache, the page object isn’t created.) The signature
for the method is fairly straightforward—it accepts an HttpContext object that represents the current
request, and it returns a string with the new HTML. Here’s an example that returns a date with
bold formatting:
private static string GetDate(HttpContext context)
{
return "<b>" + DateTime.Now.ToString() + "</b>";
}
To get this in the page, you need to use the Response.WriteSubstitution() method at some
point:
protected void Page_Load(object sender, EventArgs e)
{
Response.Write("This date is cached with the page: ");
Response.Write(DateTime.Now.ToString() + "<br />");
Response.Write("This date is not: ");
Response.WriteSubstitution(new HttpResponseSubstitutionCallback(GetDate));
}
Now, even if you apply caching to this page with the OutputCache directive, the date will still
be updated for each request. That’s because the callback bypasses the caching process. Figure 11-2
shows the result of running the page and refreshing it several times.
The problem with this technique is that post-cache substitution works at a lower level than the
rest of your user interface. Usually, when you design an ASP.NET page, you don’t use the Response
object at all—instead, you use web controls, and those web controls use the Response object to
generate their content. One problem is that if you use the Response object as shown in the previous
example, you’ll lose the ability to position your content with respect to the rest of the page. The only
realistic solution is to wrap your dynamic content in some sort of control. That way, the control can
use Response.WriteSubstitution() when it renders itself.
However, if you don’t want to go to the work of developing a custom control just to get the postcache
substitution feature, ASP.NET has one shortcut—a generic Substitution control that uses this
technique to make all its content dynamic. You bind the Substitution control to a static method
that returns your dynamic content, exactly as in the previous example. However, you can place the
Substitution control alongside other ASP.NET controls, allowing you to control exactly where the
dynamic content appears.
Here’s an example that duplicates the earlier example using markup in the .aspx portion of
the page:
This date is cached with the page:
<asp:Label ID="lblDate" runat="server" /><br />
This date is not:
<asp:Substitution ID="Substitution1" runat="server" MethodName="GetDate" />
Unfortunately, at design time you won’t see the content for the Substitution control.
Remember, post-cache substitution allows you to execute only a static method. ASP.NET still
skips the page life cycle, which means it won’t create any control objects or raise any control events.
If your dynamic content depends on the values of other controls, you’ll need to use a different technique
(such as data caching), because these control objects won’t be available to your callback.
