Home

sling-patterns a pattern library for Sling (AEM)

Goal

A strong, vivid and supportive community is key to every software framework and ecosystem. The sling-patterns shall bring the community forward in two central aspects. It shall provide a common language and best practices. Those two are tightly interwoven. To document best practices we need a common language and to build a common language we need examples. Patterns are a nice way to combine these two.

Therefore, we decided to build a pattern library comparable to the http://corej2eepatterns.com/ and the famous Design Patterns. We think a wide variety of stakeholders is key to the success of this pattern library, therefore we choose to kick it off at a community event. This will be the Connect Hackathon 2016 http://www.connectcon.ch/2016/en.html

The library is open-source and we encourage everybody to get involved.

#What is a pattern Patterns are a structured way to document solutions for recurring problems. The main benefit of patterns is that they help recognize known and solved problems and the matching solution. The names defined for each pattern simplify communication. Patterns are based on A pattern language C. Alexander et al. 1977 and won over the software industry with Design Patterns by the gang of four.

#Structure to document a pattern Each pattern will contain the following properties and chapters.

• Name
• Problem
• Solution
• Consequences
• Related Patterns

#Proposed patterns To get a rough idea where we would like to head to, we started by adding some pattern proposals, mainly names and a high level description. They are not yet fully documented by intention. We don't want to spoil the process of creating this library as a community.

We took one exception from this process and gave the pattern content suffix a first shot. It is fully documented to serve as an example, but it is not final. We may make any changes from changing the name up to kicking it out of the library completely. This has to be a community decision!

This library is not about inventing new stuff or rocket science, but rather about documenting widely used implementations and giving them a common name.

##Content Suffix TODO: complete documentation Use the path to determine the rendering context and the suffix for the content path. ##Static Page Type Use a specific page type as trigger for custom functionality, not using any CMS functionality within this page. ##View Only Trivial use cases should only contain a resourceType, dialog and view ##Decompose in JCR, recompose in view Data should be decomposed into their pieces using a suitable representation in the JCR. Re-composition shall take place in the view - e.g. via views, and not in a model.

#Implementation driven The following pattern names, directly match an existing interface/solution in Sling. Nevertheless it might make sense to document them in pattern language, to clarify when those solutions apply best. ##Rewriter https://sling.apache.org/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.html ##Filter https://sling.apache.org/documentation/the-sling-engine/filters.html ##Adaptable http://sling.apache.org/documentation/the-sling-engine/adapters.html