Coding with C#

More AJAX

Allen Guest — Thu, 22 Dec 2005 12:20:00 GMT

Looks like I am staying on my contract for another 6 months. While I am in the midst of finishing up my real projects, I am tasked with putting together an integration application with http://maps.google.com and City of Seattle address data. What is quite funny is that even though I am utilizing C# on the backend to perform my queries, the application is 80% javascript. Who would have thought we were be reverting back to the client so heavily?

Personally, I find .NET's mechanism of the full page postback to be quite archaic and it has always bothered me. Leveraging AJAX, my .NET server controls are nothing more than javascript renderers that communicate with the server for their data needs. I have to say that AJAX is a cleaner approach to client/server communication that the in the old days when we had to perform cross-frame postbacks to achieve similar effects.

Update: Look to http://web1.seattle.gov/dpd/GoogleDPD in the next few days for an Alpha version of some of the City of Seattle's permit and activity data linked with Google.

AJAX

Allen Guest — Fri, 02 Dec 2005 11:54:00 GMT

I recently had the opportunity to dabble in a concept project utilizing AJAX and have been quite impressed with the implementation of a free library found at http://www.schwarz-interactive.de/ for 1.1 or http://dotnet2.schwarz-interactive.de/ for 2.0.

Implementation is as easy as setting a reference to the library, adding an entry to your web.config and decorating the exposed methods. The decorated methods are exposed to your client side javascript. When those methods are called from Javascript, an HTTP get is performed and the parameters are serialized / deserialized and the original marked up method is invoked. Quite elegant.

In addition the library supports direct support for the majority of the .NET base classes, including the DataSet - as well as exposing an IAJAXObjectConverter interface where you can supply support for serialization of your own custom classes. This gives the ability of the client code to directly access the server side object as a client side object.

HttpHandlers : A Practical Example

Allen Guest — Tue, 01 Nov 2005 10:50:00 GMT

I recently had the need to tunnel a protected resource through a firewall and found a great practical use for HttpHandlers.

Click http://geekswithblogs.net/aguest/articles/58795.aspx to read walkthrough and complete code.

The interesting DropDownList ASP.NET control behavior

Allen Guest — Mon, 26 Sep 2005 18:00:00 GMT

So if you've decided to use syntax such as this

myDropDownListBox.Items[0].Selected = true;

ListItem foo = myDropDownListBox.Items.FindByValue(”foo”);
foo.Selected = true;

you will get the 'A DropDownList cannot have multiple items selected' error.

Seems to me that if the code sets the Selected attribute on an item in a list which by definition can only have one item selected, that the ListItem instance would set the SelectedIndex automatically for me. Seems like a no-brainer. I guess Microsoft found some sort of use for this error being thrown from a DropDownList control - just don't ask me what that could be.

I guess I'd rather see that the DropDownList have DropDownList items if the Selected property was pretty much useless and will only cause errors if used in a DropDownList.

Time for my yearly blog post

Allen Guest — Thu, 22 Sep 2005 15:54:00 GMT

Well its been a great year. I'm thinking of moving on from my current contract - been 4 years slogging on at the same area. Longest contract I've ever had - heck, longest job I've ever had.

Well, on to more interesting things - like code. We have developed a unified Framework here where I am contracting at to centralize (aka reuse) more commonly used areas of functionality, mostly data access. All data access has been abstracted into static method calls such as (note class names have been changed):

DataSet myData = Framework.Data.Enterprise.EmployeeGateway.GetAllEmployees();

or, if a Business Object wrapper was available, can be:

EmployeeCollection myEmployeeCollection = Framework.Data.Enterprise.BusinessObject.EmployeeGateway.GetAllEmployees();

An application that wants employee data simply calls one of the methods above. Simple, huh? Now, we wanted to deploy the application behind a firewall. We no longer had direct access to the database and all data requests had to know be funneled through web services. But who wanted to recode 398 stored procedures? Using a bit of reflection, I was able to potentially open up all of the static method calls so that an application running outside the firewall was able to make the same database call without knowing it was actually been funnelled through one (or more!) web services for its data. Code tidbit below:

