Return to the not-so cacheable Control in Sitecore 5.3

Ok so,

It would appear that my previous post on this subject somehow managed to misdirect the focus from what was the original intention; point out the very troublesome issue of Sitecore Support's policy of recommending Sitecore 6 upgrades for Sitecore 5 problems.

The issue at hand was that of a certain Control not being cached. Well it was, but the code was also executed. Although asked specifically for workarounds, no alternatives to the upgrade route was presented. A short while spent in Reflector, a few config files and so on, leads me to believe there could be a workable solution.

This has NOT been tested outside my sandbox testing environment however, any feedback would be appreciated.

The "CachingEnabledControl". Inherit from this one and your work is 90% done.

Now all you need to do, in top of your CreateChildControls() method, is check if Sitecore has a cached copy of your control that it intends to show.

public class MyCacheableControl : CachingEnabledControl
{
 protected override void CreateChildControls()
 {
  if ( IsSitecoreCached )
   return;

  // Normal functionality here

Given the same setup as described in the original post, we now no longer incur the long delay (.Sleep()), and Sitecore outputs it's cache just fine.

Please DO keep in mind, this is probably UNSUPPORTED and MIGHT NOT WORK FOR YOU AT ALL - for whatever reason :P

Here's the source file. MyCacheableControl.cs

How do you DO?

As someone recently commented, this blog is not overall a very positive one. And while it was never my intention to write a fanboi blog, it doesn't have to be all negative either ;-)

Overall, I have grown to like the Sitecore product quite a lot. I find, that I am able to apply it to most any scenario my clients throw at me (though there was this one client of my former employer, who wanted the CMS to realtime translate her articles into all of the other installed languages... :P) - It helps me get the job done.

Now I am sure that most people who work implementing Sitecore solutions on a regular basis has adapted a way of their own. Either in the form of socalled "Helper" libraries, or maybe a drawer full of ready to go renderings for topmenus, left menus, breadcrumbs and whatnot. Me, as I often work with Sitecore jobs that involve tight integration with Sitecore data and external data (either in form of added Sitecore functionality, or migration from third party systems for instance), my most important tool in the drawer is the ability to work following modern OO practices - Domain Objects if you will.

I decided it is time for me to share something with the Sitecore community that makes it easy to do just that. Basically, this is my "5th generation" data layer if you will, although I would probably huff over anyone classifying this as generic "DAL".

Not only is it being shared, it is being shared in full. It is being released under the GNU General Public License v3, sources and all, in the hope there are other people out there that can see the benefit of the approach I suggest and will find it useful.

Here's a quick snippet of how Sitecore integration looks, when using it:

Enough rambling for now. Head on over to the official site in the Sitecore Shared Source Library to grab your copy, and to have a look around.

• Trac space for CorePoint.DomainObjects
• Getting started guide
• Release blog post from Jimmie Overby, Sitecore Shared Source Coordinator
• Entry point on SDN

Say goodbye to Sitecore 5.3

No really. Say goodbye. What, just 3 weeks ago, was "designed to drive the largest sites on the planet. ... ... deliver compelling user experiences at lightning speeds using a combination of high availability options, intelligent caching controls, and the power of ASP .NET 2.0" (ref: http://www.sitecore.net/Products/Sitecore%20CMS.aspx) is now yesterday's news.

As I am sure any reader of this blog will know, the new Sitecore CMS flagship, Version 6 (formerly or maybe still known as Crestone) launched on 30th of July 2008, and everyone at Sitecore seems well pleased with it. They have every right to be, don't get me wrong... After what happened "back in the day" when Sitecore 5 was first launched, the transition to Sitecore 6 promises to be a much smoother ride indeed. It looks good, congratulations :-)

This post isn't about Sitecore 6 however. It's about what happens now, to you, to your clients, to your existing Sitecore 5.x solutions.

If it wasn't for the fact that I don't particularly want to spend my entire time blogging on potential and concrete issues in Sitecore 5.x; I could probably still make this a full time profession. Known issues, hotfixes, regression and non-regression tested 5.3 builds...

The question I'm asking is; will we ever get to see a stable 5.3 release now that all the spotlight has moved on to the new emperor's clothes? Surely there must be hundreds if not thousands of 5.x sites out there, and surely one cannot reasonably expect all of them to be willing to invest quite substantially in the upgrade to 6.x just to get a bugfree (or well... tolerable) product?

First line of defense from Sitecore Support seems to see this as perfectly reasonable. Take this recent scenario that played out. You can reproduce this yourself very easily. I tested this on Sitecore 5.3.1 Build 071114 - the only current Sitecore "Recommended Release" (you running 5.3.2?....)

Make yourself a new control, like this:

Simplest control ever. It outputs the current time. Now register this control on a sublayout.

Go to your Layout settings on the sublayout you registered the control on, and make sure caching is enabled (you DO do this by default, I take it..?).

Make sure you've published, and go take a look. Not surprisingly, the Sleep( 10000 ) in there causes quite a delay. Pretend this is your extremely heavy backend integration code executing. After the delay has passed, your page comes up.

Quite as expected. Now click refresh... This is where you start speculating if you did remember to configure caching correctly. I mean, after all, it is quite an involved process with lots of little things to tweak.

The 10 seconds will pass, and voila... Erm.... Well.... there you go, your cached output - again.

So Sitecore realises, AFTER deciding to render your control again (and therefore, running your extremely heavy backend integration code once again), that "aaah... ok let's disregard, and just use what's in cache instead.

Makes a lot of sense doesn't it? ;-)

In case you didn't follow. Sitecore will execute everything, thereby allowing your webserver to consume expensive resources (and even stop and wait for the result), then dump the result and use what it has in cache already.

Mmhmm.

Admittedly, caching and the way Sitecore has to implement it is very tricky stuff indeed. Am not disputing that there's a bug here (... but has this ever worked?). What really got me ticking was the response I got from Sitecore Support on this matter.

"Hi Mark,I have checked this and indeed Sitecore will return cached output but control code will be executed. This was fixed in Sitecore 6.Best regards"

To which, I imagine, there can only be one response; "So?". I have requested information on when a 5.3 fix will be available. Was told this has been put forward to developers, so we'll see what comes of it.

I am stunned however, at how easily the "support decision" was to proclaim that a switch between major versions was the way to go. I don't know about you guys, but I would hate having to go to my customer and go... "You know... I know that 3 weeks ago, Sitecore was the king of kings, intelligent caching and so on. But you see... well... it doesn't really work like intended. Don't worry however, your £75.000 investment is safe and sound. All you need to do, is invest in Sitecore 6 training for your 8 editors (who only NOW are getting to know the system), a simple quick £10.000 upgrade project, possibly a small license increase and THEN we're in business. Really, we are."

Sitecore Support was right, just for the record. The problem described here does not manifest in Sitecore 6.

Is the new mantra really; "Our website is running on it [Sitecore v6] - Why isn't yours?" ?