Spaces, we don't want no stinking spaces

Dropdown List anomaly in asp.Net

For the first time in ages, I was stumped by what seemed like a trivial issue with formatting and a pesky ampersand.  The problem was that when users selected an item from a dropdown list that had a & character in it.  The result was a rather unfriendly validation error thrown by asp.Net.

Invalid postback or callback argument. Event validation is enabled using '<pages enableEventValidation=“true”/>'

Now there is a very easy solution to this, and it involves setting the <pages enableEventValidation=“false”/>', but this wasn't optimal as it would leave the page open to cross site scripting attacks.  I set about trying to HtmlEncode the postback value to escape the troublesome characters.  In hindsight this was never going to work, but it did lead me down another path.  After some googling to old blog posts and a few examples on stackoverflow (mainly revolving around Javascript) I thought I'd found the answer I was after.

protected override void Render(HtmlTextWriter writer)
{
    //register the items from the dropdownlist as possible postbackvalues for the listbox

    foreach (ListItem option in ddAssignedTo.Items)
    {
        Page.ClientScript.RegisterForEventValidation(ddAssignedTo.UniqueID, option.Value);
    }


    base.Render(writer);
}

This still didn't work, and I was about to admit defeat and just set the EventValidation to false.  I stepped through the code to check what values were being sent back to the page and I was quite shocked.  The Values being posted back didn't match the values in the dropdownlist.  It was a subtle difference but the Dropdownlist had removed additional spaces from the raw data.

At first I thought it was some funky javascript one of the front end guys had put into the code but it turns out this wasn't the case.  IE actually had an override on the Rendering of the Controls that removes this additional whitespace.  The trouble is, the Validation Values assigned to the controls happen after this has taken place.

Unfortunately I was unable to change the data in the database so I had to change my code to accommodate this feature of the web Rendering the page.  I had two options.  Strip the additional whitespace before assigning the value to the listitem in the dropdown box, or somehow force the dropdown to keep the additional spacing.  I opted for the latter and used the <Pre> tag  to ensure that all Text and Values in the Dropdown List were treated as strict values.

I am unsure if this affects other controls at the moment but I will run some simple tests when I get some downtime and append to this blog with my findings.

Engineering vs Product Release

For a long time it has bothered me that inferior products manage to top the charts of their prospective fields.  Maybe this was because the marketing department was better at the company with the inferior product,  or maybe it was that the marketing team sucked at the company that chose to invest in engineering.

Today I was reminded of what can go wrong when the engineering arm of a company invests too heavily in that field without looking at the overall picture of what is required for a good product roll-out.

A company was offering character recognition software for automating the entry of invoices into a system.  The premise is very simple, take some text on a scanned document and enter it into some fields that can then be exported to the customers database.  Everything about this product ticked all of the boxes except for one thing, the interface.  For some reason, someone within the IT department managed to convince everyone else that silverlight was the way to go.  There is nothing wrong with silverlight, don't get me wrong, provided silverlight is the best option to go with and no other tool can offer the functionality required.  Otherwise you are locking yourself into that particular vendor and restricting the platforms you can actually run the application on.  If the customer wants a web based system they can also view on their phone / tablet, silverlight really isn't going to do you any favours.

Functionality vs Complexity

So what drove this company to go with silverlight?  Maybe they thought it was right for their customer base at the time, or maybe the devs wanted something new to play with and thought they could bolster their CV with a bit of silverlight on it.  This is where the complexity comes in.  If you have a tool that you think aids development, ask yourself this question.  If you're going to be employing someone new into your company, does having experience in that product become a prerequisite to the job?  If the answer to that question is yes, then the tool isn't actually helpful.  Take resharper and SSMS Tools for instance.  Both great plugins for visual studio / SQL Server Management Studio.  However you wouldn't state that a developer had to have experience in using them before joining your team.  However if your company has decided to use an ORM layer like nHibernate or Entity framework, where do you go from there?  All you are doing is diluting the pool of applicants you might be able to source for the job.

Bad Product Release

On the other hand, there are times when a bad product release can undo all of the good work of the engineering team.  Not setting sensible values for defaults leaves people thinking your product is inferior.  80% of your user base is not going to take the time to wade through pages of options and configuration.  They are trusting that the Release team chose a sensible set of values that cater for the majority of their customers.

So what is the right level/trade off for all of this?  I honestly don't know, it depends on your user base and what they want.  The only way you're going to find this out is through market research.  So the emphasis is back on the marketing team again!  I hope that one day the user base will improve so they can make a choice based on engineering superiority rather than aesthetics.  If that happens, companies like Saab will still be in business.