Använda Sling-adaptrar

Sling erbjuder Adaptermönster att enkelt översätta objekt som implementerar Adaptiv gränssnitt. Det här gränssnittet innehåller en allmän customiTo() metod som översätter objektet till den klasstyp som skickas som argument.

Om du till exempel vill översätta ett Resource-objekt till motsvarande Node-objekt kan du bara göra följande:

Node node = resource.adaptTo(Node.class);

Användningsexempel

Det finns följande användningsområden:

• Få implementeringsspecifika objekt.

  En JCR-baserad implementering av den generiska Resource -gränssnittet ger åtkomst till underliggande JCR Node.

• Skapa genvägar för objekt som kräver att interna kontextobjekt skickas.

  Den JCR-baserade ResourceResolver innehåller en referens till begäran JCR Sessionsom i sin tur behövs för många objekt som ska fungera baserat på den begärandesessionen, som PageManager eller UserManager.

• Genväg till tjänster.

  Ett sällsynt fall - sling.getService() är också enkelt.

Null-returvärde

adaptTo() returnerar null.

Det finns olika orsaker till detta, bland annat:

• implementeringen saknar stöd för måltypen
• en adapterfabrik som hanterar det här ärendet är inte aktivt (till exempel på grund av att det saknas tjänstreferenser)
• internt villkor misslyckades
• tjänsten är inte tillgänglig

Det är viktigt att du hanterar skiftläget null på ett smidigt sätt. Vid jsp-återgivning kan det vara acceptabelt att jsp misslyckas om det resulterar i en tom del av innehållet.

Cachning

För att förbättra prestanda kan implementeringar cachelagra objektet som returneras från en obj.adaptTo() ring. Om obj är samma, returnerade objekt är samma.

Denna cachelagring utförs för alla AdapterFactory baserade fall.

Det finns dock ingen allmän regel - objektet kan vara antingen en ny eller en befintlig instans. Det innebär att du inte kan förlita dig på något av beteendena. Därför är det viktigt, särskilt inom AdapterFactoryatt objekt kan återanvändas i det här scenariot.

Så här fungerar det

Det finns olika sätt att Adaptable.adaptTo() kan implementeras:

• Efter själva objektet, implementera själva metoden och mappa till vissa objekt.

• Av en AdapterFactory, som kan mappa godtyckliga objekt.

  Objekten måste fortfarande implementera Adaptable gränssnitt och måste utöka SlingAdaptable (som klarar adaptTo till en central adapterhanterare).

  Det gör att du kan lägga in kopplingar i adaptTo mekanism för befintliga klasser, som Resource.

• En kombination av båda.

I det första fallet kan Java™-dokumenten ange vad adaptTo-targets är möjliga. Detta är dock ofta inte möjligt för vissa underklasser, t.ex. JCR-baserade resurser. I det senare fallet ska AdapterFactory är vanligtvis en del av de privata klasserna i ett paket och därför inte exponeras i ett klient-API, och inte heller listas i Java™-dokument. Teoretiskt sett skulle det vara möjligt att få tillgång till alla AdapterFactory implementeringar från OSGi runtime-modulen för tjänster och se hur deras"adaptable"-konfigurationer (källor och mål) ser ut, men inte för att mappa dem till varandra. I slutändan beror detta på den interna logiken, som måste dokumenteras. Därför refererar vi till detta.

Referens

Sling

Resurs anpassar sig till:

ResursResolver anpassar sig till:

SlingHttpServletRequest anpassar sig till:

Inga mål ännu, men implementerar Adaptable och kan användas som källa i en anpassad AdapterFactory.

SlingHttpServletResponse anpassar sig till:

WCM

Sida anpassar sig till:

Komponent anpassar sig till:

Mall anpassar sig till:

Dokumentskydd

Auktoriserbar, Användare och ​ Grupp** anpassa till:

DAM

Tillgång anpassar sig till:

Taggar

Tagg anpassar sig till:

Övriga

Dessutom ger Sling/JCR/OCM [AdapterFactory](https://sling.apache.org/site/adapters.html#Adapters-AdapterFactory) för anpassad OCM (Mappning av objektinnehåll).