The Trouble of using Constant Values

The trouble in SharePoint is that you need a lot of constant values for names of lists, fields, receivers, assemblies, groups, views and content types. Usually you define these in xml documents.

When specifying the components (lists, content types, fields, etc.) using xml you have no possibility to use variables. This is a problem as you have a lot of rework to do once you need to change something and you have a lot of references (references beeing mentions of other components at definition time. This is especially true for applications with high component coupling.

Another thing is that the possibilities for specification are limited. You cannot define lookup fields correctly as you do not know the GUID before the list and the field that are looked up exist (The GUIDs you can insert are not applicable as you would use the equivalent of a class GUID instead of the instance GUID and the instance is not yet created at definition time).

What you will do is either create a feature receiver to tidy up you definition (create remaining lookup fields programmatically using the SharePoint API) or doing the whole routine using the API inside the feature receiver. I favor this option as it reduces the redundancy, it is debuggable and easier to use (less error prone, as Visual Studio assists you). Drawback is of course that the list is not updateable using the intended Microsoft mechanism via stsadm -o upgradesolution.

As there are still some issues with this anyway (specification and deployment), SharePoint change management can be done only using the API from my point of view. So you would create a new one-shot solution containing a feature that on activation changes your application accordingly. There are certainly some issues to get into when doing this, but for SharePoint 2007 you should seriously consider this.

So at this point you are using feature receivers one way or the other for your lookup fields. So it makes sense to declare your constant values at one central point. For the start it does not matter how you do this using one giant class for each type (list, group, content type, view, etc.) or creating a class for each actual object of the sharepoint application but you should always remind yourself that it makes sense to declare variables as constants for performance issues. You should also think about how many objects you want to specify, as you will typically use these in a static context. So you use either lightweight objects, singletons, static class definitions but you definitely separate definition of these constants from your code logic.

For custom components using workflows, eventreceivers and definition of a lot of lists it especially makes sense to use this approach as you will reference your objects using the names as key-value when iterating over the collections or direct access.

The main objective is to be enable management of code that is subject to change a lot. Using redundant string values each and every time makes changing names strenuous and error-prone.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: