Moving House

I've moved this blog over to WordPress. All the posts are also there, and those of you subscribed through feedburner shouldn't notice if I manage to get the transfer right.

My new address is http://seesharper.wordpress.com

When are there just too many generics?

Generics are a pretty cool language feature. They provide type safety and felxible reuse at the same time, and I reckon that's pretty cool. However as with all the other cool language features - like implicit typing, you need to be responsible with them. The question is though, when do you have too many generics?

One of the peices of code I wrote this week was a generic entity retrieval command. I already had a command signature that looked a little like this:

internal void MyCommand : Command <TRequest,TResponse>

No problems here. A request, a response.Now this was ok, but I couldn't really get an entity of any type like this. I tried putting the type in the request as a parameter, but it didn't really work. So then I moved to this..

internal void MyCommand<TEntityType> : Command <TRequest,TResponse>

Now I've got 3 generic parameters. 1 that specifies the type of entity I'm requesting, and 1 each for the request and response types. I might be getting a bit zesty with my generics. However this lets me go and get a table from my context like so:

Table<TEntityType> myQueryTable = myDataContext.GetTable<TEntityType>

Which is nice I think, as it lends itself to almost any table that you've got mapped in your data context.

Now, in case there weren't already enough generics in my class definition, I also needed to know what type I was returning in my response! So....

internal void MyCommand<TEntityType> : Command<TRequest,TResponse<TEntityType>>
So I really still only have 3 types here, but now I have the TEntityType on the response as well. Do I have too many generics? Am I creating a readability and maintainability issue here? I'm eagerly awaiting the code review on this one actually... I'm interested to see what is said.

What do you think? 1 too many? 2 too many? What the hell am I doing? Would you have done it differently?

ASP.Net View State

ASP.Net View State. The extent of my knowledge up until this week consisted of:

• It a base64 encoded string that exists in a hidden field in the page

There is apparently significantly more to this beast than that. I'm not going to re-hash it here, as there are some really good articles on it already. I highly recommend this article in particular. When combined with the MSDN ASP.Net Page Object help it gives an excellent picture of exactly where view state sits in the scheme of a web page, and it's intented use.

Lets go with an example of why you'd use it. I have a repeater control. In the repeater list, I have check boxes for the rows, so that the users can group items for actioning. I can group items, and all is well, until I attempt to sort the list. As soon as I post back, my checks are all lost! Why?

Well, the most likely cause is that I'm binding my data to the repeater in, or after the page load.

The issue here lies in when the view state is loaded into the state bag. If you take a look at the two articles I've referenced above you'll get a more in depth discussion of this, but the short answer is to move the loading and binding of data back into the init page method. What this does is ensures all the controls that the repeater creates (in my case - the check boxes) are all in the control tree before the view state is loaded.

The reason for the second one being an issue is that even though I'm now binding in the init method, is that I'm also rebinding after I do the sort. This causes the view state that I had before to no longer be applicable. The answer here? Some custom view state manipulation. In this example, what we can do is ensure that during the databinding, the check box for each row is given a meaningful id - I used the Id of the item I was binding to. Then, when the check box is checked, add an item to the view state using the id of the check box for the key (view state is a dictionary) and the check box checked value (true, false) as the value.

The next step is to put some code into the page that will retrieve this key/value pair and set the checked value when the page is posted back. The most important thing here to remember is that you should be calling this AFTER the init. Yep, after. The reason? Well, if the init is before the view state load, then it makes sense that if you're attempting to use something that should be in the view state to wait until after it's loaded right? :)

I personally put my custom state handling in the override of the ViewStateLoad method in the page. It's important to make sure you've made the call to the base method before you do your loading though - otherwise you're still before the view state load.... :)

So that's a quick bit of info on view state. If you're unsure at all of what view state is, and when it's loaded, what it's intended for and what you should and shouldn't use it for make sure you check out that first article. It really is a highly valuable read!

Why Blog?

Having recently asked myself this question I was very keen to have a read of this post over at Newly Corporate. I think they've made some excellent points - but I would expand on something they've touched on with point 2.

