Accessing Cookie with Javascript

The document.cookie Property is available in DOM for accessing cookie values in javascript. This Property returns all of the cookies in a long semicolon separated string. For example:

cookie1=value1; cookie2=value2; cookie3=value3; ...

There is no way of accessing individual cookie values like we access Request variables on the server side. You must extract the required cookie value from one long string. It can be easily done with a few lines of code, but if you like the way things work on the server side, here is a small helper Javascript function I wrote to prepare a dictionary with all cookie values. Now instead of trying to extract value from a long string, you can use the following code:

var cookies = getCookies();
var value1 = cookies["cookieName"];
//Now value1 holds the value of cookie "cookieName"

Makes things easier especially when multiple cookies are in use. Here is the helper function that prepares a dictionary with all available cookies and values:

    
    function getCookies()
    {
        var cks = new Object();
        var ckList = document.cookie.split("; ");
        for (var i=0; i < ckList.length; i++)
        {
            var ck = ckList[i].split("=");
            cks[ck[0]] = unescape(ck[1]);
        }
        return cks;
    }

This code has been used in several places without any problems. If you encounter any issue, please post a comment.

C# RSS Feed Fetcher - Display RSS Feed with 2 lines of Code

There is a new set of classes under the System.ServiceModel.Syndication Namespace. These classes are designed to work with RSS and ATOM Feeds, whether you want to generate or consume Feeds in ASP.NET or WinForms applications.

However, if you are looking to simply fetch and display RSS feed from any source, it can be done with just two lines of Code. This uses Linq, so ASP.NET 3.5+ is needed for it to work.

     //www.haiders.net | Jan 2010
     //C# Example: Fetch and Shape RSS Feed
     string rssUri = "http://some.feed.uri.xml";
     var doc = System.Xml.Linq.XDocument.Load(rssUri);
     var rssFeed = from el in doc.Elements("rss").Elements("channel").Elements("item")
                   select new { Title = el.Element("title").Value, Link = el.Element("link").Value,
                   Description = el.Element("description").Value };
     //The data is ready, assuming we have a ListView to display the Feed named lvFeed
     //Lets bind the Feed to the ListView
     lvFeed.DataSource = rssFeed;
     lvFeed.DataBind();
     //Thats all!

In order to display the Feed on an ASP.NET Page, you may use a ListView Control with a simple Template:

The sample ListView here only displays a list of Post Titles with Links, but you can modify it to show the Description and other attributes available in the Feed.

You can see a live example of this on the Home Page of www.dojolocator.com, look at the "What's New?" section on the right panel. Another Page showing the Same RSS Feed in detail: www.dojolocator.com/news/

How to Avoid the Eval Method for better DataBinding

Since ASP.NET 2.0, the Eval method replaced DataBinder.Eval and the syntax has become cleaner. But Eval, which is now available as a method on TemplateControl, is not really any better in terms of performance. Internally, Eval calls DataBinder.Eval and Page.GetDataItem() instead of Container.DataItem to get exactly the same result as before. There are two major issues with it: use of reflection (similar to Late Bound objects in Visual Basic), and the sytax still remains long and unpleasant, specially in complex binding situations.

If we had a strongly typed DataItem property to work with, we could avoid Eval or Reflection once for all. So instead of doing <%#Eval("FirstName")%> we would do <%#DataItem.FirstName%> and Visual Studio intellisense will make it even easier.

It is actually possible to achieve this by casting Container.DataItem to the actual type, like:

 <%#=(Container.DataItem as MyNameSpace.Customer).FirstName%>

But if you have to do a lot those, it is not much fun. 

Here is a better solution:

Add a protected Property on the Page with the Type of your DataItem, like this:

protected Mynamespace.Customer DataItem
{ 
    get
    {
        return Page.GetDataItem() as Mynamespace.Customer;
    }
}

Now, your data binding expressions can use the strongly typed DataItem and all its Properties. Better yet, you can also work with its Public Fields and Methods, something the Eval or DataBinding.Eval can not do. So now the Data Binding expression would look like:

<%#DataItem.FirstName%>

Thanks to the Page.GetDataItem() method, it is possible to get a reference to the current DataItem of the Data Binding Context from anywhere in the Page.

If you have multiple DataControls binding to collections of different Types, one strongly typed DataItem property won't  work in both DataBound Controls. In that case, simply create two properties with names like "CurrentCustomer", "CurrentProduct" etc. and use them in the right context.

Google Maps API now includes driving directions

It is possible to show interactive driving directions on your Website with very minimal effort. Google Maps now includes the driving directions API, and you could embed driving directions and maps on your Website for free.

Like all other GoogleMaps feature, you are required to obtain an API key, which is free too.

We have integrated this into our Driving Directions at houselocator.com, here is an example:

http://www.houselocator.com/DrivingDirections.aspx?ID=15274&Street=&Zip=34741 

One advantage of Javascript API integration is, as Google keeps adding more features, they will automatically appear on your Website. Right now, they have a nice way of zooming into any turn on the directions. Just click on a step in the directions in the example above and see it in action.

Check out the Google Maps API at:  http://www.google.com/apis/maps/

Integration is really easy. 

** Update: I have written a GoogleMaps Directions API wrapper control for ASP.NET that you can use to easily integrate driving directions in your ASP.NET projects. Check the following post:

GoogleMaps-Driving-Directions-API-Wrapper-Control-for-ASPNET

Rendering Client Script in ASP.NET 2.0 : Behavior changes

In ASP.NET 2.0, all client script rendering functions are grouped under the ClientScriptManager class, which is availabe through Page.ClientScript property. The older script related methods on the Page class (RegisterClientScript, RegisterStartupScript etc.) are still available, but deprecated. In addition, most Script related methods now require an additional paramater: Type or Control. This helps isolate scripts generated by different types of WebControls, and would be more useful to Control developers.

There are also changes in how the script are rendered. For example, the startup script is now rendered right before the FORM (runat='server') is closed, not before the closing of the BODY element. If your Form element is wrapping everything else in the Body element, its not a problem, but if your Form is nested within other elements (within some DIV elements, for example) it may result in unexpected behavior. For example, the DOM structure may not be ready when the Startup script is executed.

Similarly, RegisterClientScript method adds scripts in the beginning of the FORM element, rather than top of the Body. And here is the biggest problem:

No FORM, No Client Script!

Thats right, if there is no Form with runat='server' on your page, these ClientScript methods will not render any script. You won't get any error message, but no script will be rendered on the Page. ASP.NET 2.0 expects that every Web page includes a server side FORM element.

To most developers used to the ways of ASP.NET, this may not be a problem. However, for Control developers, this may be a potential problem. If your Controls depend heavily on Client scripts, be aware of this behavior and possibility of ASP.NET pages not including a server side Form tag. 

It may be a good idea to include a server side Form tag on  every ASP.NET page, just to make sure all containing Controls, specially third party Controls  would function as expected.