It's not a secret anymore!
The moose likes EJB and other Java EE Technologies and the fly likes 2 CMS or not to CMS Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "2 CMS or not to CMS" Watch "2 CMS or not to CMS" New topic

2 CMS or not to CMS

Roger Rodrigues

Joined: Oct 01, 2003
Posts: 3
Hi all
Currently we are exploring different options. We would like to build pre configured sites and create new instances for different clients rapidly , change branding and stuff. What is the best way to go about doing that ?
is CMS probably a good solution ? if not what other alternatives are there ?
Since this is a java shop , would like a java compatible solutions. Thanks for you suggestion in advance

Joe Ess

Joined: Oct 29, 2001
Posts: 9189

There is no "best" way.
Are you hosting the sites together, or are you hosting each branded site separately?
If you are hosting the sites separately, you may be able to get away with putting all the text in message bundles and naming the branding images the same. You should be using some sort of revision control and build tools (Ant and Maven being the most popular) to automate your builds. An adept use of tagging and branching will let you build sites for multiple clients quickly and easily.
If you are hosting the sites together, a CMS may make sense. We have a home-built CMS that fits our needs well. Have a look at this site then this site. You'll see the branding changes (note the branding is stored in the session, so it's persistent once it happens). It's fairly simple. There's an XML config file like this:

There's a class that builds a library of all the content references then there's a class and a JSP tag that takes a key and qualifier and looks up a value in the library, like so:

Where "id" is set on-the-fly to a qualifier. If no qualifier is specified, or no data tag has a matching qualifier, the CMS returns the default value. There's some more to it, for example, our CMS values are external to the web app so we can change them without a build, but that's the general idea.
One problem I've heard with external CMS's is that there's no easy way to migrate the settings and data from test to production. Everyone is so focused on getting production working, the test environment gets neglected and is soon completely incompatible with the code. This solution alleviates that problem by packaging the CMS data right with the web app. When the code is promoted in source control, one can promote the CMS values right along with it.
Hopefully someone with more experience with third-party CMS will chime in, as my experience is thin.

[How To Ask Questions On JavaRanch]
I agree. Here's the link:
subject: 2 CMS or not to CMS
jQuery in Action, 3rd edition