Hi,
I am not sure about the best names for the annotations. Sling is not really
consistent whether the resource has properties (which smells a bit like JCR) or
values. Actually the name ValueMap indicates, that the proper name for Sling is
rather value than property, but even the Javadoc
Hi Justin,
Unfortunately to annotate an annotation with @Inject is not allowed. The
annotation is only allowed on methods, constructors and fields.
Do you think that it would be acceptable to come up with another
inject-annotation which is also allowed on annotations?
That should just be an
Ah, good point. Yes, I think we should have a custom @Inject-like
meta-annotation. Can't think of a good name now :)
On Thu, Mar 20, 2014 at 11:48 AM, Konrad Windszus konra...@gmx.de wrote:
Hi Justin,
Unfortunately to annotate an annotation with @Inject is not allowed. The
annotation is only
Hi all,
+1 for having meta annotations, I think they make model classes a lot
more readable and give a small performance boost (outweighs the use of
standardised @Inject IMHO).
Regarding the naming I'd choose @ResourceProperty avoiding the name
clash with
Hi Justin,
thanks for your answer. What about if I come up with a patch for additional
annotations like
@InjectSlingValue and @InjectOsgiService
which are just another way of annotating fields/methods and combine logically
both the Inject and the Source. In case of InjectOsgiService one could
Hi Konrad,
I don't know about those names (@InjectSlingValue specifically -
what's a Sling Value?), but I think making @Inject work via
meta-annotations make sense. That support already exists for @Source,
would just need to be extended to work with @Inject as well. I just
did a little refactoring
Hi Justin,
great. Thanks a lot for that fix. What do you think of the following
annotations:
@SlingProperty (implies @Inject and @Source(“valuemap”))
@OsgiService (implies @Inject and @Source(“osgi-service”))
@SlingChildResource (implies @Inject and @Source(“child-resource”))
In my regard they
Hi Konrad,
How about just @Property and @ChildResource ? As with the @Model
annotation, I don't see a reason to add sling as it is already in
the package name.
@Property has overlap with SCR annotations, but I can't think of a
reason you would have them in the same class (and in any case, that's
Hi,
I am a little bit worried that model classes which leverage the Sling Models
annotations might be slow and break fast.
If you use the annotation @Inject without @Source all injectors are asked until
one returns a value.
Since almost all injectors depend on the fieldname and cover the same
