• Internet
• 23.10.2017
• EN

An Open MVC Approach to OT WSM (RedDot) Delivery Server Functionality

written by Danny Baggs, 21. November 2011
 

This topic has been on my mind for some time now and inspired by a chat with Dennis Reil, I thought I would get something written down with the view to harvesting some of the views out there in the community.

The main context for this post is the enablement of Social Media features within an OT WSM project but the pattern described can be equally applied to other forms of integration through the use of the OT WSM Delivery Server.

I’ve long desired a way in which editors can be better empowered within the constraints of what the site builder/developer has allowed them to do with regards to features like commenting and tagging etc.  It turns out that the flexibility within the Management Server product provides us this very possibility.

With version 10 of the product, came the possibility for a SmartEdit user to drag and drop templates into containers from the panels available from within the SmartEdit view.  This was initially focused on the scenario where a SmartEdit user can build up the various content parts of a page but I’d question why can this not allow the same user to enable some functional elements with a page also?  Even without the drag and drop, the point of enabling that business user was something that I was interested in looking into.

Therefore, before I detail my proposed strawman, I think it is worthwhile to detail some of the guiding principles of the idea that has helped me shape this:
 

All Content in Management Server

This for me is a no-brainer and something that I often pass off as “best-practice”.  What I mean here is that everything as much as possible should live in the Management Server.  This means the content that is normally typically unique to Delivery Server should be within Management Server (e.g. XSLT and XML files) and published into Delivery Server.  More specifically still, those XML and XSLT files are set up as Content Classes and instantiated within the project tree structure. This provides the following benefits:

• Keeps all assets together in a single repository
• Allows the utilisation of version control within the Content Classes of this content
• Allows for the possibility to parametrise elements within the templates through placeholders
• Allows for the ability to permeate the setting of certain placeholder values through to SmartEdit users
• A single project that can be published to have all set up within Delivery Server (although Delivery Server project and system config needs to be managed directly within Delivery Server)
   

Utilise the Existing Skillsets of Site Administrators and Developers

This is another important one for me to ensure that those wishing to adopt new features don’t suffer from that fear of learning another skill by facilitating the rollout of these features through the existing knowledge they already have.
 

Adopt an MVC Approach

Why is this important? Well, this well established, tried and tested pattern is there for a reason and you’d be able to search for it easily if you haven’t come across it before.  It nicely separates the responsibilities within the feature “module” and you’ll see how this separates out into different CMS pages or elements in the solution allowing for the constraining of access to the  various parts if need be.
 

An Open Approach

This one should be obvious and is actually related to the point about skills above.  Encapsulation is a good thing when used right, but when something that can and often needs to be customised is shut away behind what appears to the user as a black box, then that task has just got harder.  Therefore, an open approach of providing access to the various parts if needed is important.
 

The Provisional Proposal

The essence of this proposal is the creation of a feature module made up of different Management Server components:

• A Configuration/Controller Content Class
• A Controller/Model Content Class
• A number of View Content Classes

It looks like I’ve sat on the fence with the “Controller/Model” part above so I’ll explain the purpose of each of the above Content Classes:
 

Configuration/Controller Content Class

From a SmartEdit user’s perspective, this is the main Content Class that contains the relevant enabling code/content for the feature.  It is this Content Class that can be dragged into a container on the page for instance.

Within this Content Class, several placeholders can be exposed to the SmartEdit interface allowing control of various feature parameters to a relevant level of user.  For instance, if the feature shows a list of comments and a comment form then a parameter may allow the user to set a “refresh time” for the comments, which translates in the technical world to how long the resultant calls under the covers are cached.

In principle, this Content Class refers to two other Content Class instances (actual CMS pages) – the XML Model and the XSLT defining the View.  In the simplest case, this may just contain a single include DynaMent:

<rde-dm:include content="anc_linkToXML" stylesheet="opt_listOfViews"  cachingtime="stf_refreshTime" />

It can be imagined that the option list and the standard field could be exposed through SmartEdit to allow user control.  If the option of the view is not to be given to the user, then an anchor placeholder can be used and a pre-assigned reference to the chosen view instance utilised.
 

Controller/Model Content Class

OK, so this Content Class is part Controller and part Model and the reason is because it contains the controlling code to invoke a given feature and the resultant XML provides us the model, which is the input to the view.

Typically, it is this Content Class that encapsulate the Delivery Server DynaMent language functionality and with OpenText’s Social Communities product, this will be using the HTTP DynaMent, which I have to say is a refreshing and strong addition to the product.
 

View Content Class

This is simply the XSLT that transforms the output XML from the feature into your resultant format.  Let’s keep it simple and assume we are generating a HTML result here.  One or more can be created if you wanted to provide different ways of using the model data. Of course, if it is just look and feel changes you’re looking to provide your users control in changing then this may be better implemented in CSS.  The various XSLT Content Classes are if the results are fundamentally used in different ways.  An example that I’ve often used is when a features should return XML or JSON – that’s simply a different XSLT file that is achieving this.
 

The Value

The value of such an approach is that it enables those with the relevant knowledge to encapsulate examples for others to use.  It therefore empowers business (SmartEdit) users to be able to choose functionality within certain sections of a page – for instance, a user can drag and drop comments or ratings onto an article page.  Finally, it shows an open approach for how such features can be enabled using elements that admins are familiar with – Management Server Content Class templates.
 

The Next Step: Your ideas!

In the first instance, I would like to understand people’s views on this with the intention to conclude the proposal by making a suggestion to how such a module can be packaged.  I would like to somehow make it possible that an admin can import the module into the Management Server and from there, complete a couple of minor configuration steps and then the module’s feature is available to the business user wherever the admin enables it.

Therefore, leave a comment or join the conversation at
http://www.solutionexchange.info/forum.

 

---

Source: Moving Open Text Delivery Server to Common Search

© copyright 2011 by Danny Baggs