SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Users seems to have a hard time picking the right document template when the "New" list contains more then 50 items. As one of lists on the web contains a SPChoiceField it should be possible to limit the number of items based on the value of the SPChoiceField by using the SPContentType.Hidden property.

Edit: I have access to an event handler that will be triggered each time the above SPChoiceField is changing value, so I guess it should be possible to change the visibility flag on each content type in the library? I noted the answers that recommends a JQuery approach, alas we have no scripting development capabilities in-house, so the prototype can't based on JQuery

share|improve this question
Would like to help you, but don't understand your question. Any chance you could rephrase it? – Jaap Vossers Nov 6 '09 at 11:33
Hi Jaap, I'll try to explain in another way: Rather then displaying 50 items in the "new" dropdown list I am looking for a solution that will on show the documents which is relevant at the moment. I have a "Life cycle" choice field in another list and only a subset of documents should be visible as per the value of that choice field. My question is whether there is a good reason <b>not</b> to set the Hidden property on each item when the value of "Life cycle" changes – Kasper Bo Larsen Nov 6 '09 at 17:05
up vote 1 down vote accepted

I think my first question back would be why you are using over 50 Content Types on the same list! It would seem like your architecture is a bit questionable.

That aside, what I did in one instance is to have a page which listed all of the available Content Types with a longer description of each. (The page had a DVWP which exposed the items from a list.) When the user clicked on a Content Type, they were take to the upload page, and then when they arrived on the EditForm.aspx, I simply disabled the Content Type column with JavaScript (we could have hidden it) since the user had already chosen the Content Type. By giving them more information about what the Content Types were, they could make better decisions about which to use. We also grouped the Content Types on that initial page and allowed the user to expand/collapse the list by group. This made the page manageable from a length perspective. I don't think we had more than 20 or 25 Content Types, though, and you're talking about more than 50.

Another nice aspect of this approach was that if we decided to change where we were storing any Content Type of document, we could just send the user to the new Document Library: they wouldn't need to know about it.


share|improve this answer
Marc, that solution sounds very interesting. One question: how do you know the ID of the update page? In my case I have 200+ identical sites, one for each project in the portfolio, and each site has a "Documents" list containing the same content types. The reasons for a "one content type per document template" approach is to be able to handle changes to the templates in a structured way. – Kasper Bo Larsen Nov 21 '09 at 21:05
I just had the ContentTypeIds in a list which drove the thing. I passed the ContentTypeId on the Query String, and then set it with JavaScript on the EditForm. Given your site structure, you could still store the Content Type info list in the root site, and then have a DVWP in each site which draws from that list. – Marc D Anderson Nov 23 '09 at 17:15

Doing this through normal coding would be a bit of work building a web part and take some time.

You might try using a CEWP with JQuery to do a bit of post-processing on the List just as its rendered to hide those items in the New dropdown. has some good references on this.

share|improve this answer

Thanks Kasper for further clarifying your question, it's clear now.

I agree with pilkentonc's answer that jQuery would be a good solution to hide the menu items on page load based on the value in your list. You could use jQuery to read the value by accessing the SP web services.

The main reason I would say for NOT implementing the hidden=true solution is that the jQuery implementation would be a more light-weight solution, hence a better fit in my opinion. If you have already gone through the hassle of implementing the set hidden=true approach and it works then I personally don't see a problem with that.

share|improve this answer
Wouldn't the JQuery approach be kind of heavy performance wise as calling the web service and evaluating which documents that should be visible will happen each time the document is loaded? – Kasper Bo Larsen Nov 10 '09 at 19:25
my understanding is that you want to hide the items that appear when clicking the "New" button on a document library. If that is indeed the case, it would make 1 web service call everytime you load a page that has that New button on it (or only when you click the new button if you prefer that). I would say that that is quite acceptable. When I said that the jQuery approach is a more light-weight solution, I meant it in terms of application artifacts. It's just a .js file that you'll end up with - as opposed to an evenreiver + deployment code (wsp) + attachment code/feature, etc. – Jaap Vossers Nov 10 '09 at 22:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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