Further suggestions

Nov 18, 2008 at 11:13 AM


Let me start off by saying this guidance is absolutely fantastic. At the beginning of this year I lead a project which implemented an intranet training site using SharePoint. Our site manages a training catalogue, employees training needs (as are set out a the beginning of a financial year) and also allows HR to schedule a training course and then proceeds to gather feedback from the attendees upon completion. You've answered a number of questions which took us weeks of investigation - If this guidance had been available 12 months ago we would have finished the project with time to spare.

Some time ago technet (the magazine) were asking for ideas for articles for the new 'Inside SharePoint' colum; some of the ideas I sent on could also be used by you guys (the whole email is included here, you have already addresses some of the suggestions):




I have some suggestions regarding topics for the Inside SharePoint column:


The web as a whole has a wealth of documents regarding site customization using either the standard SharePoint UI or SharePoint Designer but there is very little regarding Site Definitions (and those articles which are out there are so basic that they are of little use when faced with a real-world problem), as this is an area many people are beginning to explore a wealth of how-to’s can only help the adoption of SharePoint. Some topics in particular we have struggled with are:

·         Setting custom Permissions to Lists within a Site Definition

o   What are the best practices when the requirements are for permissions to be set on a per-list basis for a Site Definition.

o   For example we tried to activate a feature upon provisioning which sets specific permissions on lists within the site but this failed as the site is not provisioned to the extent which allows permissions to be set. We have been forced to set these permissions in custom .net code which runs after the whole provisioning process has completed. Is there a better way?

·         Custom List Item Forms within a Site Definition

o   There is almost no documentation on the web about how custom List Item Forms are created (when not using SharePoint Designer).

o   How could a developer create a List Item Form with entirely custom validation?

o   How could a List Item Form be created in which fields where only visible depending on the value in another field?

o   Etc…

·         Web Part Connections from within a Site Definition

o   From within a site definition how can Web Part connections be specified?

o   If for example I wanted to specify a QueryStringFilterWebPart appeared on an AllItems.aspx form for a list in my Site Definition how can this be done?

·         How could a Site Definition be incrementally delivered?

o   Say for instance the Site Definition contains Workflows:

§  How can the workflows be upgraded so any workflows which began prior to the upgrade continue running v1 of the workflow but new items will run v2?

§  What about when a bug is discovered in a workflow; how can we deploy a new version of the workflow and get any running instances to now use the new version?

§  What about when the bug has caused the workflow to crash; how can we get it to restart at a given point?

o   Say for instance the Site Definition contains Lists:

§  What are the best practices for upgrading a list definition on a live site? (should this be done using a feature?)


One area that we spent a large amount of time on is the ability for large statemachine workflows to be resumable. If a workflow is implemented in the way most guides show there is no way for the workflow to be resumed. So if, for example, a  bug is discovered in a workflow which is running on all list items in a given list. We then deploy a new version of the workflow with a fix in. We then need to start a new workflow where the previous version has crashed (starting from the state that the previous workflow crashed in), and on the list items where the previous version has not crashed (perhaps it hasn't yet reached the stage where the bug occurs) we need to cancel the previous version of the workflow and start the new version in the same state.
To get around this we ensure no state is held internally within the workflow so that when the workflow starts it looks for it's current state in the list item and can resume. We used a dynamic router design pattern (similar to that suggested in some BizTalk articles) to ensure that the workflow was recoverable. I would be interested to hear your thoughts on our method, and it would be great if you could include this sort of stuff in the guidance as for people new to SharePoint development it's only after you've implemented the workflow once that you realise the limitations and then have to revisit (which can be disasterous for project timescales).

I hope that's been of use - If you have any questions about any of my suggestions then fire away.

Best regards

Adam Cox


Nov 24, 2008 at 7:03 PM
Thanks for your post Adam. I've communicated your issues list to our product owner to see if we can fit them in our v2 backlog.