Introducing DD4T version 2.0 for Java

Over the past months a number of people have been working hard to beef up the current implementation of DD4T for Java, as was announced during the SDL Tridion User Group Benelux Meeting at Trivident last October.

As the work is now in its finishing stage, the time is right to reveal the changes that have been made to make working with DD4T for Java a better experience and to mature the framework to a level where it truly becomes a full framework in support of the Tridion Content Delivery Stack, as well as in terms of following standard Java practices.

The expected release date of version 2.0 is January 30th, 2015. Read on to see the long list of changes.

[Update: The release date of version 2.0 is rescheduled to March 2nd, 2015]

Functional Enhancements
As every Tridion developer knows, every web application implementation is nearly always in need of the same basic functional (Tridion) requirements, which are pretty much always done from the ground up and therefore giving you that feeling of: “Hey, didn’t I do this in my previous project as well?”. To not let DD4T developers worry over some of the standard boilerplate code anymore, DD4T for Java is enhanced with the following elements:

A default UrlPublicationResolver, which resolves the Publication Id based on the incoming URL;
JSTL tag support for XPM;
Fetching and using published Labels, including *system labels* like resolving TCM Id’s for Tridion elements like Component Templates, Schemas and Keywords;
Caching Tridion Objects and DD4T related objects in its own cache. The default implementation uses EHCache, but can also easily be used with other Java caching frameworks like JBoss’s native Infinispan caching;
A default JMS invalidation listener to invalidate items in the DD4T cache, which can be hooked up to any Tridion Deployer;
Abstract default Spring MVC controllers. These controllers do all the work when rendering Spring JSP views with model classes and are meant to be extended in your own web application. The main reason to do this is because it is quite unwieldy to have both the source of the DD4T stack as well as the source of your own web application in one project. With using a structure like this, it becomes possible to separate the two and link them only through a Maven POM. More on this below;
Version 1.0 of DD4T for Java used the ComponentFactory to fetch dynamic components. While this was certainly usable, the name is slightly misleading as Tridion can only publish Dynamic Component Presentations and not individual components. To align more with Tridion’s model, the ComponentFactory has been renamed to DynamicComponentFactory and behaves more in that sense: a Component Template view name or Id is required to fetch the actual content;
Taxonomy support has been vastly improved;
A new set of Providers have been written to fetch content from remote DD4T providers. All this happens through a JAX-RS based content service, which is connected to the Tridion Broker database. This separate Provider Service project will be made available as a separate Git repository;
Formalisation of the Factory classes. It has been decided that the Factory classes should be the only entry point into the DD4T stack. The main reason for doing this, is because it was felt that the Controllers should actually not be a part of the DD4T Core as they should always be close to the web application, of which the DD4T Framework is but a part and are to be loaded as dependency only. To achieve this, some functionality needed to be changed in the Factory classes. While more on this will be written, this diagram shows what the Page Factory class actually does in DD4T 2.0.
Last but not least: the minimum JDK version used will move from Java 6 to Java 7. While this is in line with the minimum Java versions Tridion supports for their major Tridion versions, Java 7 is considered to be the de facto current version to work on, mainly because of its numerous improvements, not to mention the fact that Java 8 is already on the way.

All these enhancements will require a new set of TBBs to be integrated in the Tridion CM. These will be released simultaneously with the release of DD4T 2.0 for Java. The TBBs are of course fully backward compatible with DD4T 1.0 for Java as well as for DD4T for .Net and only have to be used if you want to make use of the enhancements in DD4T 2.0 for Java.

As is always the case you can of course choose to not use the default implementations and roll your own. However, as is the case with the Tridion Reference Implementation, which DD4T 2.0.0 closely follows, the default implementations are there for a reason: they save you time in having to do it yourself from the ground up, while at the same time they have already been battle tested for you.

Data binding enhancements
DD4T 2.0 for Java has changed a lot in how it deserializes published data. In the “old” way Component models where pushed on the HttpServletRequest stack and used by MVC as generic beans to be used in Views. DD4T 2.0 introduces native support for “Strongly Typed Models”, which means you can use lightweight and strongly typed models in your JSP Views like so:
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %> <jsp:useBean id="news" type="org.dd4t.test.models.News" scope="request"/> <h2> ${news.heading} </h2>
The other good thing about the new databinding framework is that depending on configuration, Tridion Component Presentation data is deserialized straight into these strongly typed models, while deserializing into generic Component models is still an option if this is required. This increases performance a lot, because the step to first deserialize the data into generic Component objects is skipped. Additionally, again depending on configuration, these models become available based on the configured viewname(s) and/or Schema root element names you set on the model class:/** * Will be used to render all component data which * has Schema "post" and will be available for CTs * with viewName set to "news" or "events" */ @ViewModel( viewModelNames = {"news","events"}, rootElementNames = "post") public class PostViewModel extends TridionViewModelBase { @ViewModelProperty(entityFieldName = "heading") public String heading; }

This encourages reuse of the same model for different views and it essentially introduces polymorphism in MVC models based on Tridion Component Templates and Tridion Schemas. This is made possible because the DD4T developers changed the paradigm from making use of “rendered Component data” to actually making use of the fully rendered Component Presentation data.

Further important changes are:

Json is used as the default data format. The main reasons are that Json is easier to work with in Java and that it tends to be smaller than XML, which adds up in implementations which have a huge amount of pages or DCPs;
By default, rendered Json is published and stored GZipped and Base64 encoded, to further reduce the storage footprint, although it is also possible use unzipped JSON or even XML by changing configuration and dependencies;
DD4T 2.0 makes use of the Jackson FasterXML framework, which is the most mature and fastest Json data binding framework in the Java world.

Project Changes and loading DD4T as dependency
Three new modules have been added to the project:

dd4t-mvc-support: as with the .Net version of DD4T, the framework now provides a separate module which can be used as base for your own controllers. Currently, only Spring MVC support is added, but this may change in the future;
dd4t-providers-rs: the client side providers to be used in scenarios where fetching of Tridion content is offloaded to other servers;
dd4t-databind: the data binder project to support Strongly Typed Models.

The new modules complement the already existing ones, which form the core of DD4T for Java:

dd4t-api: the module containing all (and only) interface definitions for the entire framework.
dd4t-core: the implementation of the core framework, implementing a full dd4t-api code base.
dd4t-providers: the entry point to the Tridion Broker database, if the web application is configured to connect to the database directly.

All modules will be uploaded to Maven Central, which means you get to keep a nice and clean web application. In total, a typical vanilla Spring MVC web application will then only have to have the following dependencies listed in its POM:

<dependencies>  <dependency> <groupId>org.dd4t</groupId> <artifactId>dd4t-core</artifactId> <version>2.0.0</version> </dependency> <dependency> <groupId>org.dd4t</groupId> <artifactId>dd4t-mvc-support</artifactId> <version>2.0.0</version> </dependency> <dependency> <groupId>org.dd4t</groupId> <artifactId>dd4t-api</artifactId> <version>2.0.0</version> </dependency> </dependencies>

Nice and clean, right?

Backward Compatibility
DD4T 2.0 will try to be backward compatible as much as possible. Although the Interfaces defined in the API have changed slightly, the deprecated interfaces and interface methods are still present. Further, it will still be possible to keep using already published XML, although no support for Strongly Typed Models will be available.

Final thoughts
As DD4T for Java is maturing a lot in terms of code (SonarQube is used!), deployment models and usage, it becomes clear that more hands on deck are needed to maintain the framework. So, if you read this post this far and didn’t get scared, drop us a line if you are willing to help out. That also goes for those of you who want to have a sneak peak in the Git repository!