Light-weight extension of Sharepoint Document Management

I recently helped the Norwegian video-conference company Tandberg get more value out of their Sharepoint installation through extended project support features and improved desentralized internal publishing.

The existing routines for document management were heavily based on a centralized assignment of unique document numbers. Early in the process it was agreed that internally both the document url and the Sharepoint guid were unique identifiers for documents, but none of these could be used externally. This called for extending Sharepoint with functionality for assigning unique document numbers.

A primary goal in the project was not to choose solutions that required deploying custom code on the Sharepoint server. We tried several approaches but they were rejected on poor user experience (extensive use of lists and custom relations and custom auto-numbering). The final solution was based on a service oriented approach, and a simple chubby client implementation in the Sharepoint UI. The result was a simple web service interface delivering unique document numbers and two lines of html in the EditForm.aspx of the template document libaries. This is how the solution is presented to the users:

When needed, users click the link in the bottom toolbar and the Document Number metadata field is assigned a unique number from the DocumentNumber WebService.

Behind the scenes we deployed the Web Service Behaviour and a custom JavaScript that handled calling the webservice and rendering the html for the toolbar. The script and htc was placed under the _layouts folder on the server as you can see from the url. The result was only two additional lines needed in the default Sharepoint EditForm.aspx:



The tricky part of this solution was really to reverse engineer Sharepoint JavaScript rendering logic to figure out the id's of the textboxes in the EditForm.aspx UI. This script snippet will give you an idea of how to go by to get a hold of your metadata values in Sharepoint forms:

Summarized we ended up with an extremely low impact solution that proved as a significant improvement over the existing solution, thus making the migration to Sharepoint easier for the users. Another really cool thing is that it is easily extensible. The getToolBarHtml() function can return a more comprehensive toolbar with more features, and the features can be easily exposed as webservices and called with the chubby client approach. All of this done from a single location in your Sharepoint server.

For my own part I have to admit that Sharepoint forces me to appreciate client-side scripting more than I'd like to:-)

Filed under:

Comments

# Wendy said:

This is exactly what i was looking for. Genius!Could you be so kind to email me your javascript and webservice too? I'm in desperate need to implement this fast but yet do not know details on writing webservice and javascript.

email: wenngsg@yahoo.com.sg

Thanks in advance!

Wednesday, March 2, 2005 3:39 AM
# TCDooM said:

Hi,
My opinion is in sync with Wendy from the previous post!
I'll really appreciate the Web service auto numbering mechanize you made plus the JS that generates the HTML for the footer (i was wondering about adding the JS and the script to the IIS footer option that way not touching the WSS at all then including in the JS a check to see if I'm in a EditForm.aspx file... what do you think?)
tomerc<---at--->egged.co.il (anti-spam)

Wednesday, March 2, 2005 10:47 AM
# wendy said:

i've been trying to put in the .htc file for sharepoint's newform.aspx to recognise.
But it keeps returning access denied at this statement
<div id="myWebService" style="behavior:url(/_layout/1033/OfficialPaper/webservice.htc)"></div>
&even though i throw it into the _layout folder.

appreciate some enlightenment please. ;)
thanks,
wendy ng

Thursday, March 3, 2005 2:33 AM
# Mads said:

Just off the top of my head: try adjusting the trust level in wss web.config?

Thursday, March 3, 2005 11:03 AM