Comments on: Structured and repeatable deployment of Lookup fields

By: Waldek Mastykarz

Waldek Mastykarz — Sun, 22 Feb 2009 09:55:36 +0000

@Prat: The control I have made for this article was more of a me-ware (works only on my setup ). I'd have to spend some more time to make it releasable. I'd definitely keep that in mind and will let you know as soon as it becomes publicly available.

By: Prat

Prat — Mon, 16 Feb 2009 09:39:22 +0000

Waldek,
Can you post the source code that sheds some light on me in terms of understanding more and implement the same.

THanks,
Prat

By: Waldek Mastykarz

Waldek Mastykarz — Sat, 16 Aug 2008 13:01:09 +0000

Thanks for sharing the idea, C3. I think it's a good point. I haven't tried that approach myself but it definitely seems plausible. The only concern is discrepancy between the XML configuration of the Lookup Field and setting the actual ID from the code behind. While it's definitely simpler than the approach I have suggested, the problem of storing the configuration and keeping the overview still remains in my opinion.

By: C3

C3 — Fri, 15 Aug 2008 22:57:58 +0000

…but what if you can set the LookupList property for an existing field?

As you know, the setter of a LookupList property for a SPFieldLookup object is coded to throw an SPException if you try set it to a value other than what it already is.

So the solution is simple; bypass the property.

The LookupList's property value is actually stored using the base SPField's SetFieldAttributeValue function, in a attribute called "List". So, with the miracle of relfection:

SPFieldLookup lkpFld = {get the lookup field from the Fields collection of the list)

System.Reflection.MethodInfo mi = lkpFld.GetType().BaseType.GetMethod("SetFieldAttributeValue", BindingFlags.NonPublic | BindingFlags.Instance);

mi.Invoke(lkpFld,new object[]{(string)"List",{YourListID});

lkpFld.Update();

And presto chango, your lookup field now points to the new list ID.

Incidentally, you can set that property to "Self", making the LookupList getter return the ListID of the field's parent list.

I'd also like to mention the LookupWebID property, which does not throw nasty exceptions. Since that property enables accessing lists from other sites. Maybe everyone else knows that already, but I didn't.

By: TSz

TSz — Sun, 01 Jun 2008 14:10:45 +0000

I'm not sure if this can be fixed as classes used for lookup functionality are documented features of Sharepoint, so probably wouldn't be changed in this version of Sharepoint.
As for lookup field type this is a very ugly part of Sharepoint 2007 architecture. It is possible to overcome problems of lookup fieldtype inheritance (IT-Dev View Filtered Lookup inherits from Sharepoint Lookup and works well also in multi mode), however client applications are hard coded for built in lookup and there is no possibility to use types derived from lookup. This is a really bad design example indeed.

By: Waldek Mastykarz

Waldek Mastykarz — Thu, 29 May 2008 14:51:57 +0000

Although I'm not really sure if the WSS team is planning to release such a fix, I definitely hope it would come out or they would at least provide an alternative like a new Field Type which would leverage the concept of structured and repeatable deployment.

By: Eric Bartels

Eric Bartels — Thu, 29 May 2008 13:07:01 +0000

I'm struggling with the same problems. I really cannot see any reason why MS implemented it in this way. I see this as a major flaw in the design.
I hope this will be changed in SP2