Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Big picture overview of what to do to create custom looking site

  Asked By: Josiah    Date: Jan 19    Category: Sharepoint    Views: 1007

I'm taking a break from our installation woes to dive into template
creation woes.

The more I read about templates, masterpages, themes, etc, the more
confused I get.

Here's what I have/need to do.

The structure will be:

Top Level Site:
- Home = static nav + newsitems
- 'Gateway pages' = columns of links into specific sites
- News Archive page

Department Sites:
- looks the same as above, with the addition of the
Site 'quicklaunch' bar. Added to the right.

What I have:

- a set of HTML templates created by a 3rd party using
Tables layouts via the Yahoo CSS Grid Framework

What do I do?

This is where I'm confused. Most every SPD tutorial begins with 'let's
modify a master page'. Is that what I want? Or do I want to make one
from scratch? Am I making a master page? A template? A theme? All three?


This sounds like a simple question, but one that seems to have too many
answers.

Share: 

 

7 Answers Found

 
Answer #1    Answered By: Saul Cobb     Answered On: Jan 19

In general:

Master page  = page "chrome" - controls the common elements used on every
page, the normal top  and left nav  stuff, could include right nav and/or
bottom nav as well

Page layout = layouts  for the page content (e.g. the web part zones
and/or WCM placeholder locations) used to standardize layouts for
different page types

Theme = CSS rollup suitable for use in WSS (can also be used in MOSS,
but targeted to non-publishing sites)

Template = site  (or site collection) base including one of all of the
above + lists, etc

 
Answer #2    Answered By: Karl Reid     Answered On: Jan 19

All pages  on all sites  of our intranet will have a top  navigation and a
left navigation that will static, meaning it's not going to be generated
via MOSS but updated manually when needed.

In my pre-MOSS days, I would have made these server side includes. Still
a viable option in MOSS?

I could just embed them into the MasterPage, but from what I understand,
MasterPages are only used at the time of site  creation, so any
subsequent changes to that masterpage wouldn't reflect into the pages
that were built previously from that master  page. Is that correct?

Page Layout...that's only if one is using a publishing portal, correct?
And doesn't apply to team sites?

Template...so, to make a 'template' one would create  all the
masterpages, css, and page layouts  they want, build a site selecting
those options, and then save that off as a template, correct?

In all these cases, what's the easiest way to manage changes down the
road on all these sites? If at some point management wants us to swap
out the site footer on all pages, for instance, what would be the best
solution to accommodate that down the road.

 
Answer #3    Answered By: Lionel Phelps     Answered On: Jan 19

The top  and left nav  should be done with a master  page - that's the
current and best way to do this in MOSS. The "stickiness" of Master
Pages is going to depend on your SharePoint version and site  type. For
MOSS publishing sites, changes to the Master page  will be reflected in
every site page automatically, and can be optionally applied to every
sub site in a site collection (including team sites) as well. If you
top level  site is not a publishing site, changes to the default Master
Page for the site will still appear in non-_layouts site pages, but
there is no UI option to change the master page for _layouts pages  or to
apply the changes to subsites.

Yes, page layouts  are a publishing feature.

On templates, yes you are correct.

If you implement the footer via the master page, you just need to edit
the master page. Once the changes are made, you may need to copy this
around a bit depending on your site type, but it shouldn't require
anything resembling changing every file.

 
Answer #4    Answered By: Marlon Colon     Answered On: Jan 19

For modifying the navigation to something more static  I would create  a
standard ASP.net sitemap xml file and then switch the properties of the
Navigation datasources over to use the new sitemap.

The Masterpage is always used when a page  is rendered just like it is in
ASP.net 2.0. The Masterpage is ghosted from the 12 hive to the site  at
site creation time. If modified in SharePoint Designer it becomes an
instance page and changes made to the 12 hive page will no longer change
anything. Changes to the local master  page instance will change the
page.

The term page layout is normally used only in Publishing, but there is
still a default.aspx page that is combined with a Master Page to create
the rendered page. In publishing controls on the default.aspx page must
be reflected in a content type. That's a layout page.

Your definition of a template  is correct. But you can do the same thing
by building a Site Definition using XML and storing it in the 12 hive.
Templates and Definitions both show up when creating a new site.

 
Answer #5    Answered By: Pierre Copeland     Answered On: Jan 19

