April 2008 Entries

This week, we had our first deployment of the product I have been working on for the last several weeks.  The deployment is to the customer's test environment and it is not a fully functional product.  However, the features delivered are complete. 

The user are very excited.  In fact, they immediately started testing the data in parallel against their prior system (Access and Excel).  We received an email yesterday, stating that the data looks great and the tone of the email was very positive.

Personally, I was very anxious about this release, not because of the quality of the product, but because this is the first dealings this customer has had with me.  I started at my new company at the beginning of the year and at which time a lot of my ideas were not necessarily in line with the customer's.  We found some common ground and now they have shown more faith in me.  Previously they were very skeptical of my Agile speak and wanted nothing to do with it.  Though we could not put in place many of the Agile practices (like an in-house user), we were able to apply others behind the scenes that I feel have made this release successful.

Now it is a matter of not letting my head get too big and staying the course!

I guess it's about time I've posted again.  I've been very busy.  Just coming up for air for a bit.

I've been mixing some CSS design patterns with Server Controls recently. 

Aside: A nice book about CSS design patterns is Pro CSS and HTML Design Patterns.  It is very helpful in understanding how the boxing models work and it provides a lot of practical examples.

Anyway, copy-paste reuse easily gets out of hand on a web project.  It's not always easy to refactor HTML.  Anyway, I have many pages that use the "rollup" (collapsible) pattern in the HTML.  The pattern involves a few elements and I found myself copying those elements over and over.  Eventually, I said, enough is enough.  I took the pattern and wrapped it in a server control that renders all of the html elements for me.  Then on my pages, I just have to set a few properties and add my content and I am done.  Taking this approach on a couple of other HTML patterns has helped me reduce the nesting levels in my pages easily by half.

I plan to write an article about my experience with this.  I am fairly new to component writing, so it took me a while to get everything working right (including the custom designer).  In fact, I am still struggling with an interesting "bug" that adds no-break-space ( ) to my content inside my control?  This only happens in design mode, so, I must have done something wrong.

Anyhow, whether I figure out the designer mode issue or not, I will write up my path to semi-enlightenment.  It will just have to wait until after this cloud (initial client deployment) looming over my head let's some light through.

I've have been pretty quiet lately.  Actually, I've been quite busy and it turns out that there isn't much new to share.  However, this is one thing that comes to mind.

A recurring pattern in my UI is selection criteria that can applied to a GridView.  It turns out that frequently the same criteria applies to various screens.  I use LinqDataSources to bind to DropDownLists for many of the criteria.

It is not uncommon to use one controller for every page.  Following this approach, I ended up with the same data being published by multiple controllers.  I started considering ways to reduce or eliminate the duplication between the controllers.  I had two major considerations (at first): inheritance and splitting out a new controller to be consumed by the UI.

Inheritance can be a useful tool, but it can be overused as well.  I knew I could easily reduce the duplication with a base controller class, but this design didn't sit well with me.  The base class would be providing data, not behavior.

I then turned to the idea of introducing a stand-alone controller just for selection criteria.  In this case, the UI would reference two controllers, one for the criteria and one for the rest of the page.  It is not uncommon to have two or more controllers driving one page.  I liked this idea, then I realized something.  The new controller didn't look like a controller at all.

The new criteria controller didn't control anything.  It simply passed data from the data context to the UI, nothing more.  In fact, there was no need for a "view" in the traditional sense.  This might sound strange, but the driving force behind all of this is the LinqDataSource.  Using the LinqDataSource is completely different than the traditional DataSource/DataBind combination.  With the LinqDataSource, you simply configure the control and it retrieves the data on its own.   Push versus pull.

So, when using a LinqDataSource, my UI was pulling data from the controller, as opposed to the controller pushing data to the view via an interface.  The LinqDataSource does not lend itself to the MVC pattern.  Nor do ObjectDataSource and SqlDataSource for that matter.

What I finally decided on was allowing my view / page to access the data context directly.  I simply exposed a couple of read only properties that represent collections of entity objects that the UI needs for the selection criteria.

The conclusion?  The MVC pattern is great.  However, sometimes it isn't worth all of the extra lines of code.  Don't put blinders on and think that everything related to the UI has to fit into the MVC pattern.
Simple questions to ask yourself... Am I over complicating this?  What is the simplest thing that works?