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 definitely make sense). This enables us to integrate 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.
New functionalities
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? Use the form below to contact us:
