Tuesday, October 8, 2013

Webinar: Blossom Q & A recording online

The recording of my Q & A webinar on Blossom is online. A whole bunch of questions were submitted and I think I managed to answer them all. It starts with an introduction to the module and what's coming up in the next version.

Grab some popcorn, lean back and enjoy!


Friday, September 20, 2013

Blossom 3.0 release candidate 1 released

This week at the Magnolia conference we released Magnolia 5.1 RC1 and with it I released Blossom 3.0 RC1. The feature set is stable since alpha1 but on a deeper level there were many changes to the inner workings of presenting dialogs.

See my earlier blog post on alpha1 for in-depth details on Blossom 3.0 features.

Note that the RC1 of Blossom requires at least Magnolia 5.1 RC1.

UPDATE: The groupId changes to info.magnolia.blossom starting with this release, use this snippet for your maven poms.

<dependency>
  <groupId>info.magnolia.blossom</groupId>
  <artifactId>magnolia-module-blossom</artifactId>
  <version>3.0-rc1</version>
</dependency>

Blossom at SpringOne 2GX 2013

I had the pleasure of presenting Blossom and Magnolia CMS at this year's SpringOne conference in Santa Clara California. The conference took place over the course of three intense days with tons of interesting talks. At the keynote Pivotal announced the Spring IO platform and Chris Beams even launched the new site spring.io right there on stage.

Our talk was on the first day right after lunch, me and my co-presenter Daniel Lipp showed what Magnolia can do for Spring developers and I shared my experience of integrating it with Spring Web MVC. I wrote the Blossom module so I wouldn't have to write my own CMS for my Spring projects. It surprised me hearing from so many attendees coming to our table in the exhibit hall that that's exactly what many people do.

SpringOne 2GX is also the biggest Grails event of the year. Many attendees I talked to who where there primarily for the Grails talks were thrilled to here about Maglev, the Grails plugin that bundles Magnolia CMS with Blossom and brings it to the Grails platform. Using the same annotation based API but on Grails classes instead.

The slides from the talk is up on slideshare, it was recorded and will be available on youtube soon.







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>