> For modifying the navigation to something more static  I would create  a
> standard ASP.net sitemap xml file and then switch the properties of
the
> Navigation datasources over to use the new sitemap.

I might do that, though I really prefer to be able to manipulate the
HTML directly, as I've never been happy with MS's less-than-semantic
.net control html  output.

We have a few custom  controls of our own that we could probably just use
that also bind to XML data sources. The advantage, I suppose, is that I
could easily make a separate control to allow site  admins to manipulate
the XML sources directly.

The question  I have is can I have user controls on the server (as
opposed to the database) and have them on every site's master  page and
then just update the one user control and have all site's update?

Or every time we update a control/web part, do we have to 'republish'
each and every masterpages  for all the sites?

> If you implement the footer via the master page, you just need to edit
> the master page. Once the changes are made, you may need to copy this
> around a bit depending on your site type, but it shouldn't require
> anything resembling changing every file.

Let's say I have one top  level site, 30 subsites, and as many subsites
under those as each department wants to create on their own.

Each is using the same masterpage, but they are all independent sites.

Is there any way to change the footer and have it apply to all sites? Or
do I need to 'reattach' the updated masterpage to each and every site
that's using it?

A general question for everyone:

I'm still a little confused  as to all the differences between 'team
sites' and 'publishing sites'. Is a publishing site the same as a team
site, but with a few additional features (layout pages, navigation,
approval)? Or does it omit some of the options that a team site has? Can
we use a publishing site to get, say, layout pages, but 'turn off'
approval?

 
Answer #6    Answered By: Lewis Mann     Answered On: Jan 19

If your need is to create  a common look and feel across multiple sites,
SPD is not the tool that you should start with. In fact, I'm of the
opinion that SPD should rarely be used to alter Master Pages, you should
use VS.NET to create Master pages  that can be ghosted across all the
sites that will need the common look and feel.





While this really doesn't address your question, there are a few terms
that every SharePoint developer should use when describing WSS v3 Sites
(Webs):



Site Definition: A site  Definition is a collection of XML files and ASPX
pages stored in the 12 Hive that are used as the foundation of a Site
(Web); they DEFINE what will the Site will look like and how the Site
will behave when an instance is created. Unfortunately, Microsoft stores
Site Definitions in a folder called ..12\TEMPLATE\SiteTemplates. In WSS
there are only a handful of Site Definitions:

STS: SharePoint Team Site

MPS: Multi-Page Site (aka Meeting Workspace)

WIKI: Wiki Site

BLOG: Blog

CENTRALADMIN: Central Admin Site (Hidden)



The GLOBAL Site Definition found in ..\12\TEMPLATE\GLOBAL\ runs before
all other Site Definitions to setup the environment that WSS needs to
provide platform functionality. Of course, MOSS adds a bunch of
additional Site Definitions not mentioned here.



Site Configuration: Each Site Definition has one or more Configuration
elements in its .\XML\ONET.XML file. These Configurations indicate what
List Instances, Features (code), and Modules (page/file instances) will
be created/activated when that Configuration of the Site Definition is
chosen from the Create page. WSS only has a handful of Site Definition
Configurations:

STS#0: Team Site

STS#1: Blank Site

STS#2: Document Workspace

MPS#0: Basic Meeting Workspace

MPS#1: Blank Meeting Workspace

MPS#2: Decision Meeting Workspace

MPS#3: Social Meeting Workspace

MPS#4: Multipage Meeting Workspace

WIKI#0: Wiki Site

BLOG#0: Blog

CENTRALADMIN#0: Central Admin Site



Microsoft doesn't support modification of the out-of-the-box Site
Definitions; use a FeatureSiteTemplateAssociation Feature (stapling) to
add functionality to these Site Definition Configurations.



Site Template: A Site template  is used to define the Site Definition
Configurations that will be displayed within the browser user interface
(Create > New SharePoint Site page). Site Templates are found in a
..12\TEMPLATE\1033\XML\WEBTEMP*.XML (temp as in template, not temporary)
file and assign characteristics not only to the Site Definition but also
to each Site Definition's Configuration(s). Site Definition
Configurations found in the WEBTEMP file must have a corresponding entry
in the Site Definition's ONET.XML file.



