"Although I feel perfectly comfortable in a set-based world writing SQL, it has traditionally been one of my least favorite areas of coding. Besides being relatively repetitive and tedious, at least when it comes to basic CRUD operations, sprocs are much more difficult to handle when it comes to source control, versioning, debugging, and unit testing."

and

"Regardless of the approach taken, I definitely no longer believe that sprocs should play any significant role in any application."

I couldn't agree more!  Read the full article: http://www.caffeinatedcoder.com/just-say-no-to-manual-crud/

 

Barry

When you add a WMS:Lister control to the actual article template (e.g. a "News Detail" template) the lister may break.  This is because the "ItemIdentifier" attribute is repeated twice on the page!

For example: Say you have an article page that uses <!-- item --> to identify the region of the page the PatternFile refers to, if you then add an actual lister control to the page you end up with two <!-- item --> comments (see below). Once in teh new lister and once for the article!

  <ez:Lister ID="scrollingNews" runat="server" PageSize="4" 
     SortBy="Date" SortDirection="Desc" PatternFile="~/NewsPattern.txt" ItemFileExtension="*.aspx" 
     ItemDirectory="~/News" PagerStyle="None" ItemIdentifier="<!-- item -->"
     CreateCacheIndex="true" FilterKey="Section" FilterValue="">
     <HeaderTemplate><span id="news_listing"></HeaderTemplate>
     <ItemTemplate>
       <a href="<%# ((ListerItem)Container.DataItem).Link %>">
        <wg:PlainText MaxLength="80" Text='<%# ((ListerItem)Container.DataItem).GetValue("text") %>' runat="server" />...
       </a>
     </ItemTemplate>
    <FooterTemplate></span></FooterTemplate>
  </ez:Lister>

The fix is simply to leave the ItemIdentifier attribute out of any Lister control.  The default value is <!-- item -->, so you only need the attribute if you need a different value.

:)

Amusingly written article on IE8 & web standards:
http://www.joelonsoftware.com/items/2008/03/17.html

 

Simple summary of Dependency Injection:
http://garyshortor.web140.discountasp.net/blog/archive/2008/02/01/inversion-of-control-pattern.aspx

Having trouble with your javascript?

Try here:
http://www.jslint.com/

While there is not much by way of documentation (by google standards!) on nhibernates caching, as it is a port of Hibernate (Java) the cahcing system seems to be the same.

Here is a good all round article on undersanding what hibernate (and therefore nhibernate) caching is and what it does.
http://www.javalobby.org/java/forums/t48846.html

UPDATE: 24/01/2008
Here is the nhibernate help on caching:

http://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/caches.html

In the future by changing the provider form SysCache to SysCache2 - SQL Notifications can be used to ensure that the cache (or a particular cache region) is cleared on changes to particular tables. 

A good article on implementing singleton classes - the wrong and right ways to do it:
http://www.yoda.arachsys.com/csharp/singleton.html

I am sure we may have seen this before but I came across it again and thought we should revisit some of these things:

The Most Useful .NET Utility Classes Developers Tend To Reinvent Rather Than Reuse

Richard

So I was attempting to find a bug in the following code (which was part of a for loop):

Label startLabel = new Label();
startLabel.Text = "<div class=" + ((counter % 2 == 0) ? columnTwo : columnOne) + "><h2><label for=\"" +
thisType.Name + "List\">" + thisType.FriendlyName + ":</label></h2>";
if (counter % 2 != 0) this.Dynamic.Controls.Add(new LiteralControl("<div class=\"searchContainer\">"));
this.Dynamic.Controls.Add(startLabel);
this.Dynamic.Controls.Add(sample);
Label endLabel = new Label();
endLabel.Text = "</div>";
this.Dynamic.Controls.Add(endLabel);
if ((counter % 2 == 0) || (counter % 2 != 0 && (counter - 1) == TypesInGroup.Count)) this.Dynamic.Controls.Add(new LiteralControl("</div>"));
counter++;

I found this really confusing and couldn't work out what was causing the bug. So I did some refactoring and tried to tidy it up a bit, in the process I found a couple of redundancies and two bugs! Below is the refactored code; notice that the main differences are formatting, variable names and simplifying the string concat by using String.Format.

string startHtml = "<div class=\"col1\"><h2><label for=\"{0}List\">{1}:</label></h2>";
LiteralControl startLabel = new LiteralControl(String.Format(startHtml, thisType.Name, thisType.FriendlyName));
LiteralControl endLabel = new LiteralControl("</div>");

bool isAlternateRow = (counter % 2 == 0);
if (!isAlternateRow)
this.Dynamic.Controls.Add(new LiteralControl("<div class=\"searchContainer\">"));

this.Dynamic.Controls.Add(startLabel);
this.Dynamic.Controls.Add(checkBoxList);
this.Dynamic.Controls.Add(endLabel);

bool isLast = (counter == this.SearchTypesList.Count);
if (isAlternateRow || isLast)
this.Dynamic.Controls.Add(new LiteralControl("</div>"));

counter++;

I find the second infinitely more readable! Lesson learned (again): the main aim of writing code is not to get it working (anyone can do that) but to make it easy to read for the next guy!

Barry

Handy trick for controls used on a lot of pages:

http://weblogs.asp.net/scottgu/archive/2006/11/26/tip-trick-how-to-register-user-controls-and-custom-controls-in-web-config.aspx

this has taken me a lttle while to work out today so this might save time for you guys....

The most likely use of precision sql data types is in the use of "Money".... This is not a valid .Net/C# datatype but maps to a "Decimal(19,4)".  Use the Decimal as the property datatype for moeny fields because it iis more precise, this can then be mapped using the following in NHibernate:

 

<property name="[Property Name]" type="Decimal(19,4)">

      <column name="[Column Name]" sql-type="Money" />

</property>

Avoid use of Console.WriteLine in Nunit tests.  Instead debug the test with breakpoints to get runtime values.

Debug.Write can be used in TestSetup and TestFixtureSetUp to help trace errors (as nunit catches exceptions in these methods and it my not be easy to debug).

If Console.WriteLine or Debug.Write (or similar) is used in Nunit tests then they should only fire when an exception occurs or a test fails (this is to simplify the command line and cruise control build outputs) OR to provide helpful info on teh status of the test (eg database script being run) NOT to help with debugging.

Thanks,
Barry