Flexible, user friendly, secure, and with our experience - we have been an official partner since our company's foundation in 2001 - dynamic, too: That is OpenText Web Site Management (OTWSM). In spite of several name changes, it remains one of the great content management systems for enterprises. Renowned consulting company Gartner's latest "Magic Quadrant for Web Content Management" report declares OpenText one of the leaders in that field.
As soon as an intranet, internet or extranet website's complexity exceeds that of a personal blog with a few new entries each month, a web content management system becomes all but indispensable. The CMS of our choosing is OpenText Web Site Management (previously known as InfoOffice, RedDot CMS and OpenText Web Solutions). Here, we are declared specialists - as demonstrated by our official status as Select Partner with focus on Services, but also by our completing numerous large scale customer projects. www.aiticon.com, obviously, has also been created and is being edited with OTWSM.
Since its foundation in 2001, aiticon has been closely aligned with this CMS as an official partner - even if, back then, it was still called RedDot CMS. This name was as fitting as it was easy to remember - it is red dots, after all, that identify all the spots where an editor can add or change content. Downright revolutionary with RedDot back then: For the first time, content editing happened on an interface that looked almost exactly like the website to be published - the only addition being those red dots. Thus, this name remains in many peoples' memories until today.
In 2005, Canadian software producer Hummingbird buys RedDot, just one year later, Canadian IT giant OpenText acquires all of Hummingbird's shares and renames the CMS into OpenText Web Solutions, initially. When OpenText added another CMS called Vignette to their portfolio, what we knew as RedDot was given the slightly complicated name "OpenText Web Site Management".
Name changes notwithstanding, the CMS stayed true to its structural principle: the separation into Management Server (formerly RedDot CMS) and Delivery Server (formerly RedDot Live Server). This dichotomy, among other things, is where the system's great opportunities lie - if you know what you are doing.
Within the Management Server, editors build a site's navigation structure, develop the content classes (templates), basically the system's building blocks, and edit content. The Management Server then publishes that content to the Delivery Server. The latter one delivers the sites to the users, the visitors on the www.
Why this separation, you might ask, if other systems, like WordPress or Typo3, get along without it? Among other things, it offers additional security, as Management Server and Delivery Server can be located in different network segments and even in different physical locations; while the former can be placed within, for instance, a particularly protected intranet, the latter can be on the internet, providing for high performance for the website visitors.
Furthermore, the separation allows for a degree of flexibility that other systems lack: using the Management Server does not exclusively tie you to the Delivery Server for delivery; in fact, web servers like Apache httpd or Microsoft IIS can be used as well. This is where our application platform appNG comes in, too - this platform-as-a-service (PaaS) allows for numerous innovative applications.
Dynamics in the mix
As a matter of principle, the Management Server publishes static sites, and that is a one-way street: the Delivery Server cannot access content stored on the Management Server "on demand" - which, from a performance perspective and for the just mentioned advantages to the separation would be counterproductive, anyway.
But what if a website's operator wants to integrate dynamic content like a full text search, database content or content from a third-party application? And what if he wants to integrate them natively into the site and not through detours like Iframe - including all the disadvantages that came along? It is, after all, absurd to have the Management Server provide results for every conceivable combination of search keys.
The solution comes in the shape of dynamic control elements named Dynaments (in case of the Delivery Server) or Taglets (that's how we call them in appNG). Once embedded, they notify the system on how to "mobilize" the site. Contact forms including direct validation, newsletter sign-up forms including automated e-mail confirmations, product databases including search and sorting functionalities - those and many far more complex scenarios can now be represented.
About Dynaments and Taglets
Dynaments and Taglets do not create dynamic within the Management Server, but only after publishing, meaning within the live system. They are much more flexible, as they are not subject to the Management Server's restrictions (which, as has been pointed out, absolutely make sense). This makes possible functionalities such as subsequent, automatic cropping of pictures for each desired view, but also things like facetted search, suggested search, integrated product- or recipe databases, basically any kind of dynamics.
That way, complex web applications can be integrated natively into a website published by the Management Server - and now, they can even interact with content published by the latter: The entire text content of an integrated third-party application is edited within the Management Server, while the actual business logic keeps being represented by that third-party application.
Applications that are being integrated into the published page by the Delivery Server or appNG, consequently, can be parametrized by the editor within the Management Server. Thus, he can influence how the application behaves - at runtime within the live system.
Naturally, Management Server and Delivery Server dictate the overall framework of functionalities, but both offer interfaces for extensions - interfaces that we use extensively, too. Via RQL (RedDot Query Language), we have extended the Management Server by several functionalities, like for example semiautomatic content migration from existing into new CMS projects or a variety of assistants that guide the editor through content editing and execute "unnecessary" clicks - "unnecessary" here meaning "able to be automated", of course. Via RQL, third party applications like appNG, for example, can be connected to the Management Server.
The Delivery Server's interface OpenAPI (this is a proprietary interface, other than the name might suggest) enabled us to write our own tool for URL beautifying, as well as an extensive form framework. Here, we put editors in a position to compile their own form in the Management Server pretty easily, the Delivery Server then takes over validation and processing of the data entered into the form.
Our experience, your advantage
Due to our extensive experience with OpenText Web Site Management-related web development, combined with our software development and IT operations know-how, we are able to exert this powerful system to its fullest - for our customers' maximum benefit.
Sounds interesting? Talk to us right now!