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.
Diagram 1 - Distributed Architecture
Diagram 2 - Localized Architecture
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.