So back in the day when I started working with SharePoint (it was a cold Monday morning ), it was around 2006 – 2007 and WSS 3.0 / MOSS 2007 was just out.
Webparts weren’t commonly known than nor was SharePoint. But we all know that MOSS 2007 was the launch to greater things.
The difference between SP 2003 and 2007 was big, one of the things we needed to ask ourselves was , are we going to inherit from System.Web.UI.WebControls.WebPart (recommended) or from the SP WebPart class..
Some differences between the ASP.NET and pure SP Webpart class:
- Cross page connections
- connections between webparts that are outside of a webpart zone
- Client-Side connections (Web Part Page Services Component)
- Data caching infrastructure that allows caching in the content database
Also creating a WSP package wasn’t that easy, if you didn’t use WSP builder of CKS than you needed to create your own package..
I think the procedure was (you can read all about it here) :
- creating a dwp file for your webpart, with the correct nodes and information
- Create a feature file
- a manifest.xml file as well
- create a DDF file so that you can cab (DDF = Diamond directive file, didn’t even know what it stands for until now)
- create a cabinet file using the DDF file (command: makecab /f solution.ddf )
The deployment happened via stsadm
Those were the times…
Also for MOSS 2007, project server came to the package as well as InfoPath Form services..
Next release of SharePoint was in 2010 and it expanded some more (Office web apps, FAST search server, …) . Webparts could still be created but you can now create also Silverlight packages and use these in SharePoint to make it more beautiful. Silverlight could also be used in MOSS 2007 but you had to write your own wrapper around it and Silverlight could only use the web services or use the OM via the wrapper. But also JQuery came to light (Jquery could also be installed for MOSS 2007, you can read about it part 1 and part 2 in the Blog of Jan Tielens ) but it wasn’t used that much in 2007 than in 2010 I believe.
In SP 2010 REST came into play and also CSOM and an OM especially for Silverlight. So we could already see the step towards client side code more and more. Sandbox helped in that regard as well. All this was created because Webparts are running solely on Server side. Meaning that it could impact the performance of the Web front end machines. So moving the logic client side would be a very logical step.
The reason why I’m writing this blog post is because I’ve highlighted this in a very small part in one of my previous blog posts and after some talks with Karine (Bosch) and some other people of the MEET team. We are all saying the same thing.
It’s no longer sufficient to write only C# code and all server side. Ok it’s the easiest because we’ve grown up with it almost and it’s what we know best. But a SharePoint developer should start to make his/her first reaction, “am I going to write this in a webpart or an app, what is the best technology for this, is it going to be multi lingual”? All these questions should be asked first before writing one line of code. The technologies that are available for us are too diverse.. and you can clearly see the move to client side code.
Einstein and SharePoint are two paths that never crossed – but applying his most famous quotes to SharePoint creates an amazingly rich and accurate framework of discussions that all SharePoint experts should learn from.
Here are some great examples:
“Any intelligent fool can make things bigger and more complex… It takes a touch of genius – and a lot of courage to move in the opposite direction.” – Albert Einstein
“If you can’t explain it simply, you don’t understand it well enough.” – Albert Einstein
“Information is not knowledge.” – Albert Einstein
That’s it.. have a great week..