DYNAMIC CONTENT CONTROL
SUBCOMPONENT HTML PAGES AND E-STORE FRAMEWWORK
Sections:
Content Sensitive Content (CSC) DB based content
Editing Subcomponent Html Pages
Debugging Subcomponent Pages
Primary Subcomponent Pages
Selectable Skins
Content Rendering Engine
Main Subcomponent Content Rendering Page
Subcomponent Form Rendering Engine
This information is only applicable to sites that are using the SendSafe E-Business framework.
E-Commerce websites and dynamic content dynamic content websites generate content on-the-fly in several ways:
Content Sensitive Content rendered page data uses static and dynamic content obtained from database records instead of subcomponent files. See: CSC for more information.
Advertisement content uses static and dynamic content obtained from database records. See: Advertisement system for more information.
EDITING SUBCOMPONENT HTML PAGES
Since a dynamic content website is not HTML, you cannot edit an entire page with HTML editors like FrontPage. Some parts of the dynamic content are derived from static HTML subcomponent pages. You can edit these subcomponent pages yourself. These partial pages can be accessed via FTP and/or uploaded via CSC Admin pages.
FrontPage is not a good tool because it adds extraneous HTML to every page it touches and as a result it does not yield professional results. We recommend using either notepad.exe or a programmer’s text editor to edit the HTML.
There are subcomponent pages for the header, the left or right column, and the center of the page column (for non-product browsing and shopping pages). There are certain requirements and rules for modifying these subcomponent pages. There are also subcomponent pages called page toppers which are dynamically inserted into product browsing pages.
1. To modify your website, all Editing and FTP access should be done with care and always keep a backup of all the files you change.
2. The site is ready to support multilingual operations. Please let us know if you would like to enable multilingual support (additional labor costs apply).
3. To Edit a subcomponent page you will need to use FTP to upload and download files. The files you will be editing can be found in the /en/ subdirectory (where /en/ is the universal language code for English; if your site also supported Spanish there would be an /es/ subdirectory containing Spanish content pages). In this subdirectory your will find HTML subcomponent files which comprise all the available areas or zones that you can edit on a given page.
4. Subcomponent files are not stand-alone web pages AND must not contain any page setup HTML tags. i.e. <HTML><HEAD><META></HEAD><BODY></BODY></HTML> are not allowed.
5. When editing subcomponent files, keep in mind that they will have a base URL of the website, not the /en/ subdirectory. The /en/ subdirectory is the physical location of the file, not the logical location of the rendered result of the file. The practical ramifications of this are: when entering an image tag <img> you would setup the tag as follows:
GOOD: <IMG SRC="images/invisibledot.gif">
GOOD: <IMG SRC="en/images/invisibledot.gif">
BAD: <IMG SRC="../images/invisibledot.gif">
6. All subcomponent files can contain client side JavaScript. For security and reliability reasons, client side Java applets are not allowed without prior review by CPrompt. You can not use any server side programming logic inside subcomponent files.
7. All hyperlinks found in subcomponent files must use JavaScript helper functions (except for off- site links). Use of any other type of hyperlink can break chain of custody and lead to customers (with cookie problems) being logged out unintentionally. These helper functions maintain chain-of-custody of customer identification as well as handle SSL. Chain of custody is maintained by the encrypted URL parameters EDI and ZDI; with a fallback of using cookies should chain of custody be broken.
An example of the use of these helper functions is included in some of the files found in the /en/ directory.
Example: The JavaScript <A HREF="javascript:gotoRootURL( 'index.asp' )">home</a> will render as a hyperlink to the home page.
Function Description gotoRootURL( targetHRef ) This function is used for all URLs except https. gotoURLWBURL( targetHRef ) This function is used to go an http page and includes a return link (BURL). This function is used when linking with the shopping cart addtobasket page. i.e. javascript:gotoURLWBURL( 'Store.addBasket.asp' ) gotoSSLURLWOEDI( targetHRef ) This function is used to go to an https page and strips off the EID (customer chain of custody). This function is used to create log off links. i.e. javascript:gotoSSLURLWOEDI( 'store.customerlogin.asp?LOGOUT=YES' ) gotoSSLURL( targetHRef ) This function is used to go to https links and maintain customer chain of custody.
The helper functions can be used with any combination of URL parameters (?) and anchors (#). For exampe:
An easy way to debug rendering of subcomponent HTML files is to include a unique hidden comment in each subcomponent file. This comment can be as simple as the name of the subcomponent file:
i.e. <!-- Engine rendered subcomponent file: common.right.inc.htm -->
One you have all your subcomponent files tagged, you can then use "view source" in the browser and search for these tagged. If you find the tag, you then know the subcomponent files was included. This makes it easy to eliminate file rendering as problem and focus on other areas such as HTML errors. It is not unusual for an HTML error such as a mismatched table tag to cause a properly included subcomponent files to be rendered invisibly.
There are several primary subcomponent pages that are typical used in almost all web pages. These html subcomponent pages are:
The common.right.inc.htm files is very often present. If used this file will always be included before the page specific includes such as: contact.right.inc.htm.
The common.left.inc.htm files is not often present. If used this file will always be included before the page specific includes such as: contact.left.inc.htm.
To enable the display of a category page toppers, you create an HTML subcomponent file and upload it. The name of the file has to match the category. For example: If you had a category of "Apples" you would create a file named: apples.category.inc.htm and upload. When ever the Apples category or its child subcategories are browsed, this page topper will be displayed.
Each Web Page for which you can edit content will have a unique "center of the page" include html file with a corresponding name in the /en/ subdirectory. You will edit this include file to change content. These include files are programmatically included in the appropriate page when it is rendered. For example: to edit the core content for the home page index.asp you would edit the file /en/index.inc.htm or /en/index.middle.inc.htm depending on the layout of the site.
MAIN SUBCOMPONENT CONTENT RENDERING PAGE
There is a general content rendering page called cldr.asp which be used to create an infinite number of general content HTML pages. The incFileLoaderWriter() subroutine as rendering engine which drives this and other derivative page.
The way cldr.asp works is that it loads a unique "center of the page" subcomponent include file from the /en/ subdirectory based upon a URL parameter. CLDR.ASP can also be customized to load an page layout you can imagine: mutliple column layouts, headres, foots, etc.
CLDR.ASP is one of the templates used. This file and its related templates must be worked into the layout you want. This file use the incFileLoaderWriter() subroutine as the major work horse though you can easily mix in any comination of CSC DB managed pages and advertisements.
Example: In its simplest configuration, the following url will load the file information.inc.htm located in the /en/ subdirectory: http://www.mywebsite.com/CLDR.asp?pg=information
You can create any number of pages by using the cldr.asp page combined with any number of xxxx.inc.htm pages that you create in the /en/ directory.
There is a second variation on cldr.asp named cldrp.asp which is used to load dynamically generated POP-UP pages.
All files handled by CLDR.ASP are automatically included in SendSafe automated SEO indexing. To exclude a file from SEO indexing you need to embed the spacial postfix .NL. into the name of the file.
Example: http://www.mywebsite.com/CLDR.asp?pg=information.nl ==> information.nl.inc.htm or information.nl.middle.inc.htm
Page Managers:
The incFileLoaderWriter() Engine works by loading the desired version of a specified HTML subcomponent into the page being constructed. This subroutine incFileLoaderWriter() is used to load: headers, footers, right column, left column content, center of page content, and more. The specific subcomponents which are loaded are determined by the format and layout of the CLDR.ASP page.
SKINS:
The content engine supports loadable multiple skins. The skin for the website is selected by either URL parameter OR by the
domain name of the website being loaded.
The skins are in essance an alternate set of subcomponents and images which are selected automatically by the system.
IMPORTANT: Skin debug information can be displayed at the bottom of the page if the URL parameeter skindebug=yes is added to the URL.
Standard files and items which are controllable by skin prefix:
Controlling Skins:
The basic rules for Skins are:
Order of precidence for Skin selection are:
Skins configuration in global.inc.asp:
Note: all skinFromDomainList() entires must be lowercase
' skins
Application("enableSkins") = true
Application("skinFromDomainEnabled") = true
' all entries must be in lower case
dim skinFromDomainList(1,2)
skinFromDomainList(0,0) = "www.site0.com"
skinFromDomainList(1,0) = "blueskin"
skinFromDomainList(0,1) = "www.site1.com"
skinFromDomainList(1,1) = "redskin"
skinFromDomainList(0,2) = "www.site2.com"
skinFromDomainList(1,2) = "greenskin"
Application("skinFromDomainList" ) = skinFromDomainList
E-Business framework product browsing configuration in pageconfig.inc.asp:
To limit product browsing to items based on skin codes appended to the product type '/skinname/'
skinLimitedProductTypes = false
This flag will limit products displayed by browser.inc.asp to items with skin codes appended to the product type '/skinname/'
productType like '%/" & websiteskinSelection & "/%'
E-Business framework skinnable CSS stylesheets:
Style sheets can be optionally skinned.
skinableCSS = true
Your stylesheets must be named ./en/<skiname>.basicstyles.css with the skinned style sheets located in the /en/ or other language specific subdirectory. You can change the CSS name or directory by editing the includes/megatags.inc.asp file.
Skinned style sheets will work with any client-side script and/or HTML. By editing the includes/megatags.inc.asp file you can easily add cascaded sheets with a common root but different dynamically rendered child sheets.
Optional banner color chip configuration in pageconfig.inc.asp:
The banner color chip is a background color used for navigation, menus, and other trim. This color chip is configured in
the E-Business framework with these settings:
When skins are enabled the E-Business framework will use a bannercolor chip file with a name equal to "skiname." PLUS the the following entries in the config file: themeColorChip, leftborderColorColorChip, coreNavColorChip. This color chip file will always be retrieved from the directory path set in entries in the config file: themeColorChip, leftborderColorColorChip, coreNavColorChip.
Example:
themeColorChip = "en/images/bannercolorchip.gif"
skinname = red
THEN the banner color chip file used will be: en/images/red.bannercolorchip.gif
So the skin name is added as a prefix to the filename while leaving the path intact. The logic which does this can be found in the pageconfigcode.inc.asp file.
When skins are enabled the Past Purchase List and WishList the mini-cart will use a "hard coded" bannercolor chip file with a default name equal to "/en/skiname.bannercolorchip.gif". This file will always be retrieved from the /en/ directory regardless multilingual support.
Cookies and URL invoked skin settings: For URL invoked settings skin selection is saved in a cookie. Multiple browser sessions from the same person and computer share cookies. This is how cookies work in general on most browsers. This means that if you have two browser windows open on the same site then both windows will be forced to the skin which was selected last. This cookie limitation is only relevant for sites which are not using skins selected by domain names.
LOCALIZATION:
The content engine supports multiple languages and automatically preforms localization (some customization required and by
default multilingual support is disable).
The site is organized into collections of subcomponent files where each set
is located in its own language specific subdirectory (i.e. /en/ for English or /de/ for German or /es/ for Spanish.
The rendering engine will automatcially select the correct subdirectory based on the language preference of the browser.
SUBCOMPONENT FORM RENDERING ENGINE
There is a general form rendering page called cldrf.asp which be used to create an infinite number of general content HTML pages. cldrf.asp works the same way as cldr.asp but it automatically includes dynamicially generate form field.
Example: the following url will load the file contact.inc.htm located in the /en/ subdirectory: http://www.mywebsite.com/CLDRF.asp?pg=contact
You must not include your own <form> begin and end tags. The CLDRF.asp file will create all the wrapper tags for you. The CLDRF.asp function will also create some special use hidden input fields for you. These fields are:
The form can be put into TESTMODE. In testmode the form will send the e-mail to an alternate address then the address which is configured in the CGI mail system. To use testmode add the url parameter: ?TESTTO=test@myaddress.com.
You must include a range checking function inside the contact.inc.htm file list this:
<SCRIPT LANGUAGE=javascript>
function checkform()
{
// START EMAIL HANDLING
// String all spaces from e-mail addresses
var email = document.Contact.email.value;
var email2 = email;
email = stripCharsInBag( email, " ");
document.Contact.email.value = email;
// Check that an e-mail address has been enetered
if ( email.length < 5 || false == isEmail( email, true ) )
{
alert( "You must enter a complete e-mail address." );
document.Contact.email.focus();
return( false );
}
return( true );
}
</SCRIPT>