Site Template (STP): It is possible to capture a Site into an STP file
(actually a CAB) that is physically stored in the Site Template Gallery
(a Library within the Top Level site in a Site Collection) and
displayed on the New SharePoint Site page  for the Site Collection that
owns the gallery. This is effectively a "macro" (my term) that captures
the differences between a Site created  directly from the underlying Site
Definition and the Site captured and is utterly dependent on the
underlying Site Definition. These are far less useful with the advent of
Features and Solutions in WSS v3 but must be mentioned for completeness.
It is also possible using STSADM to make a Site Template STP available
to every Site Collection within the Farm.

Site Instance: When a new Site Instance (aka Site or Web) is created,
rows are inserted into tables in the content database defining the
metadata that indicates that a Site exists. Pages are ghosted as
documents into the AllDocs table (I think).

Site View: There isn't really the concept of a Site View or a Site View
Web Part in WSS v3.

A similar vocabulary exists for WSS v3 Lists:

List Definition: A List Definition is a collection of XML files and ASPX
pages stored in the 12 Hive that are used as the foundation of a List;
they DEFINE what will the List will look like and how the List will
behave when an instance is created. The List Definition schema.xml file
indicates what Content Type(s), Fields, Views, and Forms will be
created/used when it is chosen from the Create page. Microsoft stores
most List Definitions as Features within ..12\TEMPLATE\FEATURES. In WSS
there are only a handful of List Definitions most of which are listed in
the TeamCollab "wrapper" (my term) Feature
..12\TEMPLATE\FEATURES\TeamCollab\feature.xml. There is a schema.xml
file that defines most of the details about the List. For example, the
Announcements list is defined in the
..12\TEMPLATE\FEATURES\AnnouncementsList\Announce\schema.xml file.

List Configuration: Lists don't really have the concept of a
Configuration. I suppose a very weak analogy could be made to Content
Types but I really only mention it here to acknowledge that Content
Types play a role here and to bring parody to my point. Most WSS v3
Lists are based upon an out-of-the-box Content Type.

List Template: A List Template is used to define the List Definitions
that will be displayed within the browser user interface (Create page).
List Templates are found in Feature files for each List; for example,
the
..12\TEMPLATE\FEATURES\AnnouncementsList\ListTemplates\Announcements.xml
file assigns characteristics to the List Definition.

List Template (STP): It is possible to capture a List into an STP file
(actually a CAB) that is physically stored in the List Template Gallery
(a Library within the Top Level site in a Site Collection) and
displayed from the Create page for similar sites  within the Site
Collection that owns the gallery. This is effectively a "macro" (my
term) that captures the differences between a List created directly from
the underlying List Definition and the List captured and is utterly
dependent on the underlying List Definition. Again, these are far less
useful with the advent of Features and Solutions in WSS v3 but must be
mentioned for completeness. It is NOT possible using STSADM to make a
List Template STP available to every Site Collection within the Farm.

List Instance: When a new List Instance (aka List or Library) is
created, rows are inserted into tables in the content database defining
the metadata that indicates that a List exists. ListItems are inserted
into the AllUserData table (I think).

List View: When a List View Web Part is added  to a page or you choose a
List View for a List Instance, the data displayed represents a "window"
(my term) into the ListItems found within the List Instance that the Web
Part is configured to show. Much like seeing only a portion of the rows
and columns  within an Excel spreadsheet. Creating/altering a "List View"
just defines what is presented within that "window". Deleting a List
View Web Part doesn't alter the ListItems stored within the List
Instance whereas deleting a List Instance will automatically remove
every List View from the Site Instance.

Consistent use of the terms Definition (for the physical files in the 12
Hive), Template (for the characteristics defined in XML to display from
the Create page), and Instance (for the metadata in the content database
indicating the existence of a container) for both Sites and Lists will
diminish confusion when asking/answering questions and discussing ideas.

Having a good understanding of these concepts should help everyone
understand the difference between the Announcements List View Web Part
displayed on the home  page of any Team Site, the Announcements List
Instance link displayed on the Quick Launch and All Site Content page of
any Team Site, and the Announcements List Template displayed on the
Create page.

 
Answer #7    Answered By: Clayton Berry     Answered On: Jan 19

Not sure what happened to my awesome formatting (bolding). Don't miss
the key part of this message:

Consistent use of the terms Definition (for the physical files in the 12
Hive), Template (for the characteristics defined in XML to display from
the Create page), and Instance (for the metadata in the content database
indicating the existence of a container) for both Sites and Lists will
diminish confusion when asking/answering questions and discussing ideas.

 




Tagged: