Discover new features of Slice 4.2

08 May 2015
Maciej Majchrzak
Frink_Cognifide_2016_HeaderImages_0117

Dear Slice Users, I’m very happy to share with you a still hot version of Slice framework – Slice 4.2. The release which we’ve done just recently is definitely not a revolution but as usual it brings a set of new features and fixes. I hope they make your dev lives easier than before and help you develop your AEM/Sling projects with bigger smiles.

If you don’t know what Slice is, I really encourage you to grab some coffee, make yourself comfortable and read my previous blog posts about this Cognifide’s major open source project. I’m sure it will help deliver your projects faster and maintain them easier. Here you can find some initial reads: Slice conceptsusing Slice and Sightly together for greater benefits.

Slice 4.2 features

Slice 4.2 brings two new features, six improvements and five bug fixes. For the full release notes please refer to Slice’s documentation. Slice 4.2 is backward compatible so if you’re already using Slice 4.x you can safely upgrade to the new one. And it’s definitely worth doing so! Just get yourselves familiar with a list of new features – I’m describing the most important ones below.

Instantiating models by following a path

This is without hesitation my favourite aspect of this release! It's a very common case when you keep a path in some property and you want to build a model based on a resource pointed by this path, for example, you let authors configure references to some content and this reference is kept in property. To make the reading of such referenced models easier, the additional annotation @Follow was introduced - it allows mapper to map a resource by following a path stored under a given property. It is possible to use this annotation in conjunction with @Children as well.

Thanks to this you can make your code even cleaner. Review the following code snippets and see how the code has been simplified by using the new feature.

// Now - with @Follow annotation
@SliceResource
public class ReportComponent {

    @Follow
    @JcrProperty(value = "reportPath")
    private ReportModel report; // this will build ReportModel based on resource path
                                // kept in reportPath property of current resource
    
    public String getReportValue() {
        return report.getValue();
    }
}

// Before
@SliceResource
public class ReportComponent implements InitializableModel {

    @JcrProperty
    private String reportPath;

    private ReportModel report;

    private ModelProvider modelProvider;

    @Inject
    public ReportComponent(ModelProvider modelProvider) {
        this.modelProvider = modelProvider
    }

    @Override
    public void afterCreated() {
        report = modelProvider.get(ReportModel.class, reportPath);
    }

    public String getReportValue() { 
        return report.getValue();
    }
}

Static declaration of model class

Since Slice 4.2 you can declare (in a component definition) a model class your component should use. If you do this, you can simplify your JSP file and omit the slice:model tag. Slice will provide an expected model through JSP bindings and set a model object for JSP use.

For example, you can define the following component's definition:

<jcr:root xmlns:slice="http://www.cognifide.com/slice/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"
    jcr:primaryType="cq:Component"
    jcr:title="Rich Text"
    slice:model="com.example.RichTextModel"/>

In such case, you don't need to explicitly declare the model in the JSP file - it will be available out of the box, in the JSP bindings object, such as:

<%@page pageEncoding="UTF-8" contentType="text/html; charset=UTF-8"%>
<%@include file="/libs/foundation/global.jsp"%>
 
Richtext content: ${bindings.model.text}

To simplify the code even more, you can use <slice:defineObjects/> - it allows you to avoid "bindings" part, so the above code, can be simplified to:

<%@page pageEncoding="UTF-8" contentType="text/html; charset=UTF-8"%>
<%@include file="/libs/foundation/global.jsp"%>
<slice:defineObjects />
 
Richtext content: ${model.text}

This feature may also be useful for some more general solutions, where you can use newly-introduced method of ModelProvider: get(Resource) - this will return mapped object without specifying its class on code level.

For improved performance it's advised to upgrade AEM/CQ add-ons too. See details below.

Updated add-ons

The AEM60 add-on and CQ56 add-on have been updated to optimize reading of component definition so it's highly advisable to upgrade them too if you're upgrading from previous versions of Slice. They use AEM's ComponentManager which provides information about components with some nice caching. The updated add-ons include:

  • AEM60 add-on - version 1.1.0
  • CQ56 add-on - version 2.1.0

Improved support for creating injector and updated bundles

Do you remember a case where all of your bundles are up and running, but the injector/context is not available, causing weird runtime errors and stack traces in logs? If so, you can finally forget about it - since Slice 4.2 your activator bundle will never be Active if injector fails on creation. You can also update bundles of your app independently and Slice will be informed about this change providing correctly mapped objects.

Updated dependencies

Since Slice 4.2, it is possible to use Lambda expressions (Java 8) thanks to upgraded ASM dependency. Slice has also started to use Peaberry 1.3 which supports a Dynamic Configuration feature.

Semantic versioning approach

We've introduced full semantic versioning in Slice, so you can be sure that all interfaces are semantically versioned and you can upgrade safely with each minor release of Slice.

What next?

I hope you enjoyed new features we’ve just delivered in this Slice release and that you soon upgrade to Slice 4.2. We really count on your feedback which you can share through our mailing list. I’d also like to thank all of the active users for feedback we’ve received so far - it is really appreciate as it helps us make Slice even better.

If you are curious about Slice features, I can tell you that we’re now working on a Slice roadmap and backlog for the next releases - I hope to share details soon. Also, we’ve just started to pay more attention to tests of Slice code itself. For this purpose, we’ve decided to use another great open-source lib called Prosper.

Useful links: