Java-based CMS with RESTful service / API to access content [closed]
Asked Answered
L

2

34

For those who might vote to close this question due to "not constructive - As it currently stands, this question is not a good fit for our Q&A format." - Would be great if you would suggest where should I post this question (https://softwareengineering.stackexchange.com/ ? or any CMS-focused forum?)

Similar questions have been asked before:

All of them are a few years old, so I am wondering if there are new recommendations / discussions around this.

Some background: We are a Java shop, we create / maintain websites for our clients, our tech stack are Java, Spring, SQL, JSP, HTML5, JQuery, Tomcat, JBoss, Maven, etc ... the usual stuff. So far in terms of "content" we either put it in some properties file read in by the JSP for copies (eg. description of product X) or back-end service that provide dynamic content (eg. what's the current value of product X).

Now we are rethinking our approach to managing content because we are managing more and more properties for the client with the same content (eg. a website, mobile website, mobile app, etc), so we definitely want to avoid having multiple copies of the same content spread around.

A few things I am particularly looking for:

  1. Java-based (because we are Java shop: 1) more expertise in handling Java-based stuff and 2) avoid introducing another tech to the stack)

  2. Extensibility / customization. Need to be able to customize the CMS (which is why we want to stick within our Java expertise) so that it can be extended to connect with other web services to consume content, etc.

  3. Focus on content - we need clear separation between content vs UI-render, going back to what we are looking for where we will need to deliver the content into separate properties.

  4. RESTful service / API to access the content - same as above. We need the content to be accessible directly as a JSON / JSON-P /. XML feed.

  5. Need to have a decent UI to work with and the more intuitive the better for business user because some of our client that might be moved to the platform will likely want to be manage their own content

  6. Multilingual support

  7. Open source / low cost

So far, several options that I have are:

Adobe CQ - Looks to be the most ideal solution, but unfortunately it's cost prohibitive

Hippo CMS - Looks to fit what we are looking for, I am unsure of how well it's documented, tutorial / how-tos seems to be quite sparse, their market share seems to be bigger in Europe than in North America.

Liferay - More focused as "portal" as opposed to CMS providing content

Alfresco - More focused on "documents"

dotCMS - Like Hippo CMS, seems like this one might fit our needs.

Magnolia CMS - Looks around the same alley as dotCMS and Hippo as well. From the comments I've seen seems like they are more focused on a single website and not clean separation between content vs UI.

I personally don't have much direct experience working with CMS before.

Your thoughts / comments on each of the options above, or if you have other solutions in mind not mentioned here, would be greatly appreciated! One of my challenge is that we need to make a really sound decision because whichever path we decide to go down with, we would likely be stuck with it, decision is not something that can easily be discarded and start over.

Lowman answered 25/5, 2013 at 17:0 Comment(4)
Thanks for the list of open shopping questions!Cullen
Meta'd the original question by asker: meta.stackexchange.com/questions/182797/…Fan
The reasons to consider some question as 'not constructive' are so subjective and arguable that often than I'd like I find valid questions like this being buried for reasons close to stupidity and/or censure.Simson
Related questions (similarly with quote open discussion and necessarily some opinions): https://mcmap.net/q/328571/-open-source-java-cms-closed stackoverflow.com/questions/12595278/cms-integration-with-javaSandman
K
37

Personally I have some experience with Hippo and a lot with dotCMS. I do know a little about Alfresco, Liferay and Magnolia but I have not worked with them before. I have no experience whatsoever with Adobe CQ, because I never took the time investigating. This is because of the high costs being a no go for many of our clients. Alfresco is indeed a better solution if you're looking for an online document management system, which I think you aren't. You are right about Hippo, Magnolia and dotCMS being somewhat similar, which isn't that strange because they try to solve the same problem: being an Enterprise class Java based Web Content Management System. They focus heavily on managing the content which can be used in pages that are also manageable with the CMS.