When they say it's a good way to practice project management I would say it's more than just a way to practice. I would say that a blog is a way to teach. Not in a condescending sense, but as a sharing exercise. Something I've picked up recently is that there are three key tenets to learning - discover, master, influence. Blogging is a significant part of mastering, and influencing in my opinion.

The reason being that in my opinion you don't truly know something until you can successfully teach it to somebody else. Once you have that ability you have mastered the subject. You can then influence peoples thinking by guiding them in their learning while teaching. This not only reinforces your subject matter knowledge but also drives your social interaction skills, which they also mention.

So why do you blog?

ASP.Net AJAX Auto Complete Control Extension

Today while working on adding tagging to items, I came across an issue with the auto complete control extender available in the ASP.Net AJAX Control library.

The problem is that you can't host the extender in a custom user control (ascx file) and make it call back to a Page Method to retrieve the auto complete list. The reason for this is that the PageMethod() function in the javascript that is used to drive this functionality only hooks into the page itself, not the hosted control.

I've got a quick and dirty workaround for this, which works for me in the short term but I'm going to work on refining. It goes a little something like this...

Set up your extender in your user control...


Configure your script manager to allow calls to page methods...


Add the following method to your page. It's important to make sure the signature matches exactly!


Then simply add the code you need to retrieve your item list to the method body. The hook will now catch the GetCompletionList method as it should and the extender will populate as normal.

Where to next? I'm currently investigating the possibility of using the StackFrame class to branch to different methods based on the caller to this method. There is potential then to have multiple auto complete extenders on the same page across various controls.

If you've done something similar - or have a better way to do this, leave a comment and let me know. I'm sure there's a better way out there... I just haven't got there yet :)

MaxLengthTextBox - AJAX Control Extender

If you're looking for an easy way to apply a max length to an ASP.Net multiline text field, I've written a control extender that is compatable with IE, and Firefox. It uses .Net 3.5, and you'll need to go here and grab the toolkit. Once you've done that, head here to grab the extender. Put a reference to the toolkit in your project, then reference the assembly I've provided.


Now all you should need to do is add the extender as per any normal extender. Set a max length for your text box, and you should be good to go!

If you've got any comments, suggestions, improvements or even ideas for other controls leave a message on the codeplex page, or here on the blog.

ASP.Net AJAX Extenders

As mentioned in my previous post it's been quite a while since I last had the fortune to work on a web application. Today I discovered another gotcha for young players in the web world when trying to set the MaxLength property of a TextBox control. Normally this works fine, but if you combine this with settinig the style to MultiLine the world changes.

What's going on here is that the TextBox control is rendered in 2 ways. Normally it's rendered as an input control, which allows the max length property to work as intended. However, in multiline mode it renders as a TextArea control, which doesn't implement the MaxLength property! No good for those of us attempting to limit our user input lengths...

So how to fix it? After spending some time playing with validation controls combined with update panels I decided it just wasn't going to happen unless I started writing some script. Now I normally shudder at the possibility of working with script, but I really have to say that it's been quite pleasent this time around.

I downloaded the ASP.Net AJAX control toolkit and took a look around to see how these extenders are put together. Basically they consist of a behaviour (client script), an extender (server side code), and a designer (to allow for use in the IDE). It seems that with the toolkit, most of the hard work wiring things together is done for you. All you really need to do is define any public properties you'd like to implement in your server side code, wire them up using the provided Get and Set methods from the toolkit then get to coding your behaviour in the script files.

For my particular problem there was already a number of solutions out there, on CodeProject and also on various blogs. I've ended up with a nice mesh of a few solutions that involves filtering the key down event to check the user input once the control reaches the max length then allows or denies the key press events to continue firing. It's not quite in the wild yet, but I'm hoping it will survive the rigours of beta use and prove a worthy addition to our internal toolset.

I'm also putting together an article on how I went about writing the extender for those interested. So if that's you - watch this space :)

References:
Multiline TextBox with MaxLength Validation
ASP.Net AJAX Control Toolkit
Keyboard restriction textbox with options and ñ
Detecting keystrokes