Thursday, August 29, 2013

Magnolia CMS and Blossom on Chariot TechCast

There's a new episode out of the Chariot TechCast, this time the topic of discussion is Magnolia CMS and the Blossom spring integration module. Listen in as Boris Kraft, CTO of Magnolia and myself talk with Ken Rimple about the history of Magnolia, the revamped user interface in version 5 and of course in depth about how the Blossom module works!

The podcast is available on iTunes and as a direct download on the Chariot TechCast site.

For iPhone there's a great podcasts app from Apple, that I discovered only recently. It lets you subscribe to podcasts and can download new episodes automatically when on WiFi as they become available. Check it out and subscribe to Chariot's podcasts, lots of interesting stuff in these for Spring developers.

Wednesday, August 28, 2013

Submit your Blossom questions in our online Q&A

As I mentioned in my last blog post, Blossom 3 brings a number of changes to how dialogs and fields are configured. To make it easier to understand these changes, I'll be hosting an online Q&A in about three weeks to answer user-submitted questions about the new Blossom module.

Register now and submit your questions.

I'll be hosting this online event on 26 September at 5 PM CET (8 AM PDT) together with my colleague Daniel Lipp. If you run into problems integrating your Spring application with Blossom 3, or have suggestions for improvements, this is the ideal forum to make your voice heard and have your issues resolved.

See you there!

Friday, August 23, 2013

Blossom 3 alpha 1 released

I have just released the first alpha of Blossom 3.

Blossom 3 is a major update that brings support for Magnolia 5. In particular the new dialogs introduced as part of the brand new user interface.

Blossom 3 builds on Magnolia 5.1, which is also in development and both will be released this September in time for this years Magnolia conference.

The new user interface is built using Vaadin. A component based UI toolkit where the components run on the server and renders on the client using Google web toolkit. This makes it much easier than before to develop custom fields for your projects.

In previous versions of Blossom you would create and configure controls, now instead you build an object model that defines how the dialog and its fields should appear and behave. This definition
model is then used as a blueprint to create and configure Vaadin components.

For composing the definition model Blossom 3 uses a builder style API that creates a more fluent programming style. A new set of classes replaces the previous API. These classes include a new TabBuilder and DialogBuilder and provides builders for each of the built-in fields, making it easier to configure properties on the fields.

@TabFactory("Content")
public void contentTab(UiConfig cfg, TabBuilder tab) {
    tab.fields(
            cfg.fields.text("title").label("Title"),
            cfg.fields.checkbox("hideInNavigation").label("Hide in navigation").description("Check this box to hide this page in navigation")
    );
}


The fields now have much better support for validation which is why @TabValidator and @DialogValidator have been removed in this version.

@TabFactory("Content")
public void contentTab(UiConfig cfg, TabBuilder tab) {

    tab.fields(
            cfg.fields.text("title").label("Title").validator(
                    cfg.validators.email().errorMessage("A title is required")
            ),
            cfg.fields.checkbox("hideInNavigation").label("Hide in navigation").description("Check this box to hide this page in navigation")
    );
}


Using Springs freemarker macros for forms is now straight forward. When rendering freemarker views Blossom will expose a RequestContext object which these macros require, it will also expose everything in the model as request attributes. This feature is enabled by default but can be switched off on the FreemarkerTemplateViewRenderer..

The multipart support that bridges Springs multipart handling to the multipart support in Magnolia has been updated for API changes in Spring 3.1.

The sample has also been updated and as always, this is the best place to start.

Get the source and start it up with these commands:

git clone http://git.magnolia-cms.com/git/modules/blossom/samples.git
cd samples
git checkout magnolia-blossom-samples-3.0-alpha1
mvn install
cd magnolia-blossom-sample-webapp
mvn jetty:run-war

UPDATE: When running it like this from the command line you might run into issues where the application does not have enough memory, especially in the perm gen pool. To get around that do this first:

export MAVEN_OPTS="-XX:+CMSClassUnloadingEnabled -XX:PermSize=256M -XX:MaxPermSize=512M -Xmx512m"

UPDATE 2: The alpha1 release of Blossom builds on the alpha1 release of Magnolia 5.1. If you need to use a more recent build of Magnolia 5.1 you should use the corresponding Blossom release or use the latest SNAPSHOT.


Stay tuned!

Thursday, May 24, 2012

Vaadin applications and tabbed browsing


