Instantiating models by following a path
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, e.g. you let authors configure references to some content and this reference is kept in property. To make reading of such referenced models easier, additional annotation @Follow
was introduced - it allows mapper to map a resource by following a path stored under 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. Check the following code snippets and see how Report
// 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:
<?xml version="1.0" encoding="UTF-8"?> <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 model in JSP file - it will be available out of the box, in the JSP bindings object, like in the example below:
<%@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 put <slice:defineObjects/>
- it allows you to avoid "bindings" part, so above code, can be simplified as follows:
<%@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
Throwing exception if fail to create injector
If for whatever reason, an injector of your application cannot be created (most likely due to some incorrect Guice bindings) you'd probably expect the Activator of your app to fail as well making your application unavailable and preventing hard-to-spot-and-debug runtime issues. We've just added this feature to InjectorRunner. If injector has failed on starting, InjectorRunner will throw BundleException
to force your Activator failure as well.
Improved support for updated bundles
If your application consists of couple of bundles you may have experienced an issue while updating only one of them. Slice had not seen this update and wasn't able to map objects from this bundle correctly. In Slice 4.2 we fixed this important problem. Therefore you can easily update a selected bundle 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 introduce 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.
Bug fixing
Slice 4.2.0 brings also fixes for some minor bugs. You can find full list of them in release notes.