How Pages are Rendered for Client

chlimage_1-25

Component Customization and Extension

To customize or extend the components, you write only the overlays and extensions to your /apps directory which simplifies the process of upgrading to future releases.

Server-Side Framework

The framework provides APIs to access functionality on the server and support interaction between the client and server.

Java APIs

The Java APIs provide abstract classes and interfaces which are easily inherited or subclassed.

The main classes are described on the Server-side Customization page.

Visit Storage Resource Provider Overview to learn about working with UGC.

HTTP API

The HTTP API supports ease of customization and choice of client platforms for PhoneGap apps, native apps, and other integrations and mashups. Further, the HTTP API allows a community site to run as a service without a client, such that framework components can be integrated into any webpage built on any technology.

HTTP API - GET Requests

For every SocialComponent, the framework provides an HTTP-based API endpoint. The endpoint is accessed by sending a GET request to the resource with a ‘.social.json’ selector + extension. Using Sling, the request is handed to the DefaultSocialGetServlet.

The DefaultSocialGetServlet

  1. Passes the resource (resourceType) to the SocialComponentFactoryManagerand receives a SocialComponentFactory capable of selecting a SocialComponentrepresenting the resousrce.

  2. Invokes the factory and receives a SocialComponentcapable of handling the resource and request.

  3. Invokes the SocialComponent, which process the request and returns a JSON representation of the results.

  4. Returns the JSON response to the client.

GET Request

A default GET servlet listens to .social.json requests to which the SocialComponent responds with customizable JSON.

chlimage_1-26

HTTP API - POST Requests

In addition to the GET (Read) operations, the framework defines an endpoint pattern to enable other operations on a component, including Create, Update and Delete. These endpoints are HTTP APIs that accept input and respond with either an HTTP status codes or with a JSON response object.

This framework endpoint pattern makes CUD operations extensible, reusable and testable.

POST Request

There is a Sling POST:operation for every SocialComponent operation. The business logic and maintenance code for each operation are wrapped in an OperationService which is accessible through the HTTP API or from elsewhere as an OSGi service. Hooks are provided supporting pluggable operation extensions for before/after actions.

chlimage_1-27

Storage Resource Provider (SRP)

To learn about handling UGC stored in the community content store, see

Server-side Customizations

Visit Server-Side Customizations for information on customizing the business logic and behavior of a Communities component on the server-side.

Handlebars JS Templating Language

One of the more noticeable changes in the new framework is the use of the Handlebars JS templating language (HBS), a popular open-source technology for server-client rendering.

HBS scripts are simple, logic-less, compile on both server and client, are easy to overlay and customize, and naturally bind with the client UX because HBS supports client side rendering.

The framework provides several Handlebars helpers that are useful when developing SocialComponents.

On the server, when Sling resolves a GET request, it identifies the script that will be used to respond to the request. If the script is an HBS template (.hbs), Sling will delegate the request to the Handlebars Engine. The Handlebars Engine will then get the SocialComponent from the appropriate SocialComponentFactory, build a context, and render the HTML.