New SharePoint Features

I'll take Heather's cue and refrain from judging the new SharePoint features until I've had a chance to get my hands on them, but here are a few thoughts based on Fitz's post from PDC:

• RSS. Everything about sites, lists, libraries, etc., can be syndicated via RSS automatically.
  Blogs and Wikis. Templates and features in the box.

Excellent. This will save a great deal of frustration with email-based alerts.

• Content Types. These aren’t just like SPS 2001’s document profiles. They define sets of metadata, but they also contain view information. And associated workflows. And events bound to them (synchronous or asynchronous). And you can have more than one in the same list/library.

Hmm...not sure. Will this help with the problem of retrieving views via web services?

• Workflow. Windows Workflow Foundation is embedded in WSS. It’s used everywhere.

I want to jump up and shout for joy...BUT...if they don't include a visual designer embedded into the UI ala Nintex SmartLibrary then they will have completely missed the boat. LOB managers, content editors, and designers cannot AND WILL NOT be forced to rely upon developers to create workflows.

• Recycle Bin. We did it. It’s scoped to a site and captures deleted documents, items, etc. It has a user restore and an administrative restore.

Now that deserves a jump and a shout (assuming, of course, that it applies to SPS as well).

• Per-item security. Even on list items.

I can die happy now. Is it really true? Oh, please, let it be so!

