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 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.
We totally do a bunch of that over here at Yellow Pencil. Maybe you’ll have to come back for another visit!
I’m actually in the middle of installing social media in one of our projects. Scott created several XML files we put into delivery server which contains the dyanmets which we then call from inside a page via transform. Data from placeholders is fed through to the calls to alter the target or options for the data, as well as some options in the page to turn things on or off (I didn’t really want them picking randomly where to put commenting)
I’ve also taken the custom user tools to another level by putting them into plugins that run from SmartEdit and SmartTree and again deploy and are customizable from inside the CMS. The XML settings for the plugin contain the reddot settings and information like at the page level in SmartTree a user can run command X. This control then injects data back into a field users don’t see and the data is then styled through XSL for display. At some point I plan to add CMS specific controls for the social elements so when you click “Social Settings” or such from the SmartTree/SmartEdit it all comes up and looks failry seamless.
On the installation side there could be RQL in the plugin which basically installs and sets up the majority of what is needed. Then depending on if your social elements are pages added to containers (would need to update pages to allow modules) or editing your foundation directly (would need to add like 2 lines of code where you want the transform to output) you’d be a good chunk of the way there.
At least that’s how Ilike it. Simple, everything a user needs in one place, basic stuff automated.
Thanks Christopher for sharing your experience and thoughts. Sounds like you should share some of that knowledge through your yellow pencil blog (or your own) and we can syndicate that to Solution Exchange 😉
Isn’t there some sort of saying like “Those who can do, those who can’t teach.”? 😉 I’ve got to find some free time in the middle of all the doing!
In your include sample, can you elaborate on the choice of StyleSheet as an option list type? In many cases the XML may need quite a specialized format needing a specialized XSL. Is this not a case you expect for this type of area? Or is this more of a generic proposal for comment and you are equally accepting of inserting an anchor for that as well if more appropriate?