Model classes vs Interfaces

[Aryan12345]

Hello,

I am slightly new to the world of sling models. More used to JSP and custom taglibs (and implementing my own "idea" of models by using reflections) than models. Whatever i have done with models is limited to simple injections, references and self injections.

Recently i was fooling around with some examples from the sling portal and came across this:

@Model(adaptables=Resource.class) public interface MyModel { @Inject String getPropertyName(); }

Then i started wondering why and when you would ever use interfaces? I tried simple parent child relations and it worked well.  But when would i ever write model interfaces and in which scenarios would i ever use them and how does it work?

Pardon me if the question is too basic.. but just could not get this...

thanks,

Yadhu

[Jitendra_S_Toma]

Hi Aryan,

Basic Idea is as simple as Class vs Interface. You can do everything with class however interface comes with own advantage. In sling models, I can see interface model can be reused easily rather than keep extending the base class model to your custom class model.

Here is a very good document around it.  This document described multiple use cases which might be useful for you to understand the difference.

Apache Sling :: Sling Models

I hope this helps.

Regards,

Jitendra

[smacdonald2008]

As far as using Sling Models to write components - here are some good examples:

1 - Creating a custom Touch UI Grid Component for Adobe Experience Manager

2- Adobe Experience Manager Help | Creating a HTL Repeating Data Set 6.3 Component that uses Sling Mode...

3 - Building Experience Manager Components using Granite/Coral Resource Types

These will get you up and running with Sling Models and HTL components.

[smacdonald2008 · Accepted solution]

Use of JSP and custom taglibs should be replaced with HTL/Sling Models.  Also - i recommend going through these sections: Getting Started with AEM Sites - WKND Tutorial

[smacdonald2008]

Nice answer Jitendra Singh tomar

[Aryan12345]

Hey thanks all for the responses.

smacdonald2008​ is this the paragraph you wanted me to see? I think this is probably the most direct answer to my question.... I need to read up more on adapters i think.... am i right? Apart from that and of course what Jitendra mentioned about the general use of interfaces, i dont see any reason why i would use a interface instead of a concrete class... please let me know what you think

The @Model annotation registers CardImpl as a Sling Model when it is deployed to AEM. The adaptables parameter specifies that this model can be adapted by the request. The adapters parameter allows the implementation class to be registered under the Card interface. This allows the HTL script to call the Sling Model via the interface (instead of the impl directly). More details about adapters can be found here. The resourceType points to the Card Component resource type (created earlier) and helps to resolve the correct model if there are multiple implementations. More details about associating a model class with a resource type can be found here.

[smacdonald2008]

Correct - the part where Daniel talks about building a Card component is the part i wanted you to see. All 6 parts are actually very valuable.

[Aryan12345]

Cool..

smacdonald2008​ thanks a million for the links.. i did a lot of playing around with models... did some really weird things and it was fun.... but now i am bumping in to something which i am not able to wrap my head around... there is the concept of source and there is a concept of via. @Source is an annotation which helps me select an injector out of available registered injectors if i want to force one.... and @Via helps me change the default injection behaviour in the context of a given injector... Around these i had the following questions....

1. Whats the difference between @Source and @Via - My understanding is @Source tells who injects the value... and it is always in the context of the adaptables in your @model annotation... certain sources will not work it adaptables is resource and certain ones will not work is the adaptables in SlingHttpServletRequest. and within the context of a @Source @via tells how the behaviour should be. Here is a weird example but one that works

    @Inject

    @Source("child-resources")

    @Named("topnav")

    @Via(value = "jcr:content", type = ChildResource.class)

    String text;

Means inject with injector "child resources", name of the node is "topnav" and within that context, go to the child called jcr:content and get the property name called text. I know i could have done it much easily with one line but this is just for discussion sake.

Is my understanding correct so far? If yes, are there more examples you can give me?

2. Is the use of injector specific annotations like @ScriptVariable only to reduce the number of lines of code as they look like nothing but two or three basic annotations packed up together.

3, when would i write a custom injector? Is writing a custom injector to pickup request params from a servlet a good scenario?

4. Now the most interesting question... I came across some models which have something like this on the top @Model (adaptables={Resource.class, SlingHttpServletRequest.class}. this got me thinking... i tried doing this... never is this treated like a resource. the SlingHttpServletRequest is taking precedence as @Self never gives me a resource.. @Inject never gives me the valuemap value. I am forced to add @Via("resource") which proves SlingHttpServletRequest takes precedence... so it brings me to the question of why this is done? what is the real use or is this just a buggy piece of code?

eagerly looking forward to an answer... Playing around with sling models has been real fun.. thanks for the links so far.....

[Aryan12345]

Hi.. any other takers for this question? any help on this would be great.

[smacdonald2008]

A lot of your questions are addressed here -- Apache Sling :: Sling Models