• FrontPage has evolved into a feature set that makes it truly a SharePoint site designer. (Ghosting’s still around, but it won’t be a problem anymore. I’ll explain why in an upcoming post.

Interesting. This could make the job of customization a bit easier, which would make my life a much better place.

• Forms services in Office “12” servers. That’s right — design a form in the InfoPath rich client, publish it as a SharePoint site, and it can be either viewed/filled out in the full smart client or in a browser as HTML.

One word: S-W-E-E-T!

• Search. Better APIs. Better results. Alternate search suggestions (misspelled words,etc.). A highly customizable default Web-based UI.

I'm definitely excited about this. Search is a bit of a blessing and a curse, so any improvement will be welcome.

• Office “12” servers will also contain a Business Data Catalog, a facility that registers LOB application data and Web services. Once that’s happened, BDC-aware Web Parts can pull data from them, we can index them, and a lot more. There’s a session on this tomorrow.

Not sure about this one. Sounds interesting, though.

• Office “12” servers will also be able to take a spreadsheet published to a SharePoint site and reneer it as an HTML application.

Like it but not sure how useful that will be...

• Mobile views of SharePoint lists. That’s right, a way to render a list on a mobile device.

Very nice.

• Lists now have a Business Data type that will use the aforemntioned Business Data Catalog

Unsure on this one. Need more info.

• Access will be able to treat SharePoint site data as fulll-blown data sources.

Yeah, baby!

All in all, it sounds promising. So, looking back, how'd they do with regards to my various predictions, rants and ravings? Not bad, I'd say.

Extreme SharePoint Design: Modifying The 'Grouped By' Headers

When applying grouping to a list view, the default style sheet prepends the field label and a colon to the group header. While this may be helpful in determing what category the data is grouped by it is certainly not the most visually appealing method. Fortunately, the style can be modified in the stdview.xml file located in the XML folder of your custom site definition (you are using a custom defintion, aren't you?). Locate the following code on or about line 278:

<GroupByHeader> <HTML><![CDATA[ <TBODY id="titl]]></HTML> <GetVar Name="GroupByLevelString"/> <HTML><![CDATA["><TR]]></HTML> <Switch> <Expr><GetVar Name="GroupByIndent"/></Expr> <Case Value="0"> <HTML> <![CDATA[ class="ms-gb" ]]> </HTML> </Case> <Default> <HTML> <![CDATA[ class="ms-gb2" ]]> </HTML> </Default> </Switch> <HTML><![CDATA[><TD colspan="100" nowrap><img src="/_layouts/images/blank.gif" alt="" height=1 width=]]></HTML> <GetVar Name="GroupByIndent"/> <HTML><![CDATA[><a href="javascript:" onclick="javascript:ExpCollGroup(']]></HTML> <GetVar Name="GroupByLevelString"/> <HTML><![CDATA[','img_]]></HTML> <GetVar Name="GroupByLevelString"/> <HTML><![CDATA[');return false;"><img id="img_]]></HTML> <GetVar Name="GroupByLevelString"/> <HTML><![CDATA[" src="/_layouts/images/minus.gif" alt="]]></HTML> <HTML>Expand/Collapse</HTML> <HTML><![CDATA[" border="0"></a> ]]></HTML> <GetVar Name="GroupByField" HTMLEncode="TRUE" /> <HTML><![CDATA[ : ]]></HTML> <GetVar Name="GroupByValue"/> <HTML><![CDATA[</TD></TR></TBODY>]]></HTML> </GroupByHeader>

Remove the field label and colon by deleting or commenting out the following code from this section:

<GetVar Name="GroupByField" HTMLEncode="TRUE" /> <HTML><![CDATA[ : ]]></HTML>

You may also wish to change the drab gray style by modifying ms-gb and ms-gb2 or assigning a class in a custom style sheet.

Once you're finished editing the file, save it and reset IIS. Note that this is a global change that will affect all lists in the definition. For localized changes, create a Data View Web Part and modify the XSL accordingly.

Compiling Locally Without SharePoint Installed

A vexing issue for SharePoint developers is the need to have WSS installed on your development machine due to DLL dependencies. Anyone who has tried to compile a web part in a stand-alone environment has run across the following errors:

The dependency 'Microsoft.SharePoint.Security' could not be found.
The dependency 'Microsoft.SharePoint.Dsp' could not be found.
The dependency 'Microsoft.SharePoint.Library' could not be found.

To circumvent this issue, extract the underlying DLL's from the GAC and copy them to your local machine. You'll need to perform the copy from the command prompt as Windows Explorer does not expose the full directory structure for the GAC. Each DLL resides in a directory with a path similar to the following:

c:/windows/assembly/gac/[Strong Name]/[Version Number]__[Public Key]/[Strong Name].dll

Once you have the DLL's you can include them as a reference in your project and compile without errors.

SharePoint Blogsearch Expands to Mexico

For our friends from Latin America, Luis Du Solier's Spanish-language blog has just been added to the SharePoint Blogsearch index. As I grew up in El Paso (which is right on the Mexican-American border), I am quite fond of our neighbors to the south and glad to see Luis is making a contribution to the SharePoint community. If I continue to get multilingual submissions I'll create a content source for each language to make native searches a bit easier.

Para todos nuestros amigos latinos, bienvenido por favor Luis Du Solier a la familia de SharePoint Blogsearch. Como soy de EL Paso, Tejas y orgullosa de nuestros vecinos al sur. Estoy alegre ver que Luis está haciendo una contribución a la comunidad de SharePoint. Su blog es muy bueno, Luis!

Database Permissions

I'd been wondering for a long time how the ACL's in the SharePoint database work. In fact, I was just discussing the issue this morning with a colleague when - voila! - Paolo posts the answer.

Now that's what the blogosphere is all about!

Working with SharePoint Lists

A colleague of mine is working on a custom application which makes extensive use of SharePoint lists to store data. He has written a webpart that rolls-up the XML data from various lists, transforms it with XSL, and renders it in a way-cool tabbed control. While putting this together, he found this link on Using Data from Sharepoint 2003 Lists. Very cool and a big thanks to Paul Ballard for his post.

Perhaps if we needle him enough, Scot will be nice enough to post his nifty code and show us how it's done. Or, he could just get a blog and start sharing his wizardry with the rest of the world, eh???

Hiding the Site Settings Link

One of the most common user complaints in new implementations is links that are exposed to users who don't have rights to access the content - like the 'Site Settings' link at the top of every page. Heather Solomon has figured out how to hide that pesky critter for good.

Where does she find this stuff? More importantly, how on earth would I make it through the week without her blog???

Heather for MVP!!!

SharePoint Templates Article

While following up on a comment from Claudia I found her article on WSS themes. Good stuff - go check it out.

Extreme SharePoint Design Series

Site definitions and custom templates are essential to delivering a customized SharePoint experience. While there are several good resources for information on how to deploy a custom site definition, such as the SDK, MSDN, and Heather Solomon's excellent site, there aren't many in-depth examples of custom code for UI modifications. It's time to change that, don't you think?

Over the next few months I'll be presenting "Extreme SharePoint Design", a regular blog series with advanced tips and tricks for designers. Topics won't be in any particular order, just cool stuff as I come across it with lots of code to copy and paste. Watch this space for updates, often daily but sometimes weekly, depending upon my travel schedule.

As always, feel free to share your thoughts or suggest ideas.

UPDATE: I'll be posting a lengthy article next week on customizing various context menus (Actions, Views, etc.) - it's a bigger task than I thought at first but well worth the effort. Stay tuned!

Extreme SharePoint Design: Site Definition File Differences

Creating a custom site definition from scratch can be a daunting task. Each file in the folder structure serves a particular purpose and many of them vary slightly from folder to folder - allitems.aspx is not the same in DOCLIB as it is in VOTING (see Heather's post for a complete list of files in each folder). Due to slight variances, there is no way to do a global search and replace to copy your customizations. Getting the correct code in each file is essential to maintaining SharePoint's functionality. Isn't there an easy way to solve this problem?

The answer is - sort of. First, begin with a blank template file that has all the necessary components for that type (allitems.aspx, for example). Remember that many page elements require specific registrations and script files, so make sure your [HEAD] tags include all the necessary code blocks. Once you have a working template file, copy it into each directory, then add the code necessary for each list type.

I have compiled a list of each file type along with the code elements that are unique to each list (folder) below, using the SPS site definition as a baseline (60\templates\1033\SPS). The code goes in various places but I tried to keep it sequential; that is, the first code block (individual blocks are separated by ***) goes first, then the second, and so on. Some are contextual (they contain more than just the unique code) to make searching and replacing easier. I also tried tgo keep all script elements together to insure that no code gets orphaned. Once you've modified a couple of files you'll know exactly where to place each block.

Site Definition Original Code (SPS)

Please note that I did not include files that are specific to a certain list type (such as calendar.aspx in EVENTS) only those that recur in multiple folders. In a subsequent post, we'll look at how these files differ from those in STS to show how a custom deployment can seamlessly incorporate both SPS and WSS in a unified design.

NOTE ON CODE SAMPLES: Few things frustrate me more than not being able to cut and paste HTML code into Blogger's editor. You would think they could solve this with a special tag like many discussion forums do, but if they have I sure don't know about it. Until such a thing comes along, all <> tags will be displayed as [ and ]. Sorry for the inconvenience.