Instead of having a custom <asp:Label> with the exception from the backend, you can inject a custom error message to the validationsummary of an asp.net page.

Of course, you could use a server-side validator, but that fires everytime you submit the page, and not only after a succesful post. A Custom Validator is therefore in the wrong place.

Here's what I came up with:

To add a custom message to the summary, just do this:

For a client i needed a ASP.Net control that showed its contents in multiple columns. The CSS requirements forced me to develop a custom repeater for it, since the normal ASP.Net controls didn't suit me. I decided to share it with you, so here it is:

This templated databound control will collect items in multiple css div's when rendering. Provide a collection of css classes to indicate the columns (in this example, 3 divs). Rendering will be done from left to right, top to bottom while iterating over the div's.

+------++-------++-------+
| one  || two   || three |
| four || five  ||       |
+------++-------++-------+

[code] public class MultiColumnRepeater : Repeater
    {
        private string _columnClasses;

        /// <summary>
        /// Specifies the amount of columns and their css classes
        /// </summary>
        /// <example>
        /// To create 2 columns, specify "column_left,column_right".
        /// </example>
        public string ColumnClasses
        {
            get { return _columnClasses;  }
            set { _columnClasses = value;  }
        }

        protected override void RenderChildren(HtmlTextWriter writer)
        {
            //iterate over the different items.
            string[] classes = _columnClasses.Split(',');
            for (int column = 0; column < classes.Length; column++)
            {
                writer.AddAttribute(HtmlTextWriterAttribute.Class, classes[column]);
                writer.RenderBeginTag(HtmlTextWriterTag.Div);
               
                //iterate over all children, and only write the ones for the current columns.
                int index = 0;
                foreach (Control control in this.Controls)
                {
                    if (index % classes.Length == column)
                    {
                        control.RenderControl(writer);
                    }
                    index++;
                }

                writer.RenderEndTag();
                writer.Write(writer.NewLine);
            }
        }
    } [/code]

Now here's something interesting I didn't notice before: ASP.Net has health monitoring features built in. In Asp.net 1.1 I used to roll out our own code to catch web application errors and log them, but now they seem to be built in into the framework.

Since I don't like typing very much, here's the link to the full article on 4GuysFromRolla:

In most of our latest Sharepoint projects we need a lot of customization. These customization generally mean that we develop webpparts and custom lists so that we use sharepoint as a sort of database. The list itself is rarely visible to end users and only to a extended sharepoint site that is used as a backoffice application.

The development of the webparts go as follows:

• For every webpart we develop we have:
  • The <webpart>.cs control
  • The <webpart>Control.asc User control
  • The <webpart>.wsp XML file that is used to package the webpart
  • A Test<webpart>.aspx file that is used to test the webpart standalone but is never deployed to the sharepoint application.
• The webparts do not rely on sharepoint, but bind to strongly type objects and collection.
• A Provider pattern is used for retrieving and updating of the data objects.

This provider model allows us to test and verify functionality of the webparts without the need to upload/provision these webparts inside a Sharepoint hosted website. We all know this takes a lot of time. The provider is configured in the web.config of the webpart solution file.

Here's a sample of one of these business objects:

The user control uses this class in codebehind like so:

You see this is basic ASP.Net stuff.

I found this a pretty amazing thing; it cuts down on the time used for each development roundtrip, and it allows us to 'outsource' the development of the web parts to ASP.Net specialist who do not (yet) have the required Sharepoint knowledge. The knife cuts on two sides!

This approach did have an enormous disadvantage however. The provider that implemented the mapping from the hard-coded business object to sharepoint needed a lot of custom code. It only paid of once the business object was used in multiple places. Another problem is that the code that provisioned the custom list was always a one-off piece of custom code. That code has NO relation to the business object.

Now, my experiences with entitypool helped me in writing a library that solves all this:

To create the list in Sharepoint, all that is needed is the following statement:

To retrieve all appointmentobjects we have a factory that converts a SPListItemCollection to AppointmentObject objects:

Easy? I think so.

I'm here to tell you about my latest invention: SourceMetrics. It is a commandline tool to scan a source repository (actually just Visual Sourcesafe for now) and report a cool set of statistics about its contents.

Currently, it reports:

• Total number of files
• Total number of bytes
• Total number of lines
• Total number of code lines
• Total number of comment lines

As this tool reports code as Xml, it will be very easy to integrate with build script and tools like CruiseControl. The effect of having some kind of time-related statistics are huge. As first beta, and more info will be posted lated on.

I just saw this article about an invisible captcha on madskristensens' blog. The principle is amazingly simple.

Although it has a small security hole it's rather cool and sufficient for most spambots.