I joined Magnolia in 2006. Unbeknownst to me at the time, I was joining a company that went through a bunch of hoops, ups and downs, and was just on the verge of taking a huge bet by releasing its first “Enterprise Edition” – a paid-for version of an otherwise free and open-source piece of software, which was a fairly new concept at the time. Oh well, what could go wrong ?
I shook hands with 4 persons that day. Now I’d need 4 flights, or go over 4 continents to shake hands with everyone in the company. (Cue naysayers who will find better travel plans, or simply are better at 1st grade maths than I am)
Not being much of a historian, I’ll spare the details of what we’ve been through since, but in keeping with the playing with numbers, I’ll try to come up with a list of my own. Instead of dwelling on the past, here’s what I’m trying to do: list 7 features of Magnolia that are perhaps a little underrated, along with suggestions for improvements or contributions. One for each year I spent working with and at Magnolia, not just because I’m too lazy to come up with ten
Looking forward for your thoughts, ideas, patches (and forge projects ;-)) in the comments below !
1. Runtime configurable, pluggable filter chain and servlets. You can add filters to your Magnolia instances on the fly, without restarting. (see configuration,
/server/filters). Servlets can also be added the same way – Magnolia wraps servlets into a filter, which is in turn added to the filter chain like any other filter, and voilà. Thanks to this, modules can provide additional filters or servlets to the default Magnolia features; many major Magnolia features are actually implemented through filters (security, cache, rendering, …) or servlets (AdminCentral, imaging, feeds, …) This allowed us to implement REST support (see below), WebDAV, etc as modules. One thing that’s been tingling me for a while are our virtual URIs; they ARE in fact implemented via a filter – but are somewhat limited; how about implementing support for the great URLRewriteFilter ? – it should even be possible to have it configured via the repository as well ! Other ideas that have been tossed around (and perhaps implemented, just never shared?): Web Resource Optimization for Java, SiteMesh, …
2. Rest support. With the new REST modules provided since 5.2, we not only provide a basic REST API to access your Magnolia content, but more importantly, we made it even easier to deploy your own REST services. Out of the box, you get simple end points to access nodes and properties as well as the ability to execute arbitrary commands. We figured that besides that, services could quickly become project-specific; however, we’re also sure great ideas will surface – what would you suggest ?
3. Groovy support. With the Groovy module, we made it possible for virtually any class in Magnolia to be implemented in Groovy, as well as use the repository as a classloader for such classes – so you can not only edit your code within Magnolia (or via WebDAV), but you can also publish to your public instances. Among the possibilities we thought of was having rendering model classes and templates entirely in the repository, which would bring some level of flexibility to developers and administrators alike – no need to intervene on the server for simple or one-off modifications. Have you ever done this ? Any feedback ? Have you ever used the Groovy module for anything else that we didn’t expect ?
4. Templating languages. With 3.5 (if memory serves right), we implemented support for FreeMarker for page components (formerly known as “paragraphs”). With 4.0 (same disclaimer), we generalized this support for page templates as well. In fact, rendering engines have since been entirely pluggable, and we were hoping to provide built-in support for other templating languages, such as Velocity (which was often requested at the time). We have not seen a contribution for this yet, but I’ve been tinkering with the idea of adding support for Mustache, for example. Any takers ?
As a side note, have a look at Adam Galloway’s great presentation at the Magnolia Conference 2013 – which definitely has something to offer in this respect, and much more than “just another templating language”.
5. Imaging. When originally conceived, we tried to keep the Imaging module agnostic from any image processing library; the quality of Java’s image processing is debatable (at the very least, we can agree it’s not consistent between versions of the JDK). I’ve always been convinced that ImageMagick could be integrated. The ImageOperation interface and its many implementations would probably become useless, but .. I wouldn’t necessarily see that as an issue – these are indeed made to work with
java.awt.image.BufferedImage – while IIRC ImageMagick just works with streams – which is something (again, IIRC)
ImageStream could handle. What do you think ?
6. Workflow. Ever had the need to use a different workflow engine than the one we shipped ? While it might have been quite the challenge up to Magnolia 4.5, it’s become more pluggable since 5.1. I’m far removed from the world of workflow engines, so I wouldn’t know what to suggest. Mostly, I’m curious if anyone’s done it, tried to do it, or would like to do it, with what back-end and with what results !
7. Open source and community. This is going to sound dorky and perhaps even like flattery, but Magnolia’s community keeps on surprising me. I’ve mentioned it a few times on this too rarely updated blog, but every couple of months I have one of those a-ha moments where I am secretly jealous that I didn’t get the idea I was just presented with first. The fact that Magnolia is open source software is one of the major reasons I joined the company in the first place, so I do consider that and its community a feature !
So here’s to another 7 years, I suppose ! A big shout out to colleagues old and new, and my (3?) readers … and some random pictures