Beware the UI Feature List

I know that I promised to post about features, but I came across an interesting bug in the MOSS feature user interface that needs to be discussed. I will continue on with the feature posts. Today I was recreating our site using the features I have been working on for the last 2 weeks. In the Sharepoint feature UI you get a list of the installed features in either a site collection or a site with buttons next to them to activate or deactivate the feature. Well I was activating the features when I received a message asking me if I wanted to really deactivate this feature. This did not make sense since the feature was not activated yet. I clicked cancel and went back to the UI for the features. I had clicked on the right feature to activate so I refreshed the page and tried it again. This time the feature activated just fine, so I really didn't think nothing of it.

About 10 minutes later I was doing the same process when I received an error that the content type did not exist. This was odd because the feature I was trying to activate did not do anything with a content type. As a side note right here I need to say that I am not the only one working on this install of Sharepoint. There are three of us working on two separate projects and sharing one 12 hive. This was only a problem once before, but that is another story for later. So I poked into the log files and found that there were some errors for JT features so I mentioned to my colleague Joel that he had some errors in the log. He looked into it and found that the error was his feature but that it was being activated on my site. So I looked into the libraries and lists for my site and sure enough there was his list created on my site.

After more poking around we guessed that the UI for the features list is indexed to an internal list of the installed features. What was happening was I would load the page with the list of features and then Joel would install a new feature that was higher up alphabetically in the list and would push the internal list down one. So on the list I was viewing I would go to activate item 3 and in the internal list it would really be item 4. After we suggested this theory to another colleague, he created a simple test by creating three features that began with z and would create an image that corresponded to the feature id. He then loaded the UI page and installed a feature that began with an a. Sure enough if he went to activate the middle z feature it actually activated the first z feature. So we concluded that you need to (if you have multiple people working on the same 12 hive) always refresh the UI page right before activating a feature to make sure you are activating the right feature or use the command line stsadm command to install and activate the features.

Needless to say this provided some entertainment for us this morning.

Let's start at the beginning.....

To create a feature you first need to define the Feature.xml file. Here is a sample file:


<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
Id="1C552111-5D53-440d-8E6E-50E3B5EB5492"
Title="LFI View Photo Page"
Description="Creates the view photo page."
Scope="Web"
Hidden="false">
<elementmanifests>
<elementmanifest location="Elements.xml">
</elementmanifests>
</feature>

The main areas of this file are the feature node. Here you need to give the feature a unique ID (GUID). You can accomplish this by opening Visual Studio 2005 and clicking on tools. Then select create GUID. While working with feature files, I have noticed that some attributes require the curly braces around the GUID and some don't. You may have to follow the feature documentation to figure this out. The MSDN has good definitions of the elements and the attributes for the elements.

http://msdn2.microsoft.com/en-us/library/ms439657.aspx

The other attributes of the feature element are mostly for your own benefit. The title and description will show up in either the site features or site collection features list. The scope determines where the feature will be installed. For most situations this will be "Web" if you want to deploy the feature to the entire site collection or "Site" if you want it available to the subsites. The hidden attribute determines if the feature will show up in the feature list. If you want to be able to see the feature to activate it, you need to set this to false.

The ElemenetManifests element contains an ElementManifest element that has one attribute, Location. This attribute tells the feature where to look for the rest of the information to activate the feature. In the next post I will begin looking at the Elements.xml file. You can name this file whatever you want, but I find having a convention like naming them all Elements.xml keeps things neat.

I'll Have the MOSS with all of the Features

The next few posts will be about MOSS features. A feature is nothing more than some XML files and any other parts that you needs to create a list, or custom master pages, etc. The feature consists of a Feature.xml file, another file that can be named anything, and then folders and files that contain images, master pages, page layouts, CSS style sheets, etc. I will be explaining the layouts for the Feature.xml file, the other XML file, and how to create features that accomplish specific tasks such as adding master pages, creating custom columns, creating lists, and creating document libraries.

Is Your CSS !important?

Today while working on the LFI project, I was creating a page layout for the pages that display a link to the CSI specifications for the products. I added a summary links web part to the page and it accomplished the task that I wanted. The problem was the default color scheme and design that the web part employed. It would never match the color scheme of the current LFI site.

I began where any other Web desgner would and created a CSS class in my external style sheet to change the color to the more appealing green. I added two classes:

a.CSILink {
color: #457E54;
text-decoration:none;
font-size:9pt;
font-family: Arial;
}
a.CSILink:hover {
color: #497c21;
text-decoration:none;
font-size:9pt;
font-family:Arial;
}

I tested the classes and found that the anchor was not changing color. When I rolled over the anchor the appropriate class was being used.

Now knowing the MOSS has thousands of CSS classes and XSL sheets for design, I began to poke into the XSL style sheet for the web part and modified the sheet by copying one of the templates and creating my own. We had done this before for antother part of the site and it worked nicely. Not so much this time.

The style was not being applied no matter how I modified the CSS and XSL sheets. I called over my fellow employees and they looked over the CSS and aspx pages and could not find anything wrong. We tried a few other methods when Art suggested we add the word !important after the color for the anchor tag. I had never heard of this keyword before and did not know what it did, so I placed it into the CSS sheet and tested the style.

This time it worked! There was a small glitch that the hover style did not work now, so I had to go back into the style sheet and add !important to the hover style as well.

Art explained that the !important keyword says that this style should be applied over all others. The only explanation for why it wasn't working before is that somewhere in the Sharepoint CSS classes there is one that specifies an anchor tag in the same combination that I have but that none of the links in Sharepoint have a hover feature, so the hover class worked fine.

Riding the CAML

As a developer, if you want to customize MOSS to any extent, you will need to familiarize yourself with CAML, or Collaborative Application Markup Language. On the current project that I am working on, we needed to create a page in Sharepoint that would display four images across the page to display the product images. Thinking we were going to need to create a custom page for this content, we started the long journey of research that seems to come with a MOSS project. Our researching led us to modifying pages using CAML.

The language itself is not hard to understand. Basically, it allows you to make universal changes to a site. Microsoft uses CAML extensively in MOSS. Some vital links that any developer needs when delving into the black abyss of CAML are included below, the first link is an introduction and the second displays some examples of using CAML to do various things in MOSS.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
spsdk11/CAML_Schema/spxmlconCAML.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
spsdk11/CAML_Schema/spxmlconhowto.asp

Another important aspect of CAML and MOSS is knowing where to look for it. This link will show you where CAML files are located.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
spsdk11/CAML_Schema/spxmlconCAMLlocation.asp

So how did our project work out? We ended up not needing to make a custom page, we found a Web part that would accomplish what we needed and then we extended it to get the final touches.

Although we did not use CAML in this part of the project I am sure we will be coming across it again since it is such an integrated part of MOSS.