For Magnolia CMS 5 we're developing a new user interface using Vaadin and plenty of custom GWT (Google Web Toolkit) on the client side. One of the challenges that we've had to solve is support for tabbed browsing. Vaadin's core concept is that there's state on the server that represents the state of the UI and there's also state on the client that represents what's being displayed.

Given a running Vaadin application in one browser tab, what happens if the user copies the application's URL and opens a new tab with the same URL?

The new tab will use the same server side state and go from there causing the first tab to go out of sync. The problem is that there's now two clients using the same server side state. And here lies the problem:

How can we make sure each tab has its own state on the server when the server has no way of finding out which tab is sending it a request?

There's a fix suggested by the Vaadin folks that uses multiple windows within a Vaadin application where each tab is supposed to get its own window. In this context a window is a server side component representing a whole browser page. However, this has a number of flaws. The first obvious problem is that a Vaadin application is synchronized and processes requests one by one, so if there's a lengthy operation in one window then all windows are stalled. The second problem is how it uses the URL. When you open the application in a first tab the URL is the same as without the fix. It uses the default window. When you copy and paste its URL to a new tab Vaadin will automatically create a new window on the server and add its generated window name to the URL. So far so good, two tabs in the browser each using a different window component on the server side. But when the user copies the URL from the second tab, the one that includes a window name, there's nothing done to create a new window. As a consequence the newly created third starts using the same window causing the second tab to go out of sync.

Another possible solution could use the HTTP referer header, then the server could look at that and see which application the client is using. An id for the application would then be part of the URL. But the referer header is optional and there are browser plugins and proxy servers that removes it for privacy reasons so we don't want to depend on it being there.

The solution I came up with takes advantage of the fact that there's a property on the javascript window object called name that survives a page reload. As far as I now this is the only state that is kept when you navigate in a browser or reloads the page. We can use this to keep track of which application we're using. That is, the id of the server side state this browser tab is connected to. But the server still has no idea when it's serving a request.

Vaadin is a single page web application where the first request sends a bootstrap page that loads javascript which then drives the application by issuing ajax requests to the server. The same thing happens on reload or opening a bookmark. By adding a javascript snippet to this page that checks the window.name property we can direct the ajax calls towards a specific application on the server. In the bootstrap page we embed an application id suggested by the server. The client then decides if it wants to use it or if it wants to use an id it has placed in window.name.

Here's a simplified example of how it works:

public class MultipleBrowserWindowsApplicationServlet extends ApplicationServlet {

    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        if (requestIsNotAnAjaxCall(request)) {

            // Generate a new application id that we'll suggest the client can use
            String applicationId = generateNewApplicationId();

            // Serve the bootstrap page with the suggested application id
            writeBootstrapPage(request, response, applicationId);
        } else {
            super.service(request, response);
        }
    }
}

The bootstrap page includes this script that does the trick:

<script type="text/javascript">
//<![CDATA[
  if (!window.name) {
    window.name = <application id suggested by the server>;
  }
  vaadin.vaadinConfigurations["ctxpathmagnoliavelvet-268765284"]["appUri"] += "/" + window.name;
//]]>
</script>

And voila, the client keeps track of which state on the server it's connected to and directs its ajax calls to it. This way it keeps using the same application on the server after a page reload or opening a bookmark and the user is free to copy and paste the URL in a new tab.

To finalize the solution there were a few things I had to solve.

The most problematic was that Vaadin creates and starts an application on the server before it sends the bootstrap page. This is problematic because it creates applications that are never actually used. It took some experimentation to get this solved properly. Fortunately Vaadin already supports creating and starting the application on the first ajax call if it hasn't already been done, so that part just worked.

Another problem was the 'restartApplication' parameter that is used to force the creation of a new application on the server. If the client always prefers the id it has in window.name that makes this parameter useless. To solve it I extended the bootstrap page a bit so it can force the client to use the suggested application id when necessary.

In summary, having state both on the server and on the client is a challenge when it comes to tabbed browsing. This solution works because it's a single page web application that's entirely driven by ajax after that first request.

The source code is available, posted on pastie.org for prettier formatting =) To use it change the servlet class in web.xml. Because the theme and the caption (the title of the page) is set in the bootstrap page and the application is started after the bootstrap page has been served those are set using init parameters to the servlet. Use a snippet like this:

  <servlet>
    <servlet-name>MyApplication</servlet-name>
    <servlet-class>info.magnolia.ui.vaadin.integration.servlet.MultipleBrowserWindowsApplicationServlet</servlet-class>
    <init-param>
      <param-name>theme</param-name>
      <param-value>myTheme</param-value>
    </init-param>
    <init-param>
      <param-name>caption</param-name>
      <param-value>My Application</param-value>
    </init-param>
  </servlet>

Wednesday, December 28, 2011

CMIS support for Magnolia CMS


This autumn I've had the opportunity to work on implementing CMIS support in Magnolia CMS. CMIS stands for Content Management Interoperability Services and is a specification administered by OASIS. The goal is to improve interoperability between content management systems and it achieves this by defining a model representing the content in a repository and a set of services for accessing it. The services come in two flavors, SOAP Web Services and REST-style services using ATOM-format.

The first version of Magnolia to have CMIS support will be 4.5. The scope of the first release is to expose the DMS in Magnolia over CMIS. This means that you will be able to download, manipulate and store content in Magnolia and access Magnolia content in other CMIS enabled systems.

The implementation is based on OpenCMIS. An open source framework for implementing both server and client -side implementations. It's one of the libraries developed by Apache Chemistry. Of special interest to us is the server binding to JCR. OpenCMIS implements the services which delegates to a binding. We have extended the JCR binding to match the repository layout we use in Magnolia and integrated the OpenCMIS authentication mechanism to use our security model.

In the process we encountered a few things we wanted to improve to make OpenCMIS adaptable to our repository layout. We developed this and contributed patches that were accepted by the active and focused team working on OpenCMIS. As a result our implementation is quite minimal and mainly consists of mapping the CMIS model onto our JCR layout. The value of OpenCMIS is impressive, an entire stack with both SOAP and REST that only needs to know how to interact with the specifics of a JCR layout.

The source code for the Magnolia CMIS Module is publicly available as always.

Tuesday, November 22, 2011

Blossom 1.2.3 & Blossom Data Extension 1.0 Released

Today I have released version 1.2.3 of Blossom and Blossom Data Extension 1.0, an extension for using Blossom style dialogs with the Magnolia Data Module. It introduces a new annotation @DataTypeDialogFactory which is used for creating dialogs for data module types. It has the same feature set as @DialogFactory and is used in the same way.

In this release the feature set TabBuilder is expanded adding support for the multi select control, the include control and for adding any control by type. It's now also possible to get the dialog and the DialogCreationContext from the TabBuilder.

This is an example of how a dialog used for the type 'category':
@DataTypeDialogFactory("category")
public class CategoryDialog {

    @TabFactory("Settings")
    public void settingsTab(TabBuilder tab) {
        tab.addEdit("name", "Name", "");
        tab.addEdit("maxResults", "Max results", "");
    }
}

To use the Data Extension you need to add it to your pom.xml
<dependency>
  <groupId>info.magnolia</groupId>
  <artifactId>magnolia-module-blossom-extension-data</artifactId>
  <version>1.0</version>
</dependency>

Add this line to your blossom-servlet.xml or equivalent.

<bean class="info.magnolia.module.blossom.extension.data.DataDialogExporter" />

And if you're using classpath scanning you'll also want to add an include-filter for the new annotation.

<context:component-scan base-package="package-containing-dialogs" use-default-filters="false">
  ...
  <context:include-filter type="annotation" expression="info.magnolia.module.blossom.extension.data.DataTypeDialogFactory"/>
</context:component-scan>

For more details see the Blossom Data Extension wiki page.

Monday, November 7, 2011

Webinar - How US Navy used Blossom to integrate Spring Applications with Magnolia CMS

I have some exciting news to share!

As many Blossom users are already aware, Campbell Ewald used Magnolia CMS and Spring Framework for building navy.com. On November 15th there will be a webinar on how they did it and how Blossom made their app integrations straightforward. It will be hosted by Campbell Ewald's Matt Dertinger, Magnolia's Sean McMains and myself.

The webinar is for Spring developers of all levels and you will learn how to develop content rich websites with Spring. It will take you through setting up your project and with examples show how Blossom solved real use cases for the navy. Matt will also show how they used it with RESTEasy and took advantage of Bean Validation (JSR-303).

Register now, I've been told it's starting to fill up already.

See you there!

UPDATE
The webinar recording is now online.