To be honest: I have a bias towards dotCMS because I have worked with the systems a lot and know much about it. I thought I'd explain why it works for us so you can take that into consideration. I work in a Java shop that does a lot of middleware development for its clients using JBoss and the whole EE stack. We connect old (Cobol) and new systems together and put a shiny new web interface on top of that middleware that targets both admins and consumers. To be able to create these interfaces we need a CMS that does a few things well:

  1. Java based (because we're a Java shop this enables us to have the same people work on the CMS and the middleware)
  2. Horizontal scalable to tens of servers without too much hassle. In the classic case when scaling out to multiple servers the database and the assets folder are shared between the nodes. This could be a problem when you have many nodes, but in practice it's not such a big issue because most of the load will hit the index and not the db or the disk. In 2.5 and up dotCMS offers a "share nothing" mode where each node has its own database and assets folder, but this does requires you to use an additional (read: licensed) authoring server that pushes the content to each of the nodes. I have not played with this setup myself, but it sounds promising, especially because each node can be a simple and cheap box that only uses postgresql / mysql and tomcat and because there is no single point of failure anymore. In the classic case if the shared assets folder or the db would die all nodes would be down as well, except when you cluster the db and the disk as well which is expensicv to do. With this "share nothing" setup this is no longer the case. As I said: I have no experience with this, but it sounds like it might work.
  3. Admin interface usable by both power users and non techie people (clients). Not everybody is "good with computers", but they too need to be able to manage the content (very often these people work in the marketing department of our clients). dotCMS offers ways to create admin interfaces that show only a few of the functionalities dotCMS offers. This prevents them for having to understand the whole system which speeds up training and acceptance.
  4. Structured content. This is biggie. We want to be able to define many types of content all with a fixed set of fields, just like a database table. All without having to rebuild or restart the system. The people that would define content based on this structure (the name dotCMS uses for these types) cannot enter invalid data because the system protects against that. This makes building websites so much more future proof and convenient. Especially for developers.
  5. Focus on content first. The first months that we used dotCMS we actually only used dotCMS for managing the content itself and exposing that through JSON API's. We did not use CMS features like defining templates and creating pages. This works fine and sounds like the stuff you're looking for. dotCMS has a JSON/XML Webservice that returns content based on queries. We use this a lot in almost all our projects, see here for more info: http://dotcms.com/docs/latest/ContentAPI. Using dotCMS itself for the whole frontend is also a possibility. Especially with the Spring controllers that it supports and the CSS-framework agnostic new template designer it is a nice way to build systems that require more than just some content.
  6. Multilingual. dotCMS offers a few ways to do this. You can create content in all languages that you need, even non textual content such as images. Because of the "content first" approach many things are content in dotCMS , and can be treated as such, including creating a version for each language that you need.
  7. Open source. dotCMS offers a community version that we use most of the time. Only for the pro features like load balancing, using oracle for the database, etc, a paid version is necessary. And even then the costs are manageable. See http://dotcms.com/products/editions/ for more details about this.
  8. Internal caching mechanism. Because of the high load some of the sites we have build need caching. DotCMS uses the Google Guava for their caching which works pretty well.
  9. Extendability, also a biggie. We needed to be able to extend the functionality of dotCMS for obvious reasons. DotCMS used to only offer an old school way of doing plugins that is kinda ugly and is based on an ant script that overwrites the dotCMS classes with your own. It works fine, but I always feel dirty after writing such a plugin. However since version 2 they offer an OSGi based plugin framework that is pretty sweet and much more developer friendly. It went out of beta in the 2.5 version. We're planning to port all of our plugins to the new framework.
  10. Multi host. We need to be able to host multiple sites within the same CMS. DotCMS provides this natively. It's also a nice way to share common stuff between multiple hosts which we use a lot.

Of course there are also down sides. Here are a few:

  1. Web CMSes like dotCMS store its content in a database and the assets as files on the disk. This makes versioning and synchronizing between different servers a pain in the butt. Starting from the 2.5 version dotCMS offers synchronizing tools that enable you to push content from one environment (for instance UAT) to another (for instance PROD), which helps. But not being able to checkout a single version of the content from something like GIT or SVN is very annoying. Especially since we as Java developers are accustomed to things like automated testing in a continues integration environment. Of course you can store the database as a SQL statement and the assets directory but that's slow and not so "nice". But then again all systems that store state in a database have this flaw.
  2. DotCMS takes some time to learn. It's not a small CMS like Wordpress that you'll understand in one afternoon. It has many features and is very powerful, but you'll most likely need a day or so to understand the dotCMS way and then another couple of days to understand all the API's. I do encourage you to first read some docs and tinker with it before building a real production site: many ways lead to Rome, but some of them consist out of quicksand. :)
  3. DotCMS is RAM hungry. To keep things fast it cached everything, so if you have a lot of content it will eat away at the RAM you have available. You can tweak this but it's easier to just give it enough RAM we have found.
  4. Not all configurations of WebDAV + editing client are compatible with dotCMS. For instance on a mac I have found that you best use Cyberduck as a WebDAV client and Aptana as a text editor. Other setups do freaky things that dotCMS does not like much. You got to play a little to find out what the best setup is for you. I did find that if you file a bug on their github they get it fixed in the next release. They told me that WebDAV is hard to get right because it's not a fixed standard which I understand but it can still be a pain in the butt.

If you want to learn dotCMS read their -not so bad- documentation: http://dotcms.com/docs/latest/TableOfContents and also take a look at their demo site (http://dotcms.com/products/demo/). In the demo site you'll find examples of all the concepts that dotCMS offers. Oh and check out our own free dotCMS plugins as well. Especially the JavaScript and CSS minifier is very handy: http://geekyplugins.com/.

Hope this helps a little. Let me know if you want to know more.

