...
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, 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 with @Children as well.
Thanks to this you can make your code even cleaner. Check the following code snippets and see how Report
...
Since Slice 4.2 you can declare which (in a component definition) a model class your component should use in a component definition. 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, we you can define the following component's definition:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<?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, we you don't need to explicitly declare model in JSP file - it will be available out of the box, in a the JSP bindings object, like in the example below:
...
To simplify the code even more, you can put put <slice:defineObjects/> somewhere in global.jsp include - it allows you to avoid "bindings" part, so above code, can be simplified as follows:
...
We've introduce full semantic versioning to in Slice, so you can be sure that all interfaces are semantically versioned and you can upgrade safely with each minor release of Slice.
...