This functionality has been renamed Sling Models and is documented at http://sling.apache.org/documentation/bundles/models.html
Many Sling projects want to be able to create model objects - POJOs which are automatically mapped from Sling objects, typically resources, but also request objects. Sometimes these POJOs need OSGi services as well.
YAMF is an attempt to consolidate the various approaches I have seen to this problem.
- Entirely annotation driven. "Pure" POJOs.
- Use standard annotations where possible.
- OOTB, support resource properties (via ValueMap), SlingBindings, OSGi services, request attributes
- Adapt multiple objects - minimal required Resource and SlingHttpServletRequest
- Client doesn't know/care that YAMF is involved
- Support both classes and interfaces.
- Work with existing Sling infrastructure (i.e. not require changes to other bundles).
In the simplest case, the class is annotated with @Model and the adaptable class. Fields which need to be injected are annotated with @Inject:
In this case, a property named 'propertyName' will be looked up from the Resource (after first adapting it to a ValueMap) and it is injected.
For an interface, it is similar:
In order for these classes to be picked up, there is a header which must be added to the bundle's manifest:
Client code doesn't need to be aware that YAMF is being used. It just uses the Sling Adapter framework:
As with other AdapterFactories, if the adaptation can't be made for any reason, adaptTo() returns null.
If the field or method name doesn't exactly match the property name, @Named can be used:
@Injected fields/methods are assumed to be required. To mark them as optional, use @Optional:
A default value can be provided (for Strings & primitives):
Defaults can also be arrays:
OSGi services can be injected:
In this case, the name is not used -- only the class name. Lists and arrays are supported:
OSGi injection can be filtered:
The @PostConstruct annotation can be used to add methods which are invoked upon completion of all injections:
@PostConstruct methods in a super class will be invoked first.
If the injection should be based on a JavaBean property of the adaptable, you can indicate this using the @Via annotation:
If there is ambiguity where a given injection could be handled by more than one injector, the @Source annotation can be used to define which injector is responsible:
If the injected object does not match the desired type and the object implements the Adaptable interface, YAMF will try to adapt it. This provides the ability to create rich object graphs. For example:
When a resource is adapted to MyModel, a child resource named image is automatically adapted to an instance of ImageModel.
- @Model - declares a model class or interface
- @Inject - marks a field or method as injectable
- @Named - declare a name for the injection (otherwise, defaults based on field or method name).
- @Optional - marks a field or method injection as optional
- @Source - explictly tie an injected field or method to a particular injector (by name). Can also be on other annotations.
- @Filter - an OSGi service filter
- @PostConstruct - methods to call upon model option creation (only for model classes)
- @Via - use a JavaBean property of the adaptable as the source of the injection
- @Default - set default values for a field or method
|Title||Name (for @Source)||Description||Applicable To (including using @Via)||Notes|
|Value Map||valuemap||Gets a property from a Value Map||Any object which is or can be adapted to a ValueMap|
|OSGI Services||osgi-services||Lookup services based on class name||Any object||Effectively ignores name.|
|Script Bindings||script-bindings||Lookup objects in the script bindings object||A ServletRequest object which has the Sling Bindings attribute defined|
|Child Resources||child-resources||Gets a child resource by name||Resource objects|
|Request Attributes||request-attributes||Get a request attribute||ServletRequest objects|