Kowloon answered 26/5, 2013 at 15:41 Comment(12)
Thanks a lot for the very extensive response! Would you say going through their own documentation is the best place to get started? Or is there some recommended tutorial site that's a must read?Lowman
I would read their documentation. I'm not aware about a real tutorial. There is however a book that handles the basic stuff about building sites in dotCMS: learndotcms.com/the-book It is a little outdated though, but handles the basic concepts nicely still.Kowloon
Thanks! ... some of my other concern with dotCMS would be it's using ant rather than maven. Also how's migration / upgrade effort when the release new version?Lowman
Well ant really isn't needed anymore with the newer OSGi plugin architecture, so that isn't a problem anymore. When a new version is released dotCMS includes an upgrade script that works fine for point releases (2.0. tot 2.1 for example). Migrating from main versions such as 1.9.5.1 to 2.0 is much more trickier. But those are only released every two to three years or so.Kowloon
dotcms.com "Spring & OSGi Dotcms dynamic plugin support gives developers the ability to hot deploy whole Spring web apps in dotcms without a restart. CMIS CMIS support allows dotcms content and files to be read and written by any system that is a CMIS client, including Sharepoint, Liferay and even Drupal." From en.wikipedia.org/wiki/…: "Content Management Interoperability Services (CMIS) is an open standard that allows different content management systems to inter-operate over the Internet" It is an adopted OASIS specification.Sandman
How much RAM is a good number for a UAT set up on doCMS ?Parsifal
Normally it depends mostly on the amount of content in the DataBase, but for a default site I'd say go with 1.5 GB for dotCMS in UAT. This is excluding the database.Kowloon
I really like this answer. I want to use dotCMS for my java application. but before setting it up in my local i want to confirm one thing..does it support multi user functionality? means different roles and render page as per loged in user role...if yes, I will set it up..now itself and if No, please suggest somethingKennard
Yes, it does. How it is best done depends on what kinds of things you want to differentiate on between users. For more info on this kind of thing I suggest you ask questions on their google group. groups.google.com/forum/#!forum/dotcmsKowloon
dotCMS looked really good comparing with Drupal features. But unfortunately dotCMS does not officially support docker which would be a deal breaker for adopting it.Ferous
I know they are experimenting with it. We use docker with dotCMS in our organisation to help with plugin development and automatic testing and that works fine. I guess you are referring to production deployments using docker images. That we did not use yet, so I don't really know if that will work well. About Drupal: The new Drupal 8 is actually even more flexible than dotCMS, but it's also (in my view) more complex to work with.Kowloon
TL;DR: SUPER long answer, so I skipped the whole text....... :(Jandy
F
6

Disclaimer: I work for Hippo, so I'll try to only answer with facts and not opinion :-)

  1. Hippo is fully Java based, front end is language independent, but geared towards JSP or Freemarker, optionally you can use a REST-interface and use whatever.

  2. Many plugins are created and collected at the Hippo forge.

  3. Content-centric design has been a staple of Hippo development, should pose no issue.

  4. Yes, by default all JCR calls are available. Apart from that you are able to define your own REST interface to suit your needs, example in the demo, documented here.

  5. I dare say yes, in my experience most non-tech users find the interface easy to understand.

  6. Multilingual is easy, part of the default multi-channel setup.

  7. The community edition (which is complete, no bait-and-switch) is open source, there is some enterprise functionality behind a proprietary license. The license also opens up support avenues, besides the Google Group and Stack Overflow.

Now, on your comment about the documentation being incomplete, let me offer my opinion: You are right, the documentation is an ongoing struggle. Most stuff is documented, but is hard to find. We are working on improving the overviews, introductions and tutorials, but we are obviously not done yet. If you can't find anything, usually the community is able to help and point you in the right direction.

Fan answered 27/5, 2013 at 8:50 Comment(6)
Thanks, one of the biggest thing about Hippo for me is its use of Maven. How's migration / upgrade effort with Hippo (ie. say we are at version 7.5 and then a new one is released, how hard is it to migrate to 7.6, what if it's major release to 8.0?). Also does Hippo have documentation on how set up is done between dev vs uat vs prod and how deployment is done?Lowman
Upgrading is indeed something to keep in mind, in the days before 7.5 this used to be a bit of a hassle, but since around that time (latest release is 7.8) Hippo has been much more focused on easing those transitions. I can't tell you how it will be between this and the next major release, that truly depends on what's going to be in there; I expect it to be relatively easy, as long as there aren't a lot of customizations in the core-CMS (i.e. use plugins rather than modify the core).Fan
Introduction into DTAP management is here: onehippo.org/7_8/library/concepts/upgrade/…Fan
If you guys write tutorial how to import existing html/css-based web-site to your system that would be very helpful.Fordo
Hi Ruslan, this isn't very straightforward, very dependent on what you actually want to achieve. It is probably best to start with the (video) trails here: onehippo.org/7_8/trails/video-trail/video-trail as these will give you an idea of the Hippo system.Fan
Does HippoCMS support docker?Ferous

© 2022 - 2024 — McMap. All rights reserved.