I've been having some problems using @OutputCache in the .NET user controls I've created in Umbraco 1.4.2.
I'm including the user controls directly on the template (not as macros) and want to enable output caching on some of them via the @OutputCache directive as I understand this is the preferred method for doing so. I have the same user control that is used on several different templates on several different levels in the hierarchy. Basically the cached result needs to be different for each page.
I initially tried just the following on the user control: <%@ OutputCache Duration="100" VaryByParam="*" %>
On different levels in the hierarchy (also different templates) the caching worked as expected. However when I go to two separate pages on the same level in the hierarchy (using same template), the first page that was loaded displays for all pages using that same template on the same level on the hierarchy.
I tried overriding the umbraco.Global class so that I coudl override the GetVaryByCustomString method and trying doing VaryByCustom for the OutputCache but my method never even gets hit!? The directive I used for this is: <%@ OutputCache Duration="100" VaryByParam="*" VaryByCustom="Page,ProductCategories" %>
So:
1) What's the best way to do Output Caching with .NET user controls if you don't want to make them macros?
2) Why isn't my GetVaryByCustomString method getting hit in the class I overrode umbraco.Global in?
I tried overriding Application_Start in my class that overrides umbraco.Global and it never gets hit either.
In an effort to see if what I'm trying to do would work, I did as some recommended for earlier versions of Umbraco, deleted App_global.asax.dll, used my own Global.asax, and everything works perfectly.
So for whatever reason the class I'm overriding umbraco.Global with just isn't getting recognized. Is there anything else special I need to do for this? From what I read all I needed to do was override umbraco.Global and it should work, just like I can do with the ApplicationBase class. I would prefer to go the overriding route if at all possible.
Well what I ended up doing was making my new Global.asax code behind file inherit from the umbraco.Global file and then deleted App_global.asax.dll and it works like a champ. I don't know if that's how it was intended to be used or not, but that is the only way it would work for me.
I think you can undo all your work. Umbraco allows you to cache usercontrols by setting several options as you can see below. By setting the cache period you enable caching. Cache by page will cach the control per page and cache personalized will cache per user also.
I'm aware of the caching option in Umbraco, but that requires setting up all the user controls as macros. I have included them all by registering them in the template, as per the recommendation of some of the Umbraco developers: "If you register the control yourself it will be faster as there is no dynamic creation of the user control instance from the Umbraco request, this is all handled via the ASP.NET runtime. It can also give you greater flexibility if you want to use features such as Dependency Injection, as you're running in the ASP.NET life cycle entirely, not being injected into the page from an outside source. "
Additionally, using .NET output caching instead of the Umbraco caching is much faster, also according to one of the Umbraco devs:
"Output cache is entirely different from the caching of Macros in Umbraco. Macro caching in Umbraco doesn't use .Net Output Caching, rather it uses HttpRuntime.Cache. Output caching is one of the very first Http modules hit in the .Net request pipeline and it is extremely fast. HttRuntime cache needs to get much further in the request pipeline and in the case of Umbraco, by the time it returns data from the runtime cache, the request has probably already started into the page lifecycle. Output caching is much faster than http runtime cache."
Problems with OutputCache and .NET User Controls
Hey All,
I've been having some problems using @OutputCache in the .NET user controls I've created in Umbraco 1.4.2.
I'm including the user controls directly on the template (not as macros) and want to enable output caching on some of them via the @OutputCache directive as I understand this is the preferred method for doing so. I have the same user control that is used on several different templates on several different levels in the hierarchy. Basically the cached result needs to be different for each page.
I initially tried just the following on the user control: <%@ OutputCache Duration="100" VaryByParam="*" %>
On different levels in the hierarchy (also different templates) the caching worked as expected. However when I go to two separate pages on the same level in the hierarchy (using same template), the first page that was loaded displays for all pages using that same template on the same level on the hierarchy.
I tried overriding the umbraco.Global class so that I coudl override the GetVaryByCustomString method and trying doing VaryByCustom for the OutputCache but my method never even gets hit!? The directive I used for this is: <%@ OutputCache Duration="100" VaryByParam="*" VaryByCustom="Page,ProductCategories" %>
So:
1) What's the best way to do Output Caching with .NET user controls if you don't want to make them macros?
2) Why isn't my GetVaryByCustomString method getting hit in the class I overrode umbraco.Global in?
I tried overriding Application_Start in my class that overrides umbraco.Global and it never gets hit either.
In an effort to see if what I'm trying to do would work, I did as some recommended for earlier versions of Umbraco, deleted App_global.asax.dll, used my own Global.asax, and everything works perfectly.
So for whatever reason the class I'm overriding umbraco.Global with just isn't getting recognized. Is there anything else special I need to do for this? From what I read all I needed to do was override umbraco.Global and it should work, just like I can do with the ApplicationBase class. I would prefer to go the overriding route if at all possible.
EDIT (couldn't change first post), I'm using Umbraco 4.5.2 not 1.4.2 lol.
Well what I ended up doing was making my new Global.asax code behind file inherit from the umbraco.Global file and then deleted App_global.asax.dll and it works like a champ. I don't know if that's how it was intended to be used or not, but that is the only way it would work for me.
Hi Danny,
I think you can undo all your work. Umbraco allows you to cache usercontrols by setting several options as you can see below. By setting the cache period you enable caching. Cache by page will cach the control per page and cache personalized will cache per user also.
Cheers,
Richard
Hey Richard,
I'm aware of the caching option in Umbraco, but that requires setting up all the user controls as macros. I have included them all by registering them in the template, as per the recommendation of some of the Umbraco developers: "If you register the control yourself it will be faster as there is no dynamic creation of the user control instance from the Umbraco request, this is all handled via the ASP.NET runtime. It can also give you greater flexibility if you want to use features such as Dependency Injection, as you're running in the ASP.NET life cycle entirely, not being injected into the page from an outside source. "
Additionally, using .NET output caching instead of the Umbraco caching is much faster, also according to one of the Umbraco devs:
"Output cache is entirely different from the caching of Macros in Umbraco. Macro caching in Umbraco doesn't use .Net Output Caching, rather it uses HttpRuntime.Cache. Output caching is one of the very first Http modules hit in the .Net request pipeline and it is extremely fast. HttRuntime cache needs to get much further in the request pipeline and in the case of Umbraco, by the time it returns data from the runtime cache, the request has probably already started into the page lifecycle. Output caching is much faster than http runtime cache."
From: http://www.farmcode.org/post/2010/07/13/TheFARMe28099s-guide-to-Macros.aspx
is working on a reply...