Server | CMS Blog Watch

Posts Tagged ‘Server’

How to integrate ASP.NET into RedDot CMS projects – Best practice on .NET template embedding

Posted in ASCX, ASPX, Best practice, CMS, RedDot, RedDot templates, Render Tags, Templates, Templating, User Controls, asp.net, temp on March 8th, 2010 by Markus Giesen – Comments Off
Integrating Microsoft ASP.NET into RedDot CMSIntegrating Microsoft ASP.NET into RedDot CMS
Learn it the right way here

Is it easy to integrate .NET into your RedDot CMS project? Yes it is, if you know how and obey some simple rules. This article gives you a best practice on how to include any .NET functionality for your published website within your RedDot CMS templates.

If you can avoid using inline code within your RedDot Content Classes then do it

Inline code within a content class can’t be versioned as it could be with a version control system when developing standard .NET solutions outside of any CMS. You can’t develop or test properly using inline code within the CMS. Whenever you have to change the .NET part of your project you would need a RedDot Consultant or some of their knowledge and hence your project doubles up on resources. Don’t integrate inline code within your CMS.

Let the CMS handle content – Don’t care about the rest

There is a clear understanding of what your CMS should handle for you – your content – and what it should not take care of – styling and dynamic functionality may it be Javascript, .NET or any other scripting technology. The CMS is your data storage and management layer, the web server is your presentation and visualization layer and hence it is the point where dynamic functionality, styling and user interaction takes place. By keeping those parts separate you ensure to have a stable, scalable and furthermore easily maintain- and upgradeable Content Management Solution. Read more on this topic here

Example – How to integrate .Net properly using User Controls

Instead of just adding a page directive followed by your inline code you should use user controls. Given that your code will be used on your website and not within the Open Text CMS ASP.NET User Controls are the best way to embedded dynamic functionality within your project.
There are basically two points where .NET is included in your template. The first one needs to be in every template which uses User Controls unless you integrate it using a container. The second one works as placeholder for the .NET functionality:

1. Reference the .ascx file at the very top of the template

<reddot:cms><if><query valuea="Context:CurrentRenderMode" operator="==" valueb="Int:2"><htmltext>
<%@ page language="C#" %>
<%@ Register Src="~/UserControls/Search.ascx" TagName="Search" TagPrefix="uc" %>
</htmltext></query></if></reddot:cms>

This example references a code behind file for a search used on the web server. It is placed in the top of every page instance created with this template. This way you only have to integrate the .NET reference once in each template. You can break it down to once per project if you use a container approach.

2. Place the User control tags as placeholder for the .NET functionality

<body>
  <div id="site">
    <div id="header">
<reddot:cms><if><query valuea="Context:CurrentRenderMode" operator="==" valueb="Int:2"><htmltext>
      <uc:Search ID="Search" runat="server"/>
</htmltext></query></if></reddot:cms>

This is the ASP.NET User Control for your search interface. Since you don’t run the search inside of your CMS project we have used a Render Tag to exclude this block from showing up within the CMS. If you want to be fancy you can put some placeholder content here by using a different Context:CurrentRenderMode block where you use valuea=”Context:CurrentRenderMode” operator=”<>” valueb=”Int:2″ to show HTML code only on the CMS server, you can read more about this here.

Maintain & edit your ASP.NET code outside of the CMS

By following the example above whenever you have to update your .NET code you just have to change your .ascx file, there is no need to touch or even deploy the .ascx file to the CMS server. There is an approach of using the built-in .Net folder within RedDot CMS but since you might as well just upload your files manually I dare to say – Why bother? Ok, you should bother in a clustered server system where you publish to multiple publishing targets, but for a simple one CMS one web server setup you might as well just stick to manual deployments.

Changing ASP.NET properties and influencing your .NET from within the CMS

In RedDot we are able to insert User Control tag into any area of a page. If you have to influence settings or content areas you can use several ways to generate content and integrate those within .Net applications. You can use XML files published by RedDot CMS or user attributes with inline edited content to changed and/or edit properties. Those can be passed through to your User Controls. No need to use the CMS as IDE for your .NET solutions, keep all parts of your project separate and everything is just fine.
Are you interested in how to integrate CSS files within the CMS? Read this article here or on a high level understanding and “how to” for CSS and CMS in general this article here.