public class EmployeeGateway
{
private EmployeeGateway() { }
public static DataSet GetAllEmployees()
{
    return ExecDataSetQuery(“GET_ALL_EMPLOYEES“, null);
}
private static DataSet ExecDataSetQuery(string sProc, SqlParameter[] parms)
{
    // Connection factory returns either a SqlConnection or a WebService instance
    // based on a Framework configuration file. Connection information for a given
    // data source was either an encrypted connection string or an encrypted web
    // service endpoint.
    object connection = ConnectionFactory.CreateConnection(DataSourceEnum.Employee);
    DataSet ds = null;
    if (connection.GetType().Equals(typeof(SqlConnection))
    {
      using (SqlConnection sqlConnection = connection as SqlConnection)
      {
        // standard SqlDataAdapter / Fill code here
      }
    }
    else if (connection.GetType().Equals(typeof(Framework.Web.Services.Enterprise.EmployeeGateway)))
    {
      using (Framework.Web.Services.Enterprise.EmployeeGateway webServiceConnection = connection as Framework.Web.Services.Enterprise.EmployeeGateway)
      {
        try
        {
          MethodInfo method = webServiceConnection.GetType().GetMethod(ExtractWebMethodName(sProc);
          if (null != method)
            ds = (DataSet)method.Invoke(webServiceConnection, Framework.Data.SqlController.ToObjectArray(parms));
          else
            throw new Framework.Data.DataException(String.Format(“Unable to locate Web Service name of {0} on the {1} connection.“, sProc, DataSourceEnum.Employee.ToString()));
        }
        catch (System.Exception ex)
        {
          // publish error to a central event log
          throw new Framework.Data.DataException(String.Format(“Failed to execute Web Service {0}.“, webServiceConnection.ToString()), ex);
        }
      }
    }
    else
      throw new Framework.Data.DataException(String.Format(“Unhandled connection request {0} returned from ConnectionFactory.“, connection.ToString());
}
}

The caveats of course is that the Web Service proxy names need to match the stored procedure names. Not a bad tradeoff if you don't have to write all the web service proxy instantiations in your code and get them for free. The bolded function names above are included below for completeness.

internal static string ExtractWebMethodName(string sProc)
{
string webMethodName = sProc;
int sProcSeperatorIndex = sProc.LastIndexOf(“.“);
if (sProcSeperatorIndex > -1)
    webMethodName = sProc.SubString(sProcSeperatorIndex+1, sProc.Length - sProcSeperatorIndex);
return webMethodName;
}

internal static Object[] ToObjectArray(SqlParameter[] parms)
{
int parmLength = 0;
if (null != parms)
{
    // figure out array length
    foreach (SqlParameter parm in parms)
    {
      if (parm.Direction != ParameterDirection.Output)
        parmLength++;
    }
}
int index = 0;
object[] args = new object[parmLength];
if (null != parms)
  {
    foreach (SqlParameter parm in parms)
    {
      if (parm.Direction != ParameterDirection.Output)
        args[index++] = parm.Value;
    }
}
return args;
}

Event problems with controls with no ViewState.

Allen Guest — Mon, 26 Apr 2004 16:57:00 GMT

DataGrid, ViewState and SelectedIndex

The ViewState of an ASP.NET page is a hidden field that the ASP.NET framework uses to maintain the state of a web page. When a user posts a page to the server, the server will restore the contents of the controls by parsing out the state and restoring the state in the Base64 encoded field.

If you've worked with the DataGrid you know it has a tendency to increase the contents of the ViewState field by quite a bit - sometimes in excess of 100KB! To combat this, a variety of methods are employed - from overriding the Page.SavePagetoPersistenceMedium and Page.LoadPageFromPersistenceMedium and serializing it to Session state to the most obvious - setting the EnableViewState property to false. Saving the view state to Session can have scalability issues, but for web sites with minimal traffic this may be an option. The better solution IMHO is to remove disable the ViewState for the DataGrid by setting the EnableViewState property to false.

A couple of additional issues rear their heads when you do this however. For starters, you must rebind your data to the Grid on every postback instead of the traditional (!isPostBack) check. You can cache this data yourself in the Page.Cache object to mitigate the database hit issue so that is no problem. As well, you will find out that the SelectedIndex property is now one post behind. This is due to the Page Life Cycle, whereby the SelectedIndexChanged event fires after the Load event. The SelectedIndex property is set correctly but it doesn't get set until after you bind. The solution is to rebind in the OnPreRender event instead.

By setting the EnableViewState to false on my pages, I've reduced the size of the Request and Response by over 60% with no loss of funtionality.

Javascript function naming from Server Controls

Allen Guest — Thu, 22 Apr 2004 17:24:00 GMT

Ever have client side code generated out of your User Controls? You aren't protected by INamingContainer in your Javascript functions - here's a simple approach to handle this issue.

http://geekswithblogs.net/aguest/articles/4213.aspx