Web Parts can only span  the Web Part Zone. If you want to modify the page  (say
default.aspx) you can create  a new site def (copied from say STS) and edit the
default.aspx page, adding as many zones as you like. I have a STSDEV definition
which is simply a copy of STS with a header and footer zone added.

I have worked with ASP.NET C# Portal code and they have a the
ability to modify how each module (Web Part) is framed. You can
develop custom container with background colors and grafics as will
as custom boarders to the module (Web Part). How can I accomplish
the same thing in STS?

For an out of the box web  part or a custom web part?

For consistancy sake...both! Idealy I'd like it to chage the
default for all web  parts on the site?

Is this possible?

For custom web  parts the sky is the limit since you are in control of the
interface display. Mucking with OOTB web parts  gets trickier.

There are the UI modifications you can do through the web part admin
screens, where you can change the style and what not. Those are pretty
basic.

You could look into creating a custom view for the web part:
msdn.microsoft.com/.../odc_SP2003_
ta/html/ODC_WSSAddingCustomViewStyle.asp

You can create  a custom cascading style sheet and override the style
statements using the IDs and class names already in the OOTB code. This is
pretty restricting since you have to work within what is already a part of
the web part.

It is a snap to add formatting for the Content Editor Web Part or your
custom part, but trying to make the changes look the same across the board
for all web parts will get more difficult and will involve some work.

Another option if it works for your situation is the Web Part Page
templates. When you go to create  new content and you scroll to the bottom
of the Create screen there is an option to create a Web Part Page. There
are several templates to choose from there, including one without the Quick
Launch area. Those pages  are then stored in a document library. You can
set up hyperlinks to those pages from your main site for access.

Great idea, but unfortunately I need to do this on the root page.

On the subject of web page  document libraries, do you find it easier or better to take this approach, or to add a virtual directory to host normal ASP/ASP.NET pages? I can see that a web  page library would be easier to implement, particularly for one-off pages, but think that it would be difficult to maintain a coherent navigation system on a large site using this approach.

I admit I have mixed feelings about web  part pages, but they have been used rather successfully in my organization and the content owners seem quite happy with them. Often several pages  are created and stored in a library that is then “hidden” from view and a navigation system is added to the site that links to the pages. What has been used most in my personal experiences is the tab nav (heathersolomon.com/.../1434.aspx).

I have also used web part pages for one offs to store policies, procedures, etc. Stuff that can be linked to and sit off on its own because it is strictly for information use only and a detailed nav is not important.

I also have ASP.net pages stored off the web server. Those work just as well. I have a template wrapped around them that looks just like SharePoint and the transition in-between is rather seamless.

The big difference is content updates. Web Part Pages allow the owners to change the text, where updating the ASP.net pages require a more technical person and interaction with the server.

Can I assume that your ASP.NET pages  are in an unmanaged path or possibly in a separate virtual directory?

[slight change of topic here]

What I would really like to do is have two  separate WSS sites on one server, along with a standard ASP.NET web  site. This would allow me to jump out to standard web pages when I need to do some high-end, out of the box feature, while supporting two organizations with the WSS sites. Each site would have its own template/CSS for banners and page  decoration. Of course, just to make things interesting, my boss wants Project Server to be loaded as well. So ideally I am looking at a structure like the following:

<root> ASP.NET site
|
|- default.aspx
|
|- <\Org 1 - top page WSS>
|
|- <\Org 2 - top page WSS>
|
|- <\projectserver>

Is this feasible to do? Can I embed separate virtual directories under a standard site, or do they need to be in a peer relationship? I haven't experimented with virtual servers/directories enough to know which way to go.

It sounds as though this would then be applied to all of the pages  in the site?

What I am trying to do is to set up a "pseudo-portal" top page  in WSS, but retain the normal structure (i.e. Quick Launch, etc) in sub-sites.

I typically use one of the spstdX.aspx pages  in the smartpgs folder of the site definition as a starting place. I hide the title zone (required by the page) row with CSS. Then you can build anything you want.

I like to put a vertical zone, followed by a horizontal zone, followed by a vertical zone, followed by a horizontal zone. This way I can construct screens with nearly any shape.

Has anyone here done a comparison between Sharepoint and any open ASP.NET based CMS Portal Applications like DotNetNuke’m or Rainbow?

Does anyone have direct experience “porting” WebParts to an open source CMS like these?

Does anyone have direct experience “porting” modules from an open source CMS like these to Sharepoint?

I have some very specific questions for anyone that has traversed these waters…