And you?

How do you integrate ASP.NET in your RedDot CMS projects?

Read more RedDot CMS best practice articles here.

Share and Enjoy:

Print
email
Twitter
Digg
Reddit
StumbleUpon
Google Bookmarks
del.icio.us
MisterWong
Facebook
LinkedIn





Take Another Look at the Sites Model

Posted in Uncategorized on March 3rd, 2010 by Hannon Hill News – Comments Off

A refresher on all the benefits of using Sites in Cascade Server.

5 Template Tips – How to use HTML and CSS within RedDot CMS – Best practice for RedDot Consultants

Posted in Best practice, CMS, JavaScript, RedDot, SmartEdit, Templates, Templating, Tricks, css, html, integration, jquery on March 1st, 2010 by Markus Giesen – Comments Off
Merging HTML, CSS and RedDot templates - How to do it the right way?Merging HTML, CSS and RedDot templates
Read how to do it the right way.

This article covers the key factors for successful CSS and HTML integration into your RedDot CMS Open Text Content Management Server project. This best practice article outlines the major points to pay attention to when implementing your HTML into the CMS.

What you should do when you integrate HTML and CSS into your content class templates

  1. If you can avoid it, do not create templates for your CSS or Javascript files. A detailed post can be found here.
  2. Don’t target HTML elements directly within the CSS. Always use classes. Specifically with anchor, image and span tags. If you target HTML elements directly this might affect the red dots which will be placed inside the templates because they are anchors, images and spans.
  3. Always target the ‘first’ item in a collection of items (lists, repeating blocks, …) by using a CSS class. Within the RedDot CMS you can identify the first item in a list using ASP and PreExecute script blocks but not always can you identify the last item. Especially when the amount of items is varying and you cannot utilize Render Tags.
  4. Ensure dynamic HTML is accessible when switched off. Using Javascript code within the CMS editing view can be problematic because it can hide editable content. Ensure that when using dynamic scripts the content is also visible when Javascript is deactivated. For example when you are using jQuery with tabs and your CMS editor changes content, the page reloads when the element is being saved and the user has to open the tab again. It’s better to deactivate the tabs when the page is ‘open’ and in SmartEdit editing mode.
  5. Files such as background images, styles heets, javascript and others need to be referenced relative (../mystyle.css) rather than root or absolute referencing (/cms/projectfolder/folder-not-working-on-live-site/mystyle.css). RedDot CMS has its own folder and sub folder structure and during editing it can’t use absolute referenced style or JS files and will mix those up.

Summary

RedDot CMS is a fairly easy to use system when it comes down to templating. I am not saying it’s straight forward or a technological top notch solution. It also is not meant to be an IDE. The good thing to say about the CMS is that the elements are modularized to each single HTML object and can be used in an infinite number of ways. Pay attention to the best practice rules above and think about where your files and references will be used. When using the guidance above the HTML of your project will run smoothly on any platform and publishing target.

What is your RedDot CMS Consultant integration experience?
How do you use HTML and CSS within the RedDot CMS?
Have you ever had any trouble or even an “CMS integration epiphany”?

Read more RedDot CMS best practice articles here.

Share and Enjoy:

Print
email
Twitter
Digg
Reddit
StumbleUpon
Google Bookmarks
del.icio.us
MisterWong
Facebook
LinkedIn





Highlighting Cascade Server Client Resources

Posted in Uncategorized on February 24th, 2010 by Hannon Hill News – Comments Off

Cascade Server clients use their websites to keep stakeholders up to date on WCM projects, timelines, training, and new resources.

LiveServer Setup Best Practice – How To Tame The OpenText Delivery Server

Posted in Apache, Best practice, Delivery Server, Helicon, IIS, LiveServer, Performance, RedDot, Tomcat, URL Rewriting, seo on February 22nd, 2010 by Markus Giesen – Comments Off

About the Author

This article is based on the blog post here of Danny Baggs. Danny has a strong developer based background and is working for Open Text.

Overview

