Overview of mizmizing Community Server

I have been learning a lot about customizing communityserver
Lately and it occurs to me that it wowould have been easier to do more
Faster if I had an overview of the way CS is built. To that end, I
Will try to codify what I have observed.

Structurally, CS can be
A little confusing because it appears to be a fully implemented Asp.net
2.0 website application. The fact is that it is almost entirely 1.1,
But was built by people who were very knowledgeable about the changes
Coming in 2.0. Whether its the use of master pages and skins, or
Appearance of a global isnullorempty string checking method-the app
Seems to be 2.0. It isn' t; the 2.0 version still uses the home-grown
Skins/master pages and slave other 2.0-seeming features.

In Terms
Of mizmizing the way your website looks or behaves you have to start
With the aspx pages found in the varous folders of the website
Application structure. These pages will point you to the varous skins
Or controls in use. Yet, they will never (besides in controlpanel)
Point you to the code or visual features of the website. All of
Real implementation occurs in the master pages, skins, and views, or in
The control code in one of the specified ded assemblies.

Each aspx
Page will identify some master page (not identifying one explicitly
Means it will use master. ascx) in its Cs: mpcontainer Control
Declaration, and potentially one or more control declarations in
CS: mpcontent controls. The master pages are generally slim, and control
Overall Layout of a page. The actual master pages are simply custom
Controls (ascx files) located in the/themes/[current theme]/masters
Folder of the website application. The most common base implementation
Of a master page is of 3 sections called 'lcr '(left side content ),
'Abc' (body content, and 'rcr '(right side content). You can either
Define controls for every descendent page in these sections in
Master page, or override master page content by declaring Cs: mpcontent
Controls with these IDs on your ASPX page. Skins shocould not implement
These content controls. For example, if you wanted to understand how
Each thing is showing up on default. aspx, you wocould open default. aspx
And find the 'themasterfile' attribute on the page level
CS: mpcontainer control. If you navigate to the homemaster. ascx File
You'll see that the only thing being added here are some style supported des
In a "headerregion", and the 3 content sections. In order to really
Understand where the content is coming from, you have to look at
Controls declared within the various content sections.

A Control
Declaration on a page or skin will carry a custom prefix defined on the
page and the name of the control-this is standard Asp.net
customization. it is important to note such control names because first
-along with the prefix Declaration on the page-it will point you to
the control code in the proper assembly where you can see how it is
implemented. second, the name is almost always identical to the
name of the skin that is used to display the control, with an added
prefix of 'skin -'. by default, all templated controls in CS will load a
skin named "skin-" + [The Name Of The control] + ". ascx ".

while
the master pages generally declare overall sections in which the
various skins will be displayed, the aspx pages, skins, and views
define the HTML and any additional sub-controls along with client or
server side script to control display. I believe it is preferable to
Leave all HTML Out Of The aspx pages, and rely on the skins for this
implementation. as a simple example, if we look this time at
'login. aspx 'we'll see that the master file is not declared (so it is
master. ascx) and all content is controlled by the "Cs: Login" control.
that means this control is declared in the
communityserver. controls. login class, and its layout will be found in
/themes/default/skins/Skin-Login.ascx. sure enough, the layout of the
login page is on this skin. the functionality (application logic) of
This page is found in the class file.

This brings us to
Important lesson about how all this comes together in the application:
The class files control behavior by "wiring" properly named controls
Certain events or operations on the back end. For instance,
Defaultbuttontextbox control for the password on Skin-Login.ascx must
Be Named 'Password' in order for the control logic to work properly.
This magic takes place in the "attachchildcontrols" method of each
Control which manipulates its members on the back end.

Using
This basic knowledge we can then start to change how our website looks
And behaves. Each templated Or skinned control (those with skins) has
Property "skinname" which it inherits and will consult as the proper
Skin to apply if it has been supplied. Recall that if this property is
Null, then the skin named "skin-[Control name]" will be applied. Note
That I have run into controls which ignore this property, but it is not
The norm. As such, if we want to change how login. aspx looks we shocould
Create a new skin, and provide the name as a "skinname" attribute on
The control declaration on login. aspx. I think you shoshould copy and
Rename the skins rather than alter them because it will save you
Headaches later if you try to upgrade CS, and clearly shows where you
Have made changes. When you fill in the "skinname" attribute you use
The full file name of the skin you created. This name may need
Include the sub folder when you are dealing with blogs and galleries (I
Don't really have the nuances of these exceptions mastered
Generally the controls from these assemblies automatically determine
The folder which contains their skins so try that first. aspx pages in
The blog subfolder are really an exception to most things I have said
So far anyhow and I'll cover that later ).

If you want
Change the way login. aspx behaves you'll need to modify the login
Class. Again, rather than modifying the class provided with Cs, you
Shocould create a new assembly for your controls and extend the login
Class via inheritance. You can change the name to match your modified
Skin if you have one, or leave the name the same. The only name
Collision issue I had working in vs 2003 was with the namespace
Including the communityserver. Controls prefix (so don't use
Mycompany. communityserver. Controls, try CS. Controls)-The controls
Themselves are all fully prefixed in the aspx and ascx pages so there
Is no confusion there. I have found that the control classes aren't all
Designed real well for extension, so I often have to copy base class
Methods In order to modify behavior, but I am trying to guarantee that
An upgrade will still work, and that I know where my code begins and CS
Provided code stops. Once you have your class built and the Assembly
Added in your web project, you can change or add the tagprefix
Declaration on your page and repoint the control declaration to your
New custom control.

Blog skin exception

Blog
Aspx pages generally declare which view they are using, rather than
Skin. These "views" are found in/themes/blogs/[current blog
Theme]/views and have the name "View-[view name]. ascx. Views contain
Layout templates with various blog controls in them. Each control then
Has a skin named the same way I mentioned above for other controls.
However, these controls have their skins in the/themes/blogs/[blog
Theme]/skins folder, rather than with the other skins.