0

I'm working on a site, where a web part I'm building takes the name of a custom list type as a property when editing the web part settings.

The "List" that this visual web-part is designed to display, comes from a List template that is also installed into SP (Currently 2010).

Iv'e already figured out how to tell that the list assigned is "GenericList", but what I actually need to know is the specific list type. I'm obtaining this property from the SPList object type that I have for the list specified by the user.

In case anyone wants code... here you go.

  errorMesg.Visible = false;
  if (string.IsNullOrEmpty(ListName))
  {
    errorMesg.Text = "Please assign the name of your JobsQueue list in the web part settings, under list settings";
    errorMesg.Visible = true;
    return;
  }

  SPWeb web = SPContext.Current.Web;
  try
  {
    SPList jobsQueueList = web.Lists[ListName];
    if(jobsQueueList.BaseTemplate == SPListTemplateType.GenericList && <WHAT DO I PUT HERE TO SAY AND IS A JOBSQUEUE TYPE>)
  }
  catch (ArgumentException)
  {
    errorMesg.Text = $"The List name '{ListName}' does not exist in your current site, please ensure settings are correct.";
    errorMesg.Visible = true;
  }
  finally
  {
    web.Dispose();
  }

However, I think Iv'e explained ok what I'm trying to achive (Well I hope I have any way!!! :-) )

In my solution, there are several custom List Templates added, and I need to know that the user has selected EG "JobsQueue" type, rather than "PaymentQueue" type.

All I can see so far is "list.BaseTemplate" which is how I know that the list is a Generic/Custom type, now I just need to figure out which custom type.

I'm doing this for good error handling, so that my visual component doesn't crash if a List type is assigned that doesn't have the correct list structure that it expects.

Any pointers on the best way to this greatly accepted.

Cheers Shawty

Update

Iv'e been talking to a good friend of mine, who I know, knows Sharepoint very well, but he didn't have time to take me through an entire example, He suggested that I might want to try 1 of 2 things:

1) Add a taxamony metadata field on the list definition (I'm developing these lists and Web parts in Visual Studio 2015), then when I check the table type, just simply look for the metadata marker, to know the list type.

2) Alter the list type ID's in feature-elements.xml and then look for those ID's in the base type ID to determine the list type.

I don't know what either of those 2 options are, and as I say he didn't have time to explain to me, so if these ideas trigger anything for anyone before I get chance to hunt the knowledge down, please feel free to comment :-)

Update 2 (Approx 26+ hours later)

So after much more reading, and researching, and breaking things then fixing them again.

I think I've found what to me seems like a better method than scanning field names, I'll add an answer for it soon.

  • 1
    Have you looked at SPListTemplateType enumeration? "Since these list types are not have corresponding values in this enumeration, you should consider not using this enumeration as a parameter value in your custom methods. Consider, instead, using String or Int32 parameters that take the list type ID as string or integer." – Trevor Seward Jun 17 '18 at 13:58
  • Thanks Trevor I'll look into that, however, how do I know the Guid/Id of the list type at run time? I can't expect my end user/admin to have to know that when adding the web part to a page, or is that what MS expects? – shawty Jun 17 '18 at 14:20
1

What your friend may be thinking about is adding a column to the list with a name unique to that list. The column does not need to be used, but could be. Your code might look something like this: (I can't test it right now...)

in a try catch block:

var x = jobsQueueList.Fields["my Custom Column Name"]

If found, then it is your custom list.

  • Hi Mike, yes, I kind of rolled with that idea in lieu of any other way, but instead since I knew exactly the column names I added, in the list definition in visual studio, I came up with a small loop to scan the internal names of all the fields, and compare them to a static array of magic strings in my visual web part. While this worked, for some of the larger lists it quickly became a maintenance nightmare, so I kept reading, and researching and Iv'e figured out a way to achieve what I need to do using content types, which I'm going to write up soon. – shawty Jun 18 '18 at 19:53
0

As the update in my comment mentions, I've come up with what in my mind is a slightly better way to handle this.

I'm creating the list definitions in visual studio, so they get installed at the same time as the web parts etc.

I kept thinking about this concept of "Meta Data" that my friend was on about, and then it occurred to me that I'd seen it used a great deal when reading about content-types last week.

After looking at the items I was able to add to a share point project in Visual Studio, I discovered I could add custom content-type's so I added one for my JobsQueue list, called JobsQueueContentType

Portion of the solution explorer in my SP project.

As you can see, that means I create a web-part, a list +instance definition and a content type for each list/scenario.

In the content type, I give it an easy to recognize, but unique name.

Content Type Name.

And I don't add any columns to the type, as I'm not actually going to use it's fields, they are already defined in the list definition.

Once the content type is defined, I then add that content type, to the content types assigned to the list.

Content type added to list.

But, notice I DON'T set it as default, as I say, i'm not actually interested in using it's definition, as that's what the list itself is for, and if you set it as default, you'll loose the standard ability to use the generic list add/edit functionality in the base sharepoint product.

Once I have this content type added, any list that is then created in SP by a user/admin is automatically tagged with this, if they use this instance to create the list in the create dialog.

In the web part, I then simply just look through the content types for a single string as follows

Code showing the loop scanning for content type

It's still a similar process to scanning the field names, as my first attempt was, and as others have suggested/hinted at, but I think it's nicer, because we are only ever looking for one string, that is not impossible to change, but certainly harder or least likely to get changed, than a field name.

I'm quite pleased with myself considering that just under a month ago, I knew absolutely nothing about Sharepoint, I am however still holding out for a sharepoint expert that will tell me I'm doing this wrong :-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.