svn commit: r1631313 - /sling/site/trunk/content/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.mdtext

[ss...@apache.org]

Author: sseifert
Date: Mon Oct 13 08:24:55 2014
New Revision: 1631313

URL: http://svn.apache.org/r1631313
Log:
switch to explicit java code formatting

Modified:
    sling/site/trunk/content/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.mdtext

Modified: sling/site/trunk/content/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.mdtext?rev=1631313&r1=1631312&r2=1631313&view=diff
==============================================================================
--- sling/site/trunk/content/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.mdtext (original)
+++ sling/site/trunk/content/documentation/bundles/output-rewriting-pipelines-org-apache-sling-rewriter.mdtext Mon Oct 13 08:24:55 2014
@@ -5,6 +5,7 @@ The Apache Sling Rewriter is a module fo
 For supporting these use cases, the rewriter uses the concept for a processor. The processor is a component that is injected through a servlet filter into the response. By implementing the *Processor* interface one is able to rewrite the whole response in one go. A more convenient way of processing the output is by using a so called pipeline; the Apache Sling rewriter basically uses the same concept as the famous Apache Cocoon: an XML based pipeline for further post processing of the output. The pipeline is based on SAX events.
 
 ## SAX Pipelines
+
 The rewriter allows to configure a pipeline for post processing of the generated response. Depending on how the pipeline is assembled the rewriting process might buffer the whole output in order to do proper post processing - for example this is required if an HTML response is "transformed" to XHTML or if XSLT is used to process the response.
 
 As the pipeline is based on SAX events, there needs to be a component that generates these events and sends them through the pipeline. By default the Sling rendering scripts write to an output stream, so there is a need to parse this output and generate the SAX events.
@@ -42,12 +43,11 @@ As the html generated by Sling is not re
 
 Each pipeline component type has a corresponding Java interface (Generator, Transformer, and Serializer) together with a factory interface (GeneratorFactory, TransformerFactory, and SerializerFactory). When implementing such a component, both interfaces need to be implemented. The factory has only one method which creates a new instance of that type for the current request. The factory has to be registered as a service. For example if you're using the Maven SCR plugin, it looks like this:
 
-
+    ::java
     @scr.component metatype="no" 
     @scr.service interface="TransformerFactory"
     @scr.property value="pipeline.type" value="validator"
 
-
 The factory needs to implement the according interface and should be registered as a service for this factory interface (this is a plain service and not a factory service in the OSGi sense). Each factory gets a unique name through the *pipeline.type* property. The pipeline configuration in the repository just references this unique name (like validator).
 
 ## Extending the Pipeline
@@ -55,6 +55,7 @@ With the possibilities from above, it is
 
 The approach here is nearly the same. A transformer factory needs to be implemented, but instead of giving this factory a unique name, this factory is marked as a global factory:
 
+    ::java
     @scr.component metatype="no"
     @scr.service interface="TransformerFactory"
     @scr.property name="pipeline.mode" value="global"
@@ -66,17 +67,19 @@ The *TransformerFactory* interface has j
 
 
 ## Implementing a Processor
+
 A processor must conform to the Java interface *org.apache.sling.rewriter.Processor*. It gets initializd (method *init*) with the *ProcessingContext*. This context contains all necessary information for the current request (especially the output writer to write the rewritten content to).
 The *getWriter* method should return a writer where the output is written to. When the output is written or an error occured *finished* is called.
 
 Like the pipeline components a processor is generated by a factory which has to be registered as a service factory, like this:
 
+    ::java
     @scr.component metatype="no" 
     @scr.service interface="ProcessorFactory"
     @scr.property value="pipeline.type" value="uniqueName"
 
-
 ## Configuring a Processor
+
 The processors can be configured in the repository as a child node of */apps/APPNAME/config/rewriter* (or libs or any configured search path). Each node can have the following properties:
 
 * processorType - the type of the processor (required) - this is the part from the scr factory information after the slash (in the example above this is *uniqueName*)