April 2008 - Posts
At my day job, we're in the process of an enterprise re-write. The old stuff is a hodge-podge of Cold Fusion, Java, J# and C#. The website is Cold Fusion so the URLs often look something like this:
http://www.example.com/products/product_details/index.cfm?fuseaction=foo
The new site is ASP.NET. Naturally, the URLs will look somewhat like this:
http://www.example.com/products/details.aspx?item=foo
I'm sure that many of you have been involved in a scenario like this. The business wants to update the site. But we don't want to lose all the SEO ground we've gained over the years. So we have to support the legacy URLs.
There are different ways to tackle this problem: map the ".cfm" extension to be handled by ASP.NET using a custom IHttpHandler; or use an ISAPI filter; or use a third party URL Rewriter. In the end, most (if not all) of these methods rely on Regular Expressions.
Regular Expressions are powerful, but they can be confusing, and many developers avoid them. They're like the ultra-geeky kid in school. You don't really want to associate with him, but you'd love it if he was your lab partner, because you know he'd carry you through anything that you didn't understand.
The task to write the RegExes to match the Legacy URLs with the new URLs has fallen to me. And I'm actually happy about that. The best for me to learn anything is by doing it. So I get to sink my teeth into Regex and hopefully, I won't forget what I learned anytime soon.
And now, the good part - links:
I have recently been learning about the new MVC framework offered by friends at ASP.NET. One of the first questions I had about it was how does AJAX fit into this framework. So, I did a little digging. I found Nikhil Kothari's article on "Ajax with the ASP.NET MVC Framework," but that is not quite what I was looking for.
(Awhile back, I stumbled across Rob Bagby's webcasts on the ASP.NET AJAX client libraries wherein he details the benefits of getting your hands dirty with the JavaScript, instead of letting the UpdatePanel control write all the JavaScript for you. And he goes into detail on how to accomplish that task. He didn't need to do much convincing of me. I've long thought that while the UpdatePanel is very convenient (especially for those who loath JavaScript), it is probably somewhat bloated. In the end, I prefer Rob Bagby's way.)
I was looking for a method that fit within the MVC framework, but didn't deliver HTML from an AJAX call, but rather straight XML, or better yet JSON. I did some more searching and found that Aaron Lerch celebrated the new year with a post titled Unifying Web "Sites" and Web Services with the ASP.NET MVC Framework, wherein he describes how one could go about returning XML or JSON through the MVC framework by simply passing the data to a view and the view determining what form it should send back to the client. I downloaded his provided code only to find that it doesn't work with the latest version of the MVC framework. (Not that this is a big deal. I'm sure I could just study the new framework and re-write it.)
I also found this interesting post by Dan Finch in the forums. It is basically the same concept that Aaron proposed, only less code.
I don't know which is better yet. I'm just learning about this stuff. But I do like how these solutions deliver XML or JSON and they use the MVC framework to deliver it. I'll be keeping an eye out for more like this.
Utilities are among my favorites to code. Especially ones that are short and sweet and useful in many different situations. One of my favorites that I wrote was an Object Serializer.
Most examples of object serialization I have seen end up serializing an object to an XML file. That does have it's purpose. However, I've been in many situations where I'd like to serialize an object into XML and use the XML in code. Or I have XML in the form of a string which I need converted to an object.
The XmlSerializer is what we need. And if you look at the Serialize or Deserialize methods, you see that we have a lot of different options. We need some sort of Writer or Reader in order to do the conversion. Since I want to serialize to and deserialize from a string, the obvious choice was the StringWriter (to serialize) and the StringReader (to deserialize).
It is important to note that both the StringWriter and StringReader classes implement IDisposable and the documentation suggests that we should always dispose of our Reader/Writer when we're done with it. I'm a big fan of the "using" statement which automatically calls the Dispose() method when it leaves the using block.
I also decided to use generics so that I could have a strongly typed object going in and coming out.
So without further ado, here it is:
using System;
using System.Collections.Generic;
using System.IO;
using System.Text;
using System.Xml.Serialization;
namespace KevnRoberts.Utilities
{
/// <summary>
/// Used for serializing and deserializing objects
/// </summary>
/// <typeparam
name="T">The type of object to
de/serialize</typeparam>
public class Serializer<T>
{
/// <summary>
/// Converts the XML into an object
/// </summary>
/// <param
name="xml">The XML representation
of an object.</param>
/// <returns>An object of type T.</returns>
public static T Deserialize(string
xml)
{
//
convert to the serializable object
T item;
using
(StringReader reader = new StringReader(xml))
{
XmlSerializer
serializer = new XmlSerializer(typeof(T));
item =
(T)serializer.Deserialize(reader);
}
return
item;
}
/// <summary>
/// Converts an object into XML.
/// </summary>
/// <param
name="obj">The object to convert.</param>
/// <returns>The XML representation of the object.</returns>
public static string
Serialize(T obj)
{
StringBuilder
data = new StringBuilder();
using
(StringWriter writer = new StringWriter(data))
{
XmlSerializer
serializer = new XmlSerializer(typeof(T));
serializer.Serialize(writer,
obj);
}
return
data.ToString();
}
}
}
And here is an example of how you would use it:
string xml = @"<dateTime>2008-04-03T00:00:00</dateTime>";
DateTime deserializedDate = Serializer<DateTime>.Deserialize(xml);
DateTime date = new
DateTime(2008, 4, 3);
string serializedDate = Serializer<DateTime>.Serialize(date);
Of course, you'll want to use it to de/serialize something more complex than a date and time, but you get the point.
More Posts