Hey There, Mr. 50,000 Properties Guy

One of the benefits that we as SharePoint developers, and as general ASP.NET 2.0 developers, gain when doing composite control development (WebPart development) is the ability to exploit WebPart properties to authorized end users. This is indeed a portion of the development framework that is very, very nice, as we empower our end users with a certain level of responsibility to take the back-end plumbing that we develop, tailor it, and extend it out into many different circumstances and scenarios. Not only do they get to feel important because they get to customize our deliverables so we look like we did smart stuff, but it takes some of the load off us because we don’t have to revisit code for minor adjustments, and it forces them to learn a little something about how the SharePoint presentation layer functions which always helps.

I was doing a code review this past week (I do a lot of these) for a fairly large shipping company, which had in-house developed several “shipping label” control WebParts, basically, it was meant for shipping label tracking, pooling this data, and massaging it into sister business systems for a variety of business process activity. The code itself, I thought, was solid (minus the fact that it was missing null reference exception checks on arguments, and some other null reference shortcoming, I am stickler for that kind of crap). Of course, with a second eye, you always pick up small things that a lot of times get deemed unnecessary during a time crunch, like moving helper methods to static classes, some exception handling improvements, etc. etc. etc.

One of the WebParts I studied was meant to just display these shipping labels using a very generic consumer / provider architecture. It basically consisted of a fed list with shipping label names, upon the user clicking the label title within the fed list, the subsequent corresponding TIF image of the label would be brought up in the corresponding sister webpart. The code for it was in itself quite simplistic and served its purpose well.

And I kid you not, one of the WebParts, all by its lonesome, had 58 properties. 58 properties! Do you know how frickin long it takes to scroll through 58 properties when there is no regions in the code file. Its not short. I need band-aids for my trigger finger now, and I think I have a mild case of Carpal Tunnel Syndrome. Not only that, but the categories themselves that the properties were subscribing to were daunting. There were 18 of them. We do the math, and there is not a lot of properties that are provisioned per category. For an incredibly complex control, maybe for something like solving world hunger or curing cancer, I could understand this amount of properties (albeit, I wouldn’t agree with that type of categorization). Maybe for commercial software that places a high level of emphasis on being able to control the display output, I can buy this level being tangiable too.

Now I am all for properties, empowering end users, and maintaining a high level of re-usability without having to revisit the code. Don’t get me wrong. But damn. 58 properties?!?! For an in-house composite control? That is instantiated in ONE location? That is out of control.

Now, I don’t really have any “standards” per se that I adhere to when developing control-specific properties. But these are something that I CONSIDER when I am doing development. This doesn’t mean that I am right, and I don’t develop commercial software, so it probably would be completely different if that was the case.

1) Group your WebPart properties by PURPOSE. Don’t group 10 properties under “Miscellaneous”. That makes you a bad person. As an example, if you are exposing CSS properties through your properties, group them all under “Styles” Or “Customize Interface”. Just so it doesn’t take wading through, and expanding out 50 panes to change the text of something.

2) If you have more than 5 properties that are going to take up space (not something like a checkbox type), then put it in a group (this is of course relative).

3) If you are instantiating a WebPart in one location, don’t put the fricking root site textbox on there. Just put it in your put your instantiation in an initialize method. There is no point to that. It is going to be set once, what the hell is the point of that.

4) MAKE YOUR PROPERTY SITE REFERENCES RELATIVE. If you are asking for a root site, don’t require the absolute URL. That also makes you a bad person. (like one large WebPart company, whose name rhymes with torasterks [say it outloud it will make sense], you suck.)
5) Don’t expose your CSS properties to users if you are instantiating your WebPart in one location, like for a large application. As an example, if I am building a personnel manager WebPart, that is going to be used once (and not re-sold to other companies) then why would you do that, just control it yourself in code. It’s bloat, and will never be used. It makes scrolling through the code unbelievably difficult. And what kind of company has people in HR that can even fathom what CSS stands for. Be realistic. Furthermore, if you MUST do this, be sure to check the CSS property string for null values and set defaults. By this I mean:

You will have some public string that equates to the CSS value:

  1. private string _myCSSClass;

In your constructor initialize it to a empty string value (you could use string.Empty or whatever)

  1. #region Ctors
  2. public testing()
  3. {
  4.  
  5. _myCSSClass = "";
  6.  
  7. }
  8.  
  9. #endregion

Then you have your get / set accessors, we all know this, but the important part is to make sure you check if it is empty, and if it is, set it to a default value:

  1. if (_myCSSClass.Equals(string.Empty))
  2. {
  3. class = "blahblahblah";
  4. }
  5. else
  6. {
  7. class = _CSSClass;
  8. }

You get the idea.

6) Unless you are making interface heavy commercial software, not every single string has to have a mutable property on it. Like if in your WebPart you have a button wired to an event handler that is going to submit data, you really don’t have to bother making that text manipulatable. The user most likely is not going to change the text from “submit” to “seriously, I want to submit”. It is most likely OK to just initialize the button text property as “submit”. In any respect, this can most likely keep you out of trouble as well with sneaky users that want to be funny and change your text to belligerent words that might offend other users.

I am sure that there are others, but this was just written on a whim with things that I really got to me today with a WebPart I was reviewing, feel free to add more in the comments. Complaining can be fun :).

share save 171 16 Hey There, Mr. 50,000 Properties Guy

No Comments

Trackbacks/Pingbacks

  1. Arb Cruncher. | 7Wins.eu - [...] Arb Cruncher. Description The Revolutionary Sports Betting Calculator For Successful Arbitrage Betting, Dutching And Trading On …

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>