In my previous post, I mentioned the changes to some parts of WSSv3 that I saw at the Office Developers Conference 2007 held in March ’06. Here are a few more sections in WSSv3 that are different or have additions over v2.0
Object Model
There is a new concept of Property Bags. Property Bags are buckets of information that can be associated with items in a List/Library/Web. The values are simply stored in a hashtable. If we need to store some data programatically with an item we can store it in the Property Bag and on Update, Sharepoint will automatically persist this data to the database.
Elevation is a new concept that allows the code to run at a higher privileged level without actually "impersonating" an account. **Note: I am not very clear on this right now and will post an update as soon as I verify my understanding. But I believe this is how ‘elevation’ is different from ‘impersonation’.**
Extensible Admin Objects – we can now define our own objects for administration purposes and sharepoint will take care of persisting their information as part of the sharepoint administration.
Events
With WSS v.2.0, Microsoft introduced the concept of event sinks, which were DLLs that could be attached to a specific document/forms library. These would get called after a particular action had occurred on the library.
With WSS v3.0, Microsoft has gone a step further and has extended the scope of events. They not only cover document/form libraries but also Lists and some web/site events. Also, now you get both pre and post action events. I.e. the event handler gets called before the action occurs and after the action occurs. Couple of things to keep in mind:
1. "pre" action events are synchronous whereas, "post" action events are asynchronous.
2. Events arent gauranteed.
3. "pre" action events do not have a binary stream attached, i.e. say an event that occurs when a document is inserted into a document library, that event will not have access to the document that was being inserted. BUT, that said, the "post" action event for the same insertion will have access to the document.
4. The methods to override in the event handler have "ing" as suffixes for those methods which belong to the "pre" action category and have "ed" as suffices for those methods which belong to the "post" action category
5. You can cancel events by specifying a ‘cancel’ property and an error message that will be displayed to the user.
Also, unlike in WSS v2.0, the number of event handlers aren’t limited to one event handler per library. Though the v2.0 method of registering event handlers is still available, that is not the recommended way to register event handlers. They should be registered using the new concepts of "Content Types" and "Features" which I will talk about in a future post.
Timer Jobs
Available to administrators only. You can now use the WSS timer mechanism by deriving your class from SPJobDefinition and overriding the ‘execute’ method. The job can be set to run once or as a recurring job. Work Items extend this concept to the end user where they can schedule jobs that will run at a later date. These need to derive from SPWorkItemJobDefinition.
Import/Export
There are new API’s available to do import/export of sites, lists, items. You can use these to merge content into existing sites or create new sites. The deployment is based on an open format with XML packed in CAB files.
Content Types
Content Type is a new feature and is very core to this version of WSS. It is a reusable collection of settings that can be applied to sites/libraries/lists etc. One of the things CT’s allow us to do is they allow us to store multiple types of documents in a single document library. Compare this to the previous version; on a document library page, an end user had the ability to click on "New Document" and this would bring up a pre-defined template that the user could use to complete their work. Now, since CT’s allow us to associate multiple document types, the end user experience is enhanced since, they can click on "New" and a drop down menu gives them a choice of document templates to choose from to complete their work. This is just one wonderful example of CT’s in use, but they are very powerful and allow us to do a lot more like associate multiple event handlers to a library, attach security policies and specify many more settings per document type that can get applied to the target content category (e.g. list/library).
These are some of the topics which stood out during the dev con. I will now start posting detailed information based on my experience with this new technology as I start developing and playing around with it. Can’t wait to get my hands dirty!
