The pages that are opened with ?Cmd=* function (from dbutil.vbs and store.vbs) have different sources, html, xsl, asp....

But, to cut the long story short -

the yellow line ( #ffcc00 ) you want to change can be found in the following
files :

Checkout.asp
CreateSubscription.asp
dbcatalog.xsl
dbcontent.xsl
dbedit.xsl
dbview.xsl
EditProfile.asp
ErrorSummary.htm
layout.xsl
managediscussions.asp
NewFolder.asp
Rename.asp
standard-office.css
standard.css
UploadFile.asp
VersionHistory.asp
wpedit.xsl

I didn't follow the function all the way, but I think the best way is to change "#ffcc00" into the color of your (or

costumers) choice. That way all pages that are generated by using the files from this list will be affected.

Tihomir Jaksic

We have a script running which performs authentication successfully, it goes like this:

objConn.Provider = "MSDAIPP.DSO"
objConn.Open strWorkspaceurl, strUsername, strPassword

Where strWorkspaceurl is http://myserver/myworkspace. strUsername is the local administrator on the SPS server and strPassword is the password of this administrator. We hope this helps.

Nikander Bruggeman
Margriet Bruggeman

Look on my Downloads page, there are some alternatives there.

The thesaurus is located under \Data\FTData\SharepointPortalServer\Config. It is an xml document and you should be able to modify it using notepad or word pad. Make sure that you keep the document well formed.

DBishop

Thesaurus: tseng.xml
Noise words list: noiseeng.txt

Yes, but you have to customise the SearchResultsPart.xsl file. Look for the <A tag, and add the target="_new" that does it for me. The XSL file is located in the Portal/Resources folder.

Pierre

The file: type URL is as far as I know only supported by the Exchange OLEDB provider, not by the Internet Publishing Provider, which generally is used through PKMCDO.

Jan Cirpka

*Abstract*
This document describes how to create static and dynamic portal web parts using ASP.NET.

*Background*
SharePoint Portal Server is based upon the Digital Dashboard specification which defines 2 categories of web parts; static and dynamic. The <ContentType> property within the Web Part XML schema is an enumeration that identifies whether embedded web part content is rendered on the client or server.

Value in schema

Meaning 0 The content is HTML

1 The content is VBScript that is executed on the Web server
2 The content is JScript that is executed on the Web server
3 The content is valid XML, transformed using values provided through the XSL or XslLink properties.
4 The content or ContentLink is a valid ASP.NET user control.

*Creating .NET portal components*

Within the .NET world, Content types 1 and 2 basically become obsolete because they're limited to executing legacy COM-based script within a single function. These web parts are susceptible to the myriad problems associated with COM such as memory leaks and buffer overflows.

Although SharePoint is unable to render .NET components on the web server, there are some tricks ("hacks" actually) to using ASP.NET in your portal solution.

Simply setup your web part with ContentType = 0 (HTML) and set the ContentLink property to the path of an ASP.NET page. The result may look like:

<ContentType>0</ContentType>
<ContentLink>mypages/webpage.aspx</ContentLink>

This web part configuration will instruct the client to request the "webpage.aspx" ASP.NET page, which in turn will render via the ASP.NET web service within the portal dashboard.

You may need to set the <RequiresIsolation> property to true (1) to get the page to render correctly. This property just emits an HTML <IFRAME> tag with your content link property set as it's source.

Although the ASP.NET page referenced by the web part may emit dynamic content, it's still considered a static web part within a portal context because the server is unable to dynamically render and cache the web part itself.

A more elegant solution is to render the ASP.NET code within the portal server, thus making the web part page-aware and allowing CGI parameters to be dynamically passed into them.

The .NET development team's answer to this problem is the user control (*.ascx). .NET user controls make excellent web parts since they represent "pagelets" of web-based information.

By simply extending the Web Part schema to include a <ContentType> 4 that represents a .NET user control and hosting the web parts on a .NET portal server, developers can leverage the benefits of 100% managed code, inter web part event raising, .NET server controls, control caching, session management, multiple languages (no more spaghetti scripts), and the .NET common libraries.

When ContentType is set to 4, the portal server will attempt to render any ASP.NET code found within the <Content> tag. If Content is null, then the server will attempt to load the control found in the <ContentLink> property.

The Passage Portal Application Server found at http://www.cubiccompass.com is an example of a .NET web part portal server.

References:

Digital Dashboard Resource Kit 3.0 Help File
[Online] Available http://www.cubiccompass.com/wikinet/docs/ddrk30.chm

Cubic Compass ContentType Extensions, Cubiccompass.com
[Online] Available
http://www.cubiccompass.com/wikinet/Wiki.aspx?ContentType

Mike Leach

I looked into this some time ago and even talked to MS about it. There take was the DocID was not intended to be used as a "key". I beleive that not only is it not indexed or retieveable, but a new version of the same parent doc will have another ID.