The way the LiveServer Delivery Server is set up for a development environment usually is as a standalone application without having a front controlling web server. Although this is working for development purposes it doesn’t work within a live environment with several thousand users firing off HTTP requests every hour or minute or even second.
This post discusses the best practice of deploying the Open Text Delivery Server in an optimal way alongside a front controlling web server. This article provides a high-level overview of what to set up and how the necessary components work together. Depending on feedback I may post further posts on the details of each step.

After reading this article you will know

  • How to set up your LiveServer environment properly to ensure it is scalable, reliable and offers high performance
  • Which tools you can use to create dynamic functionality
  • How you can tweak your LiveServer to gain some SEO enhancements

How does Delivery Server work and what should you not do

The Open Text Delivery Server is a dynamic web server component that has strengths in coarse grained personalization and dynamic behaviour as well as system integration. All you need to know is where to get your hands on and what to do and what you better should not do.
The Open Text Delivery Server is housed within a Servlet Container. A Servlet Container is not the ideal location from which to serve static content. It handles requests in a way that limits the amount of concurrent requests. This can lead to severe performance issues.
There are ways to mitigate this but it needs quite a lot of Java experience and is still not recommended. Unless you wish to maintain a level of access control over the static content let’s put it simply like this:
Don’t run the Deliver Server as a standalone web server.

What do you need to get the Delivery Server running?

Leveraging the use of a front controlling Web Server facilitates an optimised site deployment as web servers such as Microsoft’s IIS or Apache’s HTTP Server can be utilised for delivering static content in an optimised way. For example, it is possible to easily configure a far future ‘Expires’ header on a given folder and therefore its content within either Apache or IIS, which promotes the caching of content in a user’s browser, which reduces page load times. Another example is in the use of mature compression features within such web servers to gain performance for your Intranet- or Extranetapplication. Although these examples can be achieved with some Servlet Containers, it is certainly not straight forward and doesn’t necessarily make sense from an architectural perspective.
Use a web server like IIS or Apache as a hatch for your static files or to forward requests that require personalization to the Delivery Server.

2 Components – Which does what?

It is for this architectural reason, that best-practice dictates that we delegate only the relevant HTTP requests to Delivery Server. Your web server should handle the static bulky content and only forward the requests to Delivery Server which require personalization. In most cases, this means that Delivery Server is delegated requests for .htm and .xml resources. The rest such as images, videos, documents, … can be served from the front controlling web server (or better still a CDN).

Delegating HTTP requests from the Web Server to Delivery Server

This step can be easily achieved using the Tomcat Connector for both IIS and Apache. To find out more see the Tomcat Connector documentation here.
This connector uses the Apache JServ Protocol, which connects to port 8009 by default on Tomcat and is optimised to use a single connection between the Web Server and the Delivery Server for many HTTP requests for performance optimization. Therefore, this represents a better option than using reverse proxy functionality within the Web Server which slows down multiple requests fired off at the same period of time.

Typical Delivery Server install – Ports & Parts Getting Together

If we take a typical Delivery Server install (i.e. the reference install using Tomcat),
a page can be accessed with something like the following URL:

http://<host>:8080/cps/rde/xchg/<project>/<xsl_stylesheet>/<resource>
where resource could be any text based file like index.html or action.xml.

The result of correctly installing the Tomcat Connector means that we can access that same resource but through the Web Server on port 80 and not direct to the Tomcat instance on port 8080:

http://<host>/cps/rde/xchg/<project>/<xsl_stylesheet>/<resource>

Many confuse this step with URL rewriting or redirecting as the Tomcat Connector is often called the Jakarta Redirector. Therefore, I choose to differentiate by saying that this delegates HTTP requests between the two systems and nothing more.
In every install, I have always used the defaults in the workers.properties file and just used the following rule in the uriworkermap.properties file:
/cps/*=wlb

SEO Tweaks – Some URL Rewriting tricks

Due to the effort of setting up delegation, deciding which HTTP requests should be forwarded to Delivery Server is a simple matter of performing some URL rewrites.
As we have decided to use a mature Web Server, there are best practice ways to achieve this. In IIS6, HeliconTech (Visit HeliconTech website) created a very useful ISAPI filter which ports the widely adopted Apache mod_rewrite (visit Apache mod_rewrite website) functionality. For both of these, the same rewrite rules can be used. The following provides a couple of typical examples:

# Default landing page redirect
RewriteRule ^/$ /cps/rde/xchg/<project>/<xsl_stylesheet>/index.htm [L]
# Rewrite to delegate all *.html or *.htm HTTP requests to Delivery Server
RewriteRule ^/?.*/(.+\.html?)$ /cps/rde/xchg/<project>/<xsl_stylesheet>/$1 [L]
# Rewrite to delegate all *.xml HTTP requests to Delivery Server
RewriteRule ^/?.*/(.+\.xml)$ /cps/rde/xchg/<project>/<xsl_stylesheet>/$1 [L]

Those of you who are well versed in regular expressions will see that the last two rules could be combined but I tend to leave them separate to aid readability.

SEO & mapping subdirectories in LiveServer

The beauty of using regular expressions in this way is that you can actually create useful SEO benefits to your site also. Take for example the following rule:

RewriteRule ^/?.*/([0-9a-zA-Z_]+)$ /cps/rde/xchg/<project>/<xsl_stylesheet>/$1.htm [L]
This rule maps an URL with many apparent subdirectories to the Delivery Server file.

This means that you can publish a page with a “virtual” path within the Management Server which appears to a browser (and search engines) as something like the following:

http://<host>/this/is/a/descriptive/directory/structure/page.htm
and yet this maps to:
/cps/rde/xchg/<project>/<xsl_stylesheet>/page.htm

Some restrictions & tricks for IIS7
Being a Microsoft product, IIS7 has some quirks with regards to the rewriting (of course), which I explained in a previous post here.

Summary

Sharing the required tasks between their appropriate applications gives you a more stable and reliable system with an even better performance. All you have to do is let:

  • Never use the Open Text Delivery Server/RedDot LiveServer as standalone web server on tomcat
  • Any Web Server (i.e. Microsoft IIS or Apache HTTP Server) to answer all requests and then return static content(Use IIS or Apache or any other web server to deliver static pages) or if required forward to
  • Delivery Server for dynamic requests and the personalization bits (Use LiveServer as personalization engine)

This approach has led to many successful installations where sites could additionally be optimised for SEO and page load by using compression techniques and the way a web server actually serves HTTP requests.

About the Author

This article is based on the blog post here of Danny Baggs. Danny has a strong developer based background and is working for Open Text.

Questions & More information about the named components

Although this should give you a fair bit of guidance on how to set up your web server environments to get a high performance solution there are always questions remaining. Feel free to share those questions in the comments below and let us know what you think.

Read more about the components

Questions

  • How do you handle forms in a project, should they be based on LiveServer Dynament code or run in the web server?
  • How do you manage to keep static delivered content index- and searchable by Verity or another search engine on this system?

Hey Mr. and Mrs. Reader! What are your questions?

Share and Enjoy:

Print
email
Twitter
Digg
Reddit
StumbleUpon
Google Bookmarks
del.icio.us
MisterWong
Facebook
LinkedIn





Save the Date!

Posted in Uncategorized on February 17th, 2010 by Hannon Hill News – Comments Off

Mark your calendars for the 2010 Cascade Server User’s Conference taking place on Monday September 13, and Tuesday, September 14.

ocPortal 4.3 released

Posted in CMS, cmsreport.com, ocportal on February 11th, 2010 by Bryan – Comments Off

ocPortal 4.3 was released this week. The new version of ocPortal introduces a number of “bug fixes, performance improvements, and usability improvements”. However, ocPortal also introduces some new features to make upgrading to the new version more enticing.

The new features that have been implemented in ocPortal 4.3 include:

  • Wordpress, Joomla, and HTML website importers
  • iCal exporter
  • Quiz results CSV exporter
  • New Comcode ‘pulse’ tag
  • Improved shared-install functionality
  • ocPortal can now run without a database (the inbuilt database is now a bundled feature, although not completely supported or recommended for production sites)
  • New developer feature for the quick addition of language strings, written (temporarily) in-line into the code
  • Support for running a server behind a proxy server

Additional details regarding ocPortal 4.3 can be found in the official ocPortal news announcement.

Centralizing Collaboratively with U of S and Cascade Server

Posted in Uncategorized on February 2nd, 2010 by Hannon Hill News – Comments Off

The University of Saskatchewan unanimously selected Cascade Server as their institutional web content management system. Find our more about how collaboration was key to their success.

Centralizing Collaboratively with U of S and Cascade Server

Posted in Uncategorized on February 2nd, 2010 by Hannon Hill News – Comments Off

The University of Saskatchewan unanimously selected Cascade Server as their institutional web content management system. Find our more about how collaboration was key to their success.

Extending Open Text Delivery Server with your own Java Classes

Posted in Best practice, Delivery Server, Featured, Java, Java Classes, LiveServer, Open Text Delivery Server, RedDot on February 1st, 2010 by Markus Giesen – Comments Off

Guest writer Marek Korch, RedDot/Open Text Consultant at infinity-group.pl in Poland and working for clients like BNP Paribas Fortis, Dan-wood, Allianz and Nordea. He enjoys new challenges in Open Texts Management / Delivery Server systems and learning new things around the ECM world and how to improve them. He also just started writing on this blog.

In this article we will show you how to find the right files to extend Open Texts Delivery Server (formerly known as RedDot LiveServer) with your own Java classes.

You might have worked with LiveServer DynaMents before and sometimes you just wish you would have that special method or a nicer way to process this bit of information but the existing set of Delivery Server DynaMents just doesn’t exactly fit your needs. Therefore here comes your LiveServer tutorial for including your own Dynaments inside of LiveServer.

If you want to start your own adventure with DynaMents and inline Java functions which will extend the DynaMents functionality, you’ll need to go through the following steps:

  1. Prepare the LiveServer (Delivery Server) environment
  2. Prepare the java package and the java class files
  3. Create your own class which you want to use to extend the built-in java classes

Prepare the LiveServer Delivery Server environment

First of all check your Delivery Server version and build. I was working on LiveServer (Delivery Server) build 4.0.0.8 but it’s recommended to upgrade it to LiveServer 4 SP1. Of course it is not necessary to upgrade your LiveServerS/Delivery Server, but it makes things easier if you are able to go with the upgrade as you will see below. (Always keep in mind to check the release notes and check issues affecting your environment. LS 4 for example has a known defect with updating/connecting to Active Directory which is yet about to get fixed)

Prepare the java package and the java class files

Finding the classes on your LiveServer environment can be a bit tricky, to create your own Java class file you will have to import one very important class package which is built in the LS. The class is called:
de.reddot.xmaps.dynament.DefaultInlineFunctions;
There are two ways to find it and to import into your class package during the compilation process:

A) Especially recommended to use if you have LiveServer without SP1, is to import the above mentioned class into your java project in which you will compile your own class. To accomplish that, simply import the JAR file with the necessary class which is located in
<LiveServer_Install_Directory>\\tomcat\\webapps\\cps\\WEB-INF\\lib\\rdls-rde-x.x.x.x.jar

x.x.x.x corresponds to a build version of LS. In my case it was rdls-rde-4.0.0.8.jar.

B) If you already have LiveServer running with the SP1 updgrade, you can find the necessary class in
<LiveServer_Install_Directory>\\tomcat\\webapps\\cps\\WEB-INF\\classes\\de\\reddot\\xmaps\\dynament\\DefaultInlineFunctions.class

Create your own class which you want to use to extend the built-in java classes

The Next step is to prepare a definition of your own class. It should looks like this:

// ############################
package com.company.package;
import de.reddot.xmaps.dynament.DefaultInlineFunctions;
public class ExtendedInlineFunctionsClassName extends DefaultInlineFunctions{
         public String function(String value, ...ANY OTHER VARS DESIRED){
                   String mustReturnAString=value;
                   return mustReturnAString;
         }
         //called inline like [#source:attribute#].function(...ANY OTHER VARS DESIRED)
}
// ############################

After that, all you have to do is to compile your own class file with your function(s) and then copying it to to the classes folder on your LiveServer directory:
<LiveServer_Install_Directory>\\tomcat\\webapps\\cps\\WEB-INF\\classes

And Voila! Based on that you are ready to go. Create your own Java methods and use the according DynaMents in your LiveServer project.
Questions? Ideas? More LiveServer enhancements? Use the comment box below!

Share and Enjoy:

Print
email
Twitter
Digg
Reddit
StumbleUpon
Google Bookmarks
del.icio.us
MisterWong
Facebook
LinkedIn