Archives
-
The Collective vs. the Individual... a possible first step? Or just Google...
Bil Simser is wondering if it is possible to have a collective place to collect all information on SharePoint. See his post at http://weblogs.asp.net/bsimser/archive/2005/06/27/415834.aspx
In my opinion one of the best ways of getting “knowledge” out is through weblogs. This is exactly what a lot of people are doing. In out company everyone has access to its own internal weblog, and this is the way information is best shared within our company.
When I was setting up these weblogs I was also planning to create automatic categories you could assign your weblog post to, based on the SharePoint topics struxture, and based on the list of projects we are working on. It never came that far.
I still think it is a good idea, and an “easy” way to collect one part of the collective knowledge on SharePoint. Can’t we come up with a set of common post categories we assign our weblog entries to? Each blog engine support categories and separate RSS feeds on them. We could collect those RSS feeds into one big RSS feed, and based on these RSS feeds create a site that displays all collective knowledge categorized to a fixed set of topics…
But then the biggest issue: comming up with a set of common post categories... I’m afraid that part will brings us into taxonomy hell… to what level of detail do you define categories, how many categories are needed, etc. etc.
Hmmm… maybe Google isn’t so bad;-)
Talking about Google: How about http://www.google.com/Top/Computers/Software/Document_Management/Products/Microsoft_SharePoint
We could link all our information in here..
-
SharePoint versioned document magic
Bil Simser describes in post http://weblogs.asp.net/bsimser/archive/2005/06/22/414258.aspx a “bug” he encountered with versioned document libraries. When a document is saved in a versioned document library, the timestamp of the then latest version of the document gets changed to one minute before the time stamp of the new saved document.
This problem is related to one of the biggest problems I have with document libraries. A document in a versioned document library becomes a "version" when a newer version of the document is saved.
An example:
I create a document called “VersionedDoc.doc” in the document library “http://myserver/personal/serge/VersionedDocumentLibrary”.
This document is URL addressable at: “http://myserver/personal/serge/VersionedDocumentLibrary/VersionedDoc.doc”.
As soon as I save a new version of the document, this version becomes “http://myserver/personal/serge/VersionedDocumentLibrary/VersionedDoc.doc”, and my first version of the document becomes: “http://myserver/personal/serge/_vti_history/1/VersionedDocumentLibrary/VersionedDoc.doc”. This means that at the moment of saving the new version of the document, the previous version of the document gets moved to a new location. It is not already created at this location. This leads to the timestamp issue. By the way: the next version is saved as: “http://myserver/personal/serge/_vti_history/2/VersionedDocumentLibrary/VersionedDoc.doc”.
Besides the fact that the version naming schema leads to weird URL’s, it also means that you can’t provide a URL to a version of your document upfront.
If I remember correctly, SharePoint Portal Server 2001 had the possibility to address the latest document as http://…/VersionedDoc.doc, and versioned versions as http://…/VersionedDoc.doc$versionnumber. If version 4 was the latest version it was both URL addressable as http://…/VersionedDoc.doc and http://…/VersionedDoc.doc$4. It is a pity that Microsoft decided to leave this naming schema.
-
About Site Definitions and making waves inside Microsoft walls;-)
A great post by Ryan Rogers on the Site Definitions “challenge”: http://blogs.msdn.com/ryanrogers/archive/2005/06/04/425148.aspx
He was the guy I cited in my post http://weblogs.asp.net/soever/archive/2005/05/26/408948.aspx, without knowing it;-)
It is good to hear that weblogs post can make waves within Microsoft walls…
It is good that it is possible to do the modifications through code, as Ryan stated. We have an escape! A costly one if you have MANY site instances, because the pages you modify will become unghosted (a copy is created) in the database… you remember, that issue you try to prevent by not modifying pages through FrontPage;-) But hey… storage is cheap these days!
Another issue I had are the MySite pages… you don’t want to have to change 30.000 My Site pages if you need a small modification to the private or public view. Good thing is that the MySite public and private pages are handled differently from normal sites… if you modify the MySite homepage as an administrator in “Shared View” it changes for all users! These pages are in a special location:
Private homepage MySite: http://servername/MySite/default.aspx
Public homepage MySite: http://servername/MySite/Public.aspx
Modifying these pages in the site definition is probably unsupported, but making modifications through the “Shared View” or using FrontPage not (yet?) as far as I know.
-
More tunes in the "unsupported" blues... adding web parts to Forms pages unsupported!
Adding web parts on forms pages are “banned”, there goes my MacawDiscussionBoard list template!! Welcome to the wonderful world of SharePoint!
http://www.bluedoglimited.com/SharePointThoughts/ViewPost.aspx?ID=176
But this one is even worse than the Site Definitions: http://weblogs.asp.net/soever/archive/2005/05/26/408948.aspx
You may not even modify the template page before instantiating, or the instance of the page after creation…. This is in my opinion again a major problem!
Time to get a list of what is unsupported, but will work…