My Review of Peter's Data Entry Suite

The Task at Hand

A couple years ago I began one of the biggest projects of my career. I work for TechInsurance and over the last couple years we've been rebuilding the database, agency management system, and websites (www.techinsurance.com and www.businessinsurancenow.com). It's a massive undertaking. At this point it's almost done (we're so close).

My job is on the website end of things. Each website has its own dynamic insurance application with their own sets of questions. I say sets, because that's really what they are. The questions themselves are highly dynamic in nature so that it's rare that any one person will be asked the exact same set of questions as another. An engineer is going to be asked different questions than a custom programmer. Moreover, the questions also vary depending on the selections you make on an individual page. For example, answering "Yes" to one question may cause another required question to appear on a page. This is great for the user because they don't have to answer more questions than are necessary, but it's complicated for me.

So one of the daunting tasks for me was to scrap all of the existing questions and rewrite them. The previous incarnation of the site was written in ASP.NET 1.1, where the client side validation doesn't work in browsers other than IE. So that's just one thing we were looking to improve. The constant struggle I've always had was that I had to write lengthy Javascript to handle the expanding/collapsing controls while simultaneously turning on or off the validators accordingly. And all of this logic had to be written in my code-behind .NET code as well. This meant that to be thorough I absolutely had to test the forms in both IE and Firefox to ensure that only the visible questions were required in both the client side and server side validation. I mean, if a hidden control's validator is ever set to the "Enabled" state then that spells trouble. How can you fill out a field that's invisible? It's not easy. And this is a problem I'd run into more often than I'd like when dealing with applications of this level of complexity.

Enter Peter Blum

I thought that surely someone had a solution to simplify this process. And eventually I stumbled across a solution at www.peterblum.com. I had known about Peter's awesome validators for awhile. They're much more powerful than even the latest version of ASP.NET 4 validators. They allow custom formatting rules in the form of HTMLBefore and HTMLAfter around the error message you specify. You can specify extra controls to fire the validators other than the control it's validating. You can wire a validator to a label or other form element for better error visualization effects. I could go on and on.

But in addition to these validators he offers something in the suite that solves my problem, and solves it well. It's the MultiFieldStateController. The MultiFieldStateController offers a declarative way of handling the complex visibility conditions I had to deal with.

Peter Blum Controls in the Real World

Let's take the classic mailing address example. Often times the user doesn't need to enter their mailing address because it's the same as their physical address.

So if we have a question like this:

Is your mailing address the same as your physical address? <asp:RadioButtonList ID="rdoSameAddress" runat="server" RepeatDirection="Horizontal"> <asp:ListItem Value="True">Yes</asp:ListItem> <asp:ListItem Value="False">No</asp:ListItem> </asp:RadioButtonList>

Then we can handle the visibility condition like this:

<des:MultiFieldStateController ID="mfsc1" runat="server" ConditionTrue-Visible="true" ConditionFalse-Visible="false"> <ControlConnections> <des:FSAControlConnection ControlID="trMailingAddress" /> </ControlConnections> <ConditionContainer> <des:MultiCondition Operator="AND"> <Conditions> <des:RequiredListCondition ControlIDToEvaluate="rdoSameAddress" /> <des:CompareToValueCondition ControlIDToEvaluate="rdoSameAddress" ValueToCompare="False" /> </Conditions> </des:MultiCondition> </ConditionContainer> </des:MultiFieldStateController>

And then the mailing address and validator below might look like this:

<table width="100%"> <tr id="trMailingAddress" runat="server"> <th> <asp:Label ID="lblMailingAddress" runat="server" AssociatedControlID="txtMailingAddress">Address</asp:Label> </th> <td> <asp:TextBox id="txtMailingAddress" runat="server" width="275" MaxLength="100" /> <des:RequiredTextValidator ID="RequiredTextValidator6" runat="server" ControlIDToEvaluate="txtMailingAddress" ErrorMessage="This information is required" Label-LabelControlID="lblMailingAddress"> <ErrorFormatterContainer> <des:TextErrorFormatter Display="Dynamic" HTMLBefore="<br />" ImageURL="/images/quote/ErrorBullet.png"></des:TextErrorFormatter> </ErrorFormatterContainer> <EnablerContainer> <des:VisibleCondition ControlIDToEvaluate="trMailingAddress" IsVisible="true" /> </EnablerContainer> </des:RequiredTextValidator> </td> </tr> <!-- City, state, and zip fields go here --> </table>

And that's it. The mailing address will only appear when the answer to the above question is "False". And then whether RequiredTextValidator fires or not is dependent on the des:VisibleCondition. The beauty part is that this completely takes care of both the Javascript and server-side end of things. This is a relatively straightforward example, but you can also combine conditions and do some pretty powerful stuff.

With as much time and effort this has saved me, these features were easily enough to sell me on the product. Of course this is just a small aspect of what Peter's suite is capable of. And his support and documentation are legendary so I can recommend the suite without hesitation. If you're looking to simplify your life and avoid ASP.NET Web Form headaches then I'd seriously consider checking it out.