Book Review: “Enterprise Application Development in SharePoint 2010” by Ira Fuchs

I had the pleasure of meeting Ira Fuchs for the first time at SharePoint Fest Dallas a few weeks ago. Ira is a SharePoint Technical Specialist at Microsoft, so I’m guessing he has access to some of the brightest SharePoint minds in the world.

BookAs Ira and I were talking, he saw fit to gift me with a free copy of his new book, “Enterprise Application Development in SharePoint 2010”, since we seem to have overlapping interests in the SharePoint sphere. (Or is it the SharePoint wheel or the SharePoint donut?) Yes, Mr. FTC Man, I got a free copy of the book. I’m writing about it because I like it.

Ira’s book is an interestingly different take on what I call Middle Tier development. Ira uses the perhaps more correct term “declarative development” throughout his book, but many of the concepts he stresses are near and dear to my own heart. Building things in SharePoint doesn’t always mean pulling in the heavy coders.

In the book, which has the fitting subtitle “Creating an End-to-End Application without Code”, Ira takes you through developing a complex, highly useful application in SharePoint 2010 to track employee absences. This may make it seem like this isn’t the book for you, assuming you don’t want to track employee absences, but that’s not the case.

First of all, this is a process that all organizations have at some level. Even in small organizations like mine (the power of one), I need to keep track of when I’ll be available and when not. Anyone can extrapolate this application to their own processes.

Secondly, because Ira approaches this as an enterprise-class application, he touches on many of the great capabilities in SharePoint 2010; you can mix and match based upon your own needs.

The book is chock full of step by step instructions on how to get things done, from connecting to external data sources using the BCS to customizing your forms using InfoPath 2010 to creating workflows to manage the process. You’d be doing yourself a favor by adding this book to your SharePoint bookshelf.

Ira bravely self-published the book (as IHF Publishing), so support him in that risky endeavor by grabbing a copy!

XSL Is a Declarative Language – Why Do I Care?

Dreftymac ImageNode series. sample xslt file

Image via Wikipedia

One of the comments I sometimes get when I talk about the beauty of Data View Web Parts (DVWPs) in SharePoint is “You know, XSL is a declarative language, not a procedural one.” I gave a talk last night at the Boston Area SharePoint User Group (BASPUG) called Developing in SharePoint’s Middle Tier and it came up again so I thought I’d try to figure out a better way to respond than “Uh-huh”.

I turned to my esteemed colleague Ian Dicker (he thinks I should call what I do in the Middle Tier “middletation”) to see what I should think about this. Ian’s view is that XSL can be both declarative and procedural, and I concur. Of course, I couldn’t concur fully until I did a little Binging to try to find out what “declarative language” and “procedural language” meant and how they differed.  This is theoretical computer science stuff to me. Sure, I studied that in college (I majored in Computer Mathematics at the University of Pennsylvania, which was a hybrid math/computer science degree they offered at the time) but the theory of these things doesn’t play much of a role in my daily life. I usually just try to get things done. Well.

Turning to Wikipedia (everything there is true because it’s on the Internet):

Declarative programming

In computer science, declarative programming is a programming paradigm that expresses the logic of a computation without describing its control flow.[1] Many languages applying this style attempt to minimize or eliminate side effects by describing what the program should accomplish, rather than describing how to go about accomplishing it.[2] This is in contrast with imperative programming, which requires an explicitly provided algorithm.

Procedural programming

Procedural programming can sometimes be used as a synonym for imperative programming (specifying the steps the program must take to reach the desired state), but can also refer (as in this article) to a programming paradigm, derived from structured programming, based upon the concept of the procedure call. Procedures, also known as routines, subroutines, methods, or functions (not to be confused with mathematical functions, but similar to those used in functional programming) simply contain a series of computational steps to be carried out. Any given procedure might be called at any point during a program’s execution, including by other procedures or itself.[1]

and thus

Imperative programming

In computer science, imperative programming is a programming paradigm that describes computation in terms of statements that change a program state. In much the same way that imperative mood in natural languages expresses commands to take action, imperative programs define sequences of commands for the computer to perform.

(See the specific Wikipedia entries I’ve linked to above if you’d like to follow the citations.)

So, as in the title, why do I care? I think that the bottom line is that I don’t. But I also don’t agree that XSL can’t be used as a procedural language. I’m probably missing some of the nuances of the theory, but let me give an example.

SharePoint Designer sets up XSL templates itself and I do, too, in my custom solutions. An XSL template looks something like this:

<xsl:template name="StripHTML">
  <xsl:param name="HTMLText"/>
    <xsl:when test="contains($HTMLText, '&lt;')">
      <xsl:call-template name="StripHTML">
        <xsl:with-param name="HTMLText" select="concat(substring-before($HTMLText, '&lt;'), substring-after($HTMLText, '&gt;'))"/>
      <xsl:value-of select="$HTMLText"/>

This is an example from my SPXSLT Codeplex Project which strips all HTML tags from a chunk of text. It’s most often useful in displaying the Body of an Announcement without all of the goofy formating that the authors insist on using. It recursively calls itself until there are no more HTML tags to strip out the of chunk of text.  You call it like this:

<xsl:call-template name="StripHTML">
  <xsl:with-param name="HTMLText" select="@Body"/>

So based on the definitions above I suppose that this isn’t truly imperative (am I changing the program’s “state“? [Wikipedia: “In computer science and automata theory, a state is a unique configuration of information in a program or machine. It is a concept that occasionally extends into some forms of systems programming such as lexers and parsers.”), but it provides a reusable, procedural result. Again, I’m not sure if I care what the theoretical definition is, as long as I can use this template multiple times in the same DVWP, as needed. And I can, calling it with the @Title, @Body, and any other columns for which I need it, getting a consistently formatted chunk of text back, just the way I want it.