May 2009 Entries
A common task is to take an array of strings or a List<string> and parse it to a comma separated value string for use in some sort of light weight media like a cookie or an url.
The way that this is usually done is to loop the array and concatenate the strings with a trailing comma “ , “ to then remove the last one.
Yesterday I was on my way in doing just this procedure when I thought that there’s got to be a better way to do this. After doing some research with our old friend Google I found a hidden gem in the String object in .NET. String.Join().
The name is somewhat misleading, at first glance it looks like it will just concatenate two strings, but no. This method takes an array of string and a separator string, it then uses the separator to create a CSV string with the separator as delimiter. The way I used it was like this
string categoryCsv = String.Join(",", IENumerable<T>.ToArray());
Some times you don’t need much to make your day, this definitely did, and it won’t be the last time I use it.
Here is a link to MSDN documentation http://msdn.microsoft.com/en-us/library/57a79xd0.aspx
Today I ran into a problem. I have a search web page that renders categorized search results within an UpdatePanel. Then I have a separate web control that has some Jquery script to hide and show the different categories. The control renders only the categories that have been chosen by the user. When a search is done both the search results and the category filter control are rendered asynchronous. To decouple the rendered links and elements from the JavaScript the script has a
$(document).ready(function()
that kicks of the script and puts the needed attributes in place.
The problem is that the $(document).ready function only kicks in when the page is posted or reloaded, and not when an async. postback is done by the UpdatePanel.
Then Joel had the answer, in the first function the code that has to run on every post needs to be wrapped wit a function that is called by the scripts generated by ASP.NET AJAX framework. the code looks like this.
$(document).ready(function() {
Sys.WebForms.PageRequestManager.getInstance().add_pageLoaded(pageLoadedHandler);
function pageLoadedHandler() {
Code to run on async postback...
}
});
In web development design is often the main force driving the project, then comes content, functionality followed by technology. Sure, the first thin the visitors see when they come to a web page is the design of the start page. In 3 seconds the visitor has judged the site by the look and feel of the site. The way the menu is composed, if the information they seek is one of the first things they see, and so on. The first page tells you much about what you can expect of the web site. But what happens after that? 
When working with small to midsized projects much effort is put on the design, the look and feel of the site. The start page is carefully put together, then the main pages are laid out. The designer delivers some pages containing the big picture. Of course the design is flawless, all pictures align, the articles are just the right length, tables are static and so on. And when you get the designs everything is just perfect, until you start coding. Questions start creeping upon you, first there is just a question like “how do I handle this content if the editor doesn’t provide the content”, in this case you could just not display the control, but then the design may break. Once you tackle that minor design bug you jump right to the next task, a data entry form. Again the designs is beautiful, without error messages or follow up screens, and yes here is when the next question you already knew would come “what should happen if there is an error when posting this form”.
I suppose you already guessed where I’m going. More often than not, designs (and also requirements) are like Swiss cheese, nice and round on the outside but filled with holes when you cut them open. They lack all those things that must be in place for the user to have a good experience and interaction with the site. So there you sit, in front of your screen, having to make a on the fly design decision, one of those things programmers shouldn’t be allowed to do.
So how do we get through this? There are several ways to tackle this dilemma, the best would be to educate the designers so that they also take interaction design in consideration when creating the UI. But that is a longer path to take. A quicker one is to have a dedicated and experienced interaction architect. A person that thinks in personas, flows and creates wireframes for others to follow.
The role of the interaction architect is far underestimated, they not only facilitate the work of the designer by giving them a rough canvas to get started from, but they also fill all those holes in the cheese. And when those interaction gaps are filled the work for us programmers get so much easier, not just because all those questions get answered but because we don’t have to do the work of someone else that, let’s face it, that someone else, would do so much better.
In web development design is often the main force driving the project, then comes content, functionality followed by technology. Sure, the first thin the visitors see when they come to a web page is the design of the start page. In 3 seconds the visitor has judged the site by the look and feel of the site. The way the menu is composed, if the information they seek is one of the first things they see, and so on. The first page tells you much about what you can expect of the web site. But what happens after that? 
When working with small to midsized projects much effort is put on the design, the look and feel of the site. The start page is carefully put together, then the main pages are laid out. The designer delivers some pages containing the big picture. Of course the design is flawless, all pictures align, the articles are just the right length, tables are static and so on. And when you get the designs everything is just perfect, until you start coding. Questions start creeping upon you, first there is just a question like “how do I handle this content if the editor doesn’t provide the content”, in this case you could just not display the control, but then the design may break. Once you tackle that minor design bug you jump right to the next task, a data entry form. Again the designs is beautiful, without error messages or follow up screens, and yes here is when the next question you already knew would come “what should happen if there is an error when posting this form”.
I suppose you already guessed where I’m going. More often than not, designs (and also requirements) are like Swiss cheese, nice and round on the outside but filled with holes when you cut them open. They lack all those things that must be in place for the user to have a good experience and interaction with the site. So there you sit, in front of your screen, having to make a on the fly design decision, one of those things programmers shouldn’t be allowed to do.
So how do we get through this? There are several ways to tackle this dilemma, the best would be to educate the designers so that they also take interaction design in consideration when creating the UI. But that is a longer path to take. A quicker one is to have a dedicated and experienced interaction architect. A person that thinks in personas, flows and creates wireframes for others to follow.
The role of the interaction architect is far underestimated, they not only facilitate the work of the designer by giving them a rough canvas to get started from, but they also fill all those holes in the cheese. And when those interaction gaps are filled the work for us programmers get so much easier, not just because all those questions get answered but because we don’t have to do the work of someone else that, let’s face it, that someone else, would do so much better.