« Archives in April, 2011

Prevent nullrefs when databinding with placeholders

I love databinding. It allows me to keep view-logic in ascx/aspx files so I don’t have to read long code-behind files laden with initialization logic and page lifecycle related crap.

Databinding works better with WPF and Silverlight than it does with ASP.NET. But in my humble opinion it still beats the alternative in ASP.NET.

One very annoying problem I’ve run into when using databinding in ASP.NET is the use of placeholders. The placeholder is a control that we use as the equivalent of an if-statement in C#. If the “Visible” property evaluates as true, only then the contents are rendered.

This works well in most cases. But when you use databinding it sort of breaks. For example:

This code will work perfectly fine, unless “SomeProperty” evaluates to null, because the contents of the placeholder are always evaluated! This problem is especially annoying with Sitecore FieldRenderers, which don’t allow the “Item” property to be null. A simple fix to this problem is to repeat the null-check within the placeholder, like so:

But if you would have a more complicated condition, many unsafe binding statements within the placeholder or nesting of several placeholders, this fix can prove to be quite cumbersome.

So I tried to find a good workaround for this problem and I observed the repeater control. It does not have this problem, because the contents of “ItemTemplate” will never be evaluated if the collection in the datasource is empty. This is what I came up with:

That works really well! I used the repeater as a placeholder and now, if “SomeProperty” evaluates to null, there will be no problem; the contents of “ItemTemplate” are never evaluated by the databinder.

Still, this is quite an ugly workaround, because it’s pretty verbose and not really intuitive to programmers. So we need a better solution.

And I found one! I created a custom control that derives from the PlaceHolder control. The only difference in behaviour is that the contents of the control are not evaluated by the databinder if the “Visible” property is null. Here’s the code for the control:

This is a pretty simple change, but it makes life so much easier. If we import the control and use it in the following way, we no longer have to worry about nullref problems:

Happy coding!

Update CompiledDomainModel from Visual Studio

My friend and I were talking about the CompiledDomainModel module the other day. He suggested that it would be a little easier if you could update the code from Visual Studio.

A few options were discussed, until we arrived at a rather nifty one. The generated code would start with a certain prefix, followed by a url that can be used to regenerate the code. Then, a Visual Studio plugin or macro could refresh the code by downloading it from that location.

Well, I’ve implemented just that! The code needed in CompiledDomainModel can be found in the current trunk version in SVN and I´ll add it to the release notes for the next release. The macro for updating generated code can be found on this page.

The following steps should be taken to generate code from Visual Studio (I’ve tested this with VS2010, and I’m not sure if it will work with VS2008):

  1. Make sure you have the CompiledDomainModel version from the trunk (or the release after 0.4.1.0, when it’s released)
  2. Generate the code and paste it into a file in your solution in Visual Studio
  3. Install the macro
    Now, you’re all set up to use the macro, so you can skip the first 3 steps next time
  4. Open the generated file from the Solution Explorer and make sure it is checked out of source control (if configured)
  5. Run the macro
  6. Choose to reload the file from the file system when asked about it

You may notice a few things that are not that convenient yet:

  • You have to actually open the file before regenerating it – This was the quickest way I could figure this out. If anyone knows how to get the selected file from the solution explorer, then please let me know!
  • You have to check out the file from source control – The file must be writable. The macro writes the generated code directly to the filesystem, because writing it in the editor turned out te be way too slow. Perhaps source control can be controlled from the macro as well, but I don’t know how to do that.
  • The module needs to be accessible to anonymous users, as the macro isn’t authenticated in Sitecore. But this is not really a problem in a development environment. This does mean that the comment always says “User ‘sitecore\Anonymous’ generated this file.”.

I’ve never coded a macro before; I’ve never even coded in VB.NET before (yes, I said the UGLY word). But even with these minor issues, the macro does seem to make things a little easier if you need to regenerate the code often.

Here’s the code for the macro. Have fun!

UA-4216957-1