2

I need to develop a SharePoint solution that has many layout pages, ten sub sites to be exact. Each department wants to have its own slight variation on the three layout pages proposed at the beginning of the project. Therefore I am going to have a lot more layout pages that I will have to create now ten instead of the original three. I really wanted to have a restricted number of layout pages.

I was going to go the aspx user control route and have simple custom controls for each region on the layout pages. I have found this to be a lot simpler to deploy and pages load a lot faster than having too many web part on the layout pages but then I lose the flexibility of using web parts.

In this solution I am consider using a combination of user controls and web parts to help cut down the number of layout pages I want to deploy but still provided some flexibility to the end users.

My question is, is it best to use web parts as part of your SharePoint solutions? Can having too many web parts on a page affect the performance and speed at which a page is loaded?

Using aspx user controls is the asp.net way of web development and therefore easier to produce but when is it best to use aspx user controls in a SharePoint solution?

Improve this question

3 Answers 3

Reset to default
4

Having many page layouts isnt necessarily an issue. You can (in publishing feature) determine what publishing pages to allow on a given site/subsite, and you can also change this in Site Settings > Page layouts and site templates.

Also you dont mention what features that varies from PL to PL. You can get a long way with using different CSS for different sites to get a PL look one way on one site, and different on another.

If you provision pages using modules and features you also have a way of reusing the same PL with different content by placing Web Parts inside your zones with AllUsersWebPart tag.

Regarding your other question, yes you can definately have too many web parts on a page. There is no magic number for how many, since it depends on what the web part do. TechNet specifies 25 before performance is affected, but I would never put that many on a page, instead create multiple pages.

Weather you choose to use user controls or web controls is pretty much a personal preference. I tend to use both, but often i tend to create them as delegate controls. That way I can configure it with properties and replace with new controls without having to do more than switch on a feature!

Improve this answer
2
  • Web Parts were born with SharePoint, and the whole thing is based on them - all you see at SharePoint site - lists, list forms, pages - all have webparts inside. So why don't you use them? :) @Anders Rask, thanks for comprehensive answer and many useful links! +1
    – Andrey Markeev
    May 3, 2011 at 10:32
  • Thanks for this information I will look over all your notes.
    – Steven Summone
    May 5, 2011 at 10:16
2

In my opinion if you have component on page and you have doubts...

Go with web part when user needs to personalize, configure, remove or edit component.

Go with user control when one same component is going to be on many layouts. I like to think that web part configuration has 'page scope' and user control 'global scope'.

Maybe you can use feature stappling to add web parts on pages when site is created based on some config file and site url. You will have less layout pages but more code to debug.

Improve this answer
1
  • +1 I like the explanation about page scope and global scope. I'd say definitely create user controls if you can reuse code across web parts.
    – Kit Menke
    May 3, 2011 at 15:39
1

A web part is just an .aspx custom control with a little extra plumbing. It means that your control can be configured at run time by a power user, which is great tool for any kind of composite application. That custom control can also host a user control (visual web part) if you need the ability to build it visually. So it is a bit of a false distinction, in that the capabilities of a web part are a superset of an aspx control.

My view is that building a web part, as opposed to an aspx control, gives you additional flexibility with minimal extra effort. You might as well have that web part infrastructure available to you. You can always embed a static web part in a page layout or master page at which point it is acting as a control. So the decision is whether to embed the web part or put it into a web part zone.

How you break your site down into master pages, page layouts, static controls and web parts is really a trade-off. You have to decide how much flexibility you need to give your content authors or users, what elements are common throughout the site, what groups of pages you can identify. You don't want one page layout per page, nor do you want one hugely complicated layout for a diversity of pages. This is the skill of designing and architecting a SharePoint site.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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