Target Box CMS
COMPLETE SPECS PDF    OVERVIEW    DOWNLOAD    YOUR COMMENT 
 

OVERVIEW

Target Box CMS (TBCMS) is a .Net-platform thin-client cloud web Content Management System designed for content management on multiple custom-developed websites with highly structured dynamic content such as catalogs, E-commerce etc. The vast majority of content on sites like these is driven by data in relational databases, where data is normally structured in database schema. On user interface side this translates into specialized data entry tools. However, there are areas where structuring becomes either too costly or impractical. Examples include but are not limited to: time-sensitive marketing materials, promos, advertisement blocks, instructions (such as product delivery terms), "about us" information, etc. Eventually the developers are facing the dilemma of either creating their own customized CMS module for handling ad-hoc content, or using one of the existing out-of-the-box CMS. The latter, however, tend to be not only somewhat intrusive requiring certain modification to website architecture (if not taking it over completely), but also require routine involvement of developer work. Therefore, in practice data entry requires substantial preliminary developer work rather than sort of work available for users without programming expertise. This defeats the very purpose of CMS, which is supposed to provide an easy way of modifying content by content managers rather than web developers.
TBCMS is designed to address this dilemma. Aside from original setup, which indeed involves certain technical knowledge, TBCMS developer routine tasks only consist of setting HTML DIV elements with specific IDs in dedicated places in web page’s HTML (thus, "Target Box"). Or, if you opt for server-side client component provided with TBCMS solution, the developer’s task will be to drop self-contained components in dedicated places. The rest is taken care of by data-entry clerks and TBCMS architecture.
Without further ado let’s see how it works.

Distributed Architecture
Diagram 1 - Distributed Architecture

Localized Architecture
Diagram 2 - Localized Architecture

TBCMS system consists of the following components: TBCMS database (MS SQL or SQL EXPRESS), UI application (TBCMSUI), File Utility service application (TBCMSFUT), and WCF service (TBCMSWS). The latter is essential in distributed configuration for Production Website Client, but redundant in localized-type architecture. There are 2 system configuration types: localized (diagram 2) and distributed (diagram 1). On diagram 1 text content is created in UI applications in HTML Editor and stored in TBCMS database (0). Uploaded files (such as images and PDF) are stored in file system structured in UI application. When content is published to preview or deployed to production TBCMSUI sends HTTP request to respective TBCMSFUT to clear application variables where content was previously cached (CC and CCA respectively). On the website client (WC) side, triggered by "document on load" event JavaScript populates inner HTML of DIV elements identified by content container IDs (1, 1A). To obtain HTML text JavaScript sends AJAX request to TBCMSFUT (2 and 2A), which either calls DB directly or through TBCMSWS (2 and 2A). TBCMSFUT stores content in application variable and sends it back to client script (3 and 3A). All subsequent client requests are handled by cache, unless application variable is cleared again by call from TBCMSUI. References to files again point to TBCMSFUT, for example:

<img src="http://siteurl/bxcmsfut/?path=c:\web\bxcmsui\bxcms_contentfolder\1\1\image.jpg&bxcmsoverwrite=true&height=205&width=210" alt="" height="205" width="210" border="0">

<a target="_blank" href="http://siteurl/bxcmsfut/?path=c:\web\bxcmsui\bxcms_contentfolder\1\3\yourfile.pdf&bxcmsoverwrite=true">This is a link</a>

This process is marked on the diagram as FBF (stands for file binary feed). In this process file’s byte array is pulled by TBCMSFUT from the "bxcms_contentfolder" folder in TBXCMSUI either directly (if both applications are on the same server) or via TBCMSWS. Notice "bxcmsoverwrite=true" parameter. It tells TBCMSFUT that file must be pulled from the source rather than its own local storage, where they are stored after first request. This parameter corresponds to Publish/Deploy situation. In subsequent requests this parameter will be removed from the text stored in application variable, so locally stored files will be used for binary write.

It is worth noting that TBCMSFUT can be used as a stand-alone file server application (in distributed architecture it’ll also require TBCMSWS). Through the set of parameters in query string it provides a way for easy image formatting with height, width, vertical and horizontal padding and padding area color (see TBCMSFUT AS STAND-ALONE FILE SERVER section in COMPLETE SPECS PDF).

Finally, content expiration can be set in TBCMSUI. Expiration is handled by an executable application BXCMSSCHEDULER. It should be set up on Content Generation Server as a windows task, so it’ll be periodically checking content marked for expiration. With each record found an HTTP request is sent to clear application variables in respective TBCMSFUT corresponding to content container record.