Category: SharePoint

What’s Wrong with SharePoint?

So, I am watching Twitter updates go by (as I always do, even on a Saturday night), including my search that shows me all the tweets with “sharepoint” in them. As anyone knows who watches any amount of SharePoint commentary go by, there is a fairly constant flow of comments of the “SharePoint sucks” variety.

So this evening this led me to ask the question “What is wrong with SharePoint?” No, I do not mean I want a list of every nit picking, annoying little defect – every platform has defects and annoyances. I also do not want to know why SharePoint is note good for everything – no platform is good for everything. I also do not give a crap if your opinion is “it comes from Microsoft therefore it MUST suck” – it that is as deep as your analysis can go, well, you’re a moron.

What I want to see from SOMEONE is an intelligent, well thought out description of why SharePoint sucks. Why is it a bad choice for anything? Why should you perform an exorcism on all servers running any version of SharePoint?

I did a web search (notice I did not say “google” – contrary to popular usage, google is not a verb) for “what is wrong with SharePoint?” The only relevant results I found on either Google or Bing were written in 2005 or before, and hence are not particularly relevant at this point. For example, the post Five Things Wrong with SharePoint from back in 2005 tries to talk about what is actually wrong  with SharePoint. Even though I disagree with a lot of what it says, I will not refute it since it is so old.

So – if SharePoint is so bad…if all the otherwise intelligent people implementing solutions over SharePoint are wrong – where the heck are the statements as to what is wrong with it. So tell me – WHAT IS WRONG WITH SHAREPOINT? I really want to know, and to share it with others.

Danger! Do not….well, you know…

My column “Danger! Do not implement SharePoint in your organization!” has been reposted on EndUserSharePoint.com

(or read the original on LegalITProfessionals.com)

Interesting response to my column on the “dangers” of “implementing SharePoint”

I find the response to my latest Legal IT Professionals column. As expected, the title drew some very interesting reactions – that is, afterall, the intent of a title – to say something that will draw people in and get them to read the content. In addition, it was intended to be a “whack in the side of the head” (borrowed from Roger van Oeck), to startle people out of their normal daily thinking as the began to read the column. While most of the response I have was neutral to positive, some (even those who responded positively) seemed to miss the intent of the title.

(I must admit, though, that I feel a little bit like a tabloid publisher – maybe I will call my next column “NASA Reveals – Bigfoot loves SharePoint”)

For those confused – the real intent is that there is not (or should not be, in my opinion) any such thing as “implementing SharePoint”. You may install SharePoint, configure SharePoint, develop over SharePoint, but you are not implementing SharePoint. You are implementing solutions to business problems of which SharePoint (or any other technology) is only a part.

Working with Association Data in MOSS Workflows

I received a couple of comments in response to me previous post on Custom Association and Custom Initiation forms regarding how to use the Association and Initiation data collected, from within the workflow code. I had answered in my responses that you just access the AssociationData and InitiationData members of the WorkflowProperties, which return the data as XML strings. You then just work with that XML as required.

Here I will present some sample code for actually working with the XML coming from the custom AssociationData.

First, I would like to step back though and look at designing the Association Data. Typically when working with any InfoPath form, I start from the data side, and develop an XML Schema for the data (ideally, this is done as part of the overall design of the solution being developed, and includes all of the data design for the solution). The code snippet below shows the schema I developed for this example.

<?xml version="1.0" encoding="utf-8"?>
<xs:schema targetNamespace="http://t4g.com/TestSchema.xsd"
           elementFormDefault="qualified"
           xmlns="http://t4g.com/TestSchema.xsd"
           xmlns:mstns="http://t4g.com/TestSchema.xsd"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
>
   <xs:element name="AssociationInitiationData" type="AssociationInitiationDataType" />
   <xs:complexType name="AssociationInitiationDataType">
      <xs:sequence>
         <xs:element name="TaskDescription" type="xs:string" />
         <xs:element name="AssignTo" type="xs:string" />
      </xs:sequence>
   </xs:complexType>
</xs:schema>

Note that this schema represents both the Association Data structure, as well as the Initiation Data. It is necessary for these two to share a schema and namespace, though the Association form need not populate all of the fields.

A Custom Association Form can then be developed in InfoPath based upon this schema, and deployed as described in my previous post.

Now, how do we access this Association Data from within our workflow?

I implemented a simple serializable class matching the schema, as shown below.

[Serializable()]
public class AssociationData
{
   private String _TaskDescription;
   private String _AssignTo;

   public String TaskDescription
   {
      get
      {
         return this._TaskDescription;
      }
      set
      {
         this._TaskDescription = value;
      }
   }

   public String AssignTo
   {
      get
      {
         return this._AssignTo;
      }

      set
      {
         this._AssignTo = value;
      }
   }
}

I also implemented a helper class (creatively named) to support loading the Association Data into this class (note that this helper handles both the Initiation and Association data):

public class Helper
{
   public static InitiationData DeserializeInitiationData(string xmlString)
   {
      using (MemoryStream stream =
         new MemoryStream(Encoding.UTF8.GetBytes(xmlString)))
      {
         XmlSerializer serializer =
            new XmlSerializer(typeof(InitiationData), "http://t4g.com/TestSchema.xsd");
            InitiationData data = (InitiationData)serializer.Deserialize(stream);
            return data;
      }
   }

   public static AssociationData DeserializeAssociationData(string xmlString)
   {
      using (MemoryStream stream =
         new MemoryStream(Encoding.UTF8.GetBytes(xmlString)))
      {
         XmlSerializer serializer = new XmlSerializer(typeof(AssociationData), "http://t4g.com/TestSchema.xsd");
         AssociationData data = (AssociationData)serializer.Deserialize(stream);
         return data;
       }
   }
}

Given these two classes, it is then simple to access the Association Data from within the workflow. For example, add a private member to the workflow class:

private AssociationData _associationData;

Then from within the onWorkflowActivated activity, add the following code:

String AssociationDataXml = workflowProperties.AssociationData;
_associationData = Helper.DeserializeAssociationData(AssociationDataXml);

The association data can then be accessed from within our _associationData object as required. The Schema, and the AssociationData class definition, can be modified as required to add additional fields.

I was considering another post about doing the same thing for InitiationData, but it works exactly the same way. So unless someone really insists, I will not bother.

First look at SharePoint 2010 for Developers

The past week has seen quite a bit of new information being published by Microsoft regarding Office 2010 and SharePoint 2010. This is just the start, I am sure, and by the time Office 2010 is released next year, we will probably all be getting sick of hearing about it (jk). A good place to start getting a feel for SharePoint 2010 is to look at SharePoint 2010 Sneak Peek videos recently posted by Microsoft.

I had a look late last week at the new features from a general perspective – see my column over at Legal IT Professionals. In this post I want to have a look at some of the new features for developers. I will give my take on what I saw in the videos, and also mention a few things that I was hoping to see but didn’t.

The Developer Sneak Peek Video covers a number of features of SharePoint 201 for developers:

  • Visual Studio 2010 SharePoint tools
  • Language Integrated Query (LINQ) for SharePoint
  • Developer Dashboard
  • Business Connectivity Services
  • Client Object Model (OM)
  • Silverlight Web Part

The Visual Studio SharePoint tools are intended to improve programmer productivity when developing for SharePoint. A major new feature is the Visual Web Part Designer. As the name implies, this tool lets you visually design your web part UI, rather than coding it or using something like SmartPart. While the demonstration in the video is extremely simple, this tool should greatly improve the process of developing Web Parts for SharePoint 2010.

The support for Feature and Solution packaging seems to be greatly improved as well, and actually looks like it is a real Visual Studio tool rather than an afterthought.

Microsoft has also added a SharePoint node to the Server Explorer in Visual Studio. This allows you to look at the structure and content of the SharePoint site you are targeting without having to bounce back and forth between IE and Visual Studio.

Another big feature is the Business Connectivity Services design tools for Visual Studio. This is a set of tools for implementing BCS entities from within Visual Studio, allowing a developer to do more sophisticated BCS development than is possible from SharePoint Designer.

Moving beyond Visual Studio, there are a number of other important enhancements for developers.

One of these enhancements is the Developer Dashboard. This is a component which is enabled by a sight administrator, and can be added to any SharePoint page to support development and debugging. It provides diagnostic information regarding including the detailed page request, timing information, information on Stored procedures called, as well as details regarding resource usage, authenticated user, web part timings, etc. This should be a big help in troubleshooting issues.

Another addition is the addition of the Client Object Model, a client-side API for interacting with data on the SharePoint server using JavaScript, .NET code, or Silverlight.

Speaking of Silverlight, there is now a built-in Silverlight Web Part to facilitate deployment of rich UI components. The video shows a nice demonstration using Silverlight, the Silverlight Web Part, and the Client Object Model.  

While I definitely like what I see for developers in SharePoint 2010, there are a number of things I want to see but didn’t:

  1. The Visual Web Part Designer is great. I am curious, though, whether this tool will have any support for developing connectable web parts more easily? Creating the visual part of the Web Part is wonderful, but most useful web parts need to provide or consume connections.
  2. Another thought on the Web Part Designer – does it have support for developing async behaviours, or does it still have to be duck-taped together?
  3. Is there better support for development of Site Definitions, List Definitions, Content Types, etc.? This has remained a manual, tedious, and hence error-prone process. Similarly, is there support for editing of CAML for queries, etc.?
  4. SharePoint Workflow development support. The tools for workflow development in SharePoint 2007 are “ok” as far as they go, but there remain a fair number of very manual, very “cludgey” steps that make it non-trivial to implement real-world workflows, including the mechanisms for developing and using custom ASP.NET association, initiation, and task forms.
  5. Speaking of workflow, the execution environment for workflow in SharePoint is missing some pieces, most notably the tracking service. What has been added?
  6. Rumour has it that SharePoint 2010 will be running over .NET 3.5, not .NET 4.0. Say it ain’t so! So SharePoint Workflow will not take advantage of the performance improvements in .NET 4.0 – what’s the point?
  7. Does the Silverlight Web Part support connections? Or must any data flow into or out of the web part be done from within the Silverlight?

Well, those are my first thoughts on SharePoint 2010 for developers. I can’t wait to see/learn more over the coming months.