How SmartPart definitions on a SalesLogix web page are rendered

In the SalesLogix Application Architect, each main page has a definition of the various components found on the page.  These are things such as smart parts (tabs, detail views) and modules.  If you look at something like the Account page (found in the SalesLogix Application Architect under the VFS…Portal Manager…Sage SalesLogix…Pages…Account Detail) you can see the various smart parts that comprise the UI that is rendered when a user navigates to the Account area of SalesLogix:

The smart parts listed here have several attributes such as the target workspace and show in mode.  The Target Workspace defines what section of the page the smart part gets rendered in:  Main Content, NavBar, TabControl, Task Pane, Toolbar, and DialogWorkspace.  The show in mode defines in what view mode the smart part shows (List, Detail, Both).

Once these attributes are defined the SalesLogix web deployment reads these settings and renders a main ASP page and code file.  These files are found in the root of the portal deployment (typically in the SLXClient folder).  For the Account page you will see an Account.aspx and Account.aspx.cs file.  If you examine the code file you can see that there is an OnLoad event which defines the following actions:

base.OnLoad(e);
SetTitleBar();
MenuService mnuService = new MenuService();
this.Page.Form.Controls.Add(mnuService);
this.PageWorkItem.Services.Add<IMenuService>(mnuService);
LoadLayout(this.Master);
LoadNav();
LoadMenu();
LoadSmartParts();
LoadModules();
LoadTasklets();

All of these methods are also defined in the code file under the Helper Methods section.  The one particular one that deals with what tabs are rendered on the page is called LoadSmartParts. (BTW, you can see here that the LoadModules runs after all of the other events.  That is how this post that Ryan Farley wrote is able to use a module to affect the menus available on the page.)

Lets take a look at what the LoadSmartParts method is doing.

You can see that there are various IF blocks inside this method that checks to see if the IsModeMatch() result and the IsRoleMatch() result return the values as defined on our Page definition found under the Portal Manager.  For instance we can see for the main detail part of the account screen we have the following conditional statement:

    if(IsModeMatch(“Detail”) && IsRoleMatch(“”))
            {
            }

Inside the condition we can see that the script loads the corresponding control which is also defined under the Page definition on the Portal Manager.  Throw in some error trapping code and the code that then actually renders the smart part in the correct Workspace and you have the full code block:

if(IsModeMatch(“Detail”) && IsRoleMatch(“”))
{
    Control AccountDetails = null;
    try
    {
        AccountDetails = LoadControl(“~/SmartParts/Account/AccountDetails.ascx”);
    }
    catch (Exception ex)
    {
        AccountDetails = new LiteralControl(ex.Message);
    }
    AccountDetails.ID = “AccountDetails”;
    this.PageWorkItem.Workspaces[“MainContent”].Show(AccountDetails, new SmartPartInfo(GetResource(“AccountDetails.Title”), GetResource(“AccountDetails.Description”)));               
}

So there it is.  From definitions of the Page on the Portal Manager to the actual deployed files. 

A helpful tip: In the past I have seen where a smart part was added to a Portal Page yet it failed to show once the site was deployed.  Under some circumstances the system does not recognize a smart part was added to the page.  This can be confirmed by looking at the deployed code file for the page in question.  If the condition block is not present to load the smart part you can typically force the system to recognize it by modifying the Page definitions again and then re-deploying.