January 2008 - Posts

• The Battle for Nothing... or is it Null?

  I have worked in numerous programming languages and the one thing that I find most irritating is that every language feels the need to reinvent Nothing - literally - and then applies their own rules to it. In VB, Nothing is Nothing.  In C# and JavaScript, Nothing is null.  Ruby's Nothing is nil.  Nothing can also be Null or Empty or undefined, although it can sometimes be NaN, which is not necessarily Empty or Null.  Something that is undefined is sometimes null and sometimes not but something that is null is rarely undefined. Throw in the mix how badly empty strings are handled where "" is not Empty or null, but is an EmptyString and could be NaN.  It could also be a NullString, which is still not a null or even a Null and certainly not an Empty or undefined. Nothing/Null/null/nul/nil is a basic part of any programming language.  Is there any chance that we could pick one term, like Null (or null even), and use it across languages? It's just a word, what is the big deal?  The word itself is trivial but the need to use a new term for something so basic is the root of my aggravation.  Each language feels that they have to use their own terms to be "cool", yet are just rebranding well established concepts without adding functionality.  That isn't innovation, that's marketing.  It's "New and Improved" without being either. All it accomplishes is that it adds one more tiny step in the learning curve for that language and slows adoption.  Further, assuming that the "cool" factor won out in other areas, then there will be hundreds of other such tiny steps as well, all without any added benefit. Tell you what, I'm going to create my own programming language called Presidents.Net, where all of my core data types are named after past Presidents. private Jefferson ProcessRequest(Washington pRefID, Jackson pAmount) {    Lincoln User = getUserID(pRefID);    Eisenhower AccountNumber = getAccount(User);    ...    return applyTransaction(AccountNumber, pAmount); } What is the value added?  Nil, or ... null ... or ... Polk. Posted Jan 31 2008, 09:33 PM by DavidWise with 2 comment(s) Filed under: Development

• The Value of an IT Curmudgeon

  They have stories from the dawn of computing, about the problems with tape backup, data layouts using bitmasking to save single bytes wherever possible and can regale you with tales of horror about the era of punchcards.  While they can expound for hours on middling details of tech found only in museums, they are surprisingly quiet on the merits of any recent technologies.  One could say that their value is historical but I think they serve a far greater purpose. They are warning posts, put in place to remind you about the perils of complacency.  About what will happen to you if you let your skills lapse or get too comfortable with any one particular technology.  This field moves too fast and they are glimpses into your own future if you stop moving with it. Talk with them.  Listen to them.  Consider them the career equivalent of a car wreck.  They hit the brick wall so you don't have to. Posted Jan 23 2008, 11:27 AM by DavidWise with no comments Filed under: General

• Accessing SharePoint List Data as XML

  The other day, I found myself in need of a way to access SharePoint list data as XML but the only method available to me was a simple http GET.  This is not too bad, but what can I get from SharePoint via GET?  RSS is too limited and scraping the page is too painful and error-prone to even contemplate.  It turns out that there is an option available in 2007 that was carried forward from SharePoint 2003 / FrontPage days: owssvr.dll.  But this isn't some forgotten FrontPage artifact, it is still a central part of SharePoint.  In fact, if you pull up a list view and then view the source looking for owssvr.dll, you will see that this is the mechanism behind both the Export to Spreadsheet and Open with Access options on the list Actions menu. How It Works Simply put together a URL like this: http://MyServer/[site]/_vti_bin/owssvr.dll?Cmd=Display&List={listGuid}&XMLDATA=TRUE This will only return the fields that are defined on the default view of the list.  If you need specific fields then you need to create a view with those fields and pass the View ID as well, like this: http://.../owssvr.dll?Cmd=Display&List={listGuid}&view={viewGuid}&XMLDATA=TRUE Specifying Fields to be Returned There is also a Query parameter that lets you specify which fields are to be included in the resulting XML, regardless of how the view is defined.  For example, if you wanted just to bring back the Title and Status Fields, you would add the field names separated by spaces (URL Encoded, of course) like "&Query=Title%20Status".  If you want to return all fields, use an asterisk (*) instead of field names. http://.../owssvr.dll?Cmd=Display&List={listGuid}&query=Title%20Status&XMLDATA=TRUE Filtering Data Regardless of whether you pass a view or use the default it will still use the filter defined by that view.  Not bad, but you can trim this data even more by including a filter of your own using the FilterFieldn and FilterValuen arguments in the querystring.  These are the same values that are passed when you use the filter options in the column headers of a view which makes it pretty easy to track down exactly what needs to be passed.  Simply pull up the view that is your starting point and use the column filters to create your desired filter.  Once you have it, grab all of the FilterField and FilterValue items from the querystring and add them on to yours. http://.../owssvr.dll?Cmd=Display&List={listGuid}&query=Title%20Status&XMLDATA=TRUE&FilterField1=Status&FilterValue1=In%20Progress For a full list of what can be done with this technique, check out the URL Protocol or the older Using the URL Protocol on MSDN. Posted Jan 10 2008, 07:02 AM by DavidWise with 23 comment(s) Filed under: Sharepoint