Posts

Showing posts with the label Will

The Dark Side of Extension Methods

Image
In my quest to find a suitable generic update method for a generic LINQ Data Access class I have found a decent amount of code and even more theories (sans code).  Some good, some verbose, and a lot bad.  It seems that Extension Methods are a fan favorite for just about everything nowadays and I wasn't suprised to see Extension Methods being used for LINQ to SQL updates. In reading about Extension Methods I have heard good and bad feedback.  The good usually involves the convenience of bypassing a utility class and the bad involving code readability / maintability.  Forgive me for I am the William Hung of LINQ as I have had no formal training in this arena, but IMHO Extension Methods are a pain-in-the-ass when ExtensionMethodA returns the result of ExtensionMethodB which depends on the output of ExtensionMethodC which ..... Here is an example of what I am talking about in pseudo-code: public static bool Update<T>( this T...

When a Codebase Sucks There's Always JavaScript

Image
In working on some inherited code in a very large and complex website I was a little bit skeptical of touching the code.  Let's just say the codebase was dubious at best.  This presented a problem as I had 3 days to make a lot of changes in the admin section of the site.  When inheriting code there is always a learning curve.  Unfortunately I didn't have this luxury as I spent 1.5 days getting the code running locally (still haven't COMPLETELY finished this).  This left me with about another half-day to learn the handful of tables I was to be using.  One day to actually write the code.  No problem.  So the client relayed to the PM what needed to be done which was ultimately relayed to me.  "When a manager selects a value from the whatever dropdownlist the values for the FileUpload control disappears and the user has to re-enter this value (which is by design as this would be a huuuuge security risk. Think if you could programmatically ...

Control.ClientID Extremely Useful for Creating Client-Side Functionality

Image
The ClientID property is my favorite property this week and will definitely reshape how I write asynchronous functionality in the future.  I learned about this while adding some functionality to a client's site earlier this week.  The original site was created off-shore and people like me are the ones who get to take care of it.  It's been fun so far and had I not been working on this site this week I would've totally overlooked this wonderful property. First off, ClientID is a readonly property (as it should be!) that does nothing more than get you the id of the control that is rendered.  Take the following rendered RequiredFieldValidator . <span id="datalistContent_ctl05_requiredDescription" style="color:Red;visibility:hidden;">I saw what you did there.</span>  Not quite the same as my original "requiredDescription" ID set in the .aspx.  When this control was processed this original ID was appended to the UniqueID created for...

Source Control Pet Peeves

Image
There is no reason, NONE WHATSOEVER , for updating SVN (or any other source code repository) with code that does not compile.  There are 2 rules for version control that are both #1: 1. Check code in frequently 1. Don't check projects in unless they compile Some argue that this isn't a good practice (1 #2 above) but let me explain.  Let's say you are working on a distributed team and there are 3 people working on a project.  Team members 1 & 2 are working on a class library for a web project.  They figure they are done for the day and check in the code that they worked on. Team member 3 (me) wants to check out this class library when working on a new & unrelated project. I add this library to my project, do my thing, build. WTF? 57 Errors and 2 warnings.  I should see 0 Errors and 2 warnings.  Warnings are usually harmless and a lot that I have seen lately stem from converting 1.x websites to 2.0, 3.5 projects and usually have...

Use T-SQL's NULLIF To Fix Divide By Zero Errors

Image
Lately I have doing a lot of SSRS and overall SQL work for a project.  In returning some data to process server-side my data retrieval method was returning null * which means that an exception was thrown. I did a little digging around and then decided to execute the stored procedure manually (i.e. Management Studio).  After debugging in Visual Studio and seeing what the values were and that they were in fact getting passed to the stored procedure I used the same signature to execute the proc in Management Studio.  Hmm, no dice.   My error message was of a "Divide-By-Zero" fashion.  This is the first time that I have ever seen this.  A little reading on the subject and I come to find out that the field used as the denominator allowed nulls. Enter NULLIF . This is what saved the day.  This function will compare two values and return a null value if the expressions are equal.  For example, take the following dummy stored procedure. CREATE...

Generic Session Wrapper Class for Session Object Maintenance

Image
I've been reading a couple of renditions of this SessionWrapper class via DotNetKicks over the past couple of days.  While I must admit that this code isn't 100% original, I can say that I have given it a more generic feel and added a little bit of functionality.  With my implementation you can not only use any class, you can specify a name for the session object.  That way if you want to store say the Account and Order objects in Session you could use the same method without creating a wrapper for each type. using System.Web; namespace NamespaceNameGoesHere {     public class Session <T> where T: class     {        private string _name = string .Empty;       public string Name       {           get { return _name; }           set { _name = va...

I Just Finished My First VB.NET Project in Over 2 Years

Image
I just finished my first VB.NET project and it was pretty interesting. Some of you might be wondering why I did a project in VB.NET.  There are actually 3 reasons: Client's money is still green Site was the first .NET application by someone straight out of classic ASP Client won't pay to upgrade to C# Now that we've cleared that up, I'd like to say how awkward it was.  First of all, it took me probably twice as long to write this as it would if it were in C#.  This is due to my not knowing the in's and out's of VB.NET 2.0 and not necessarily something I can blame on VB.  While there are some great additions to VB.NET such as Generics (even though the syntax isn't very intuitive), the  Using construct (about time!) there is one feature that is still not there that I use day-to-day when writing applications in C#. I am talking about collapsible regions within methods. Take the following code example: Protected Sub ButtonClick( ByVal sender As ...