While developing custom field types I found out that I often had to make queries to different metadata of different sites via different identifiers. For example, a list can be identified via both site-relative URL and ID. And if you want to get it according to Best Practices: Using Disposable Windows SharePoint Services Objects, you will have to determine SPSite and SPWeb identifiers which can be different.
It was necessary to get rid of these annoying dilemmas in order to be able to focus on developing of custom field types.
It was necessary to get rid of these annoying dilemmas in order to be able to focus on developing of custom field types.
The solution of these problems was packed into SPMetadata - a framework that facilitates work with queries to SharePoint metadata.
The framework works only with .NET Framework 3.5. because it ‘s been developed using LINQ.
It is important that searching fields and views of list are case-sensitive, for example:
It is important that searching fields and views of list are case-sensitive, for example:
web.Fields.GetFieldByInternalName(“Title”) – returns SPField
web.Fields.GetFieldByInternalName(“TITLE”) – returns NULL. (In case the site column with such internal name wasn’t created before).
Frankly speaking I don’t understand the logic of this approach. Probably the reason is in SharePoint’s core or such field names can cause some confusion. For such cases I worked out two methods: SPThis() which is case-sensitive and This() – which is not.
In this framework search was realized via parameters which are unique for metadata identifications: site-relative URL of the page that contains the view, type, internal name, and ID of the Feature containing the list definition. However they are not used in Microsoft.SharePoint methods of assembly searching.
In this framework search was realized via parameters which are unique for metadata identifications: site-relative URL of the page that contains the view, type, internal name, and ID of the Feature containing the list definition. However they are not used in Microsoft.SharePoint methods of assembly searching.
This framework has only one nuance, for example: an expression SPMetadata.Site("http://localhost").Web("/test").List("/Lists/Tasks").This(); returns NULL in three cases:
- no SPSite via specified siteID;
- no SPWeb via specified webID;
- no SPList via specified listID;
However it wasn’t essential in developing of these custom field types. If we have no site we will have no list. So we have nothing to work with.
No comments:
Post a Comment