Rocker ist ein Java 8+ -Optimierter, nahe Null-Kopie-Rendering-Rendering, eine schnelle Template-Engine, die statisch typisierte, einfache Java-Objektvorlagen erzeugt, die zusammen mit dem Rest Ihres Projekts zusammengestellt werden. Keine "Aufwärmzeit" -Präuation mehr in der Produktion, die langsame Reflexionslogik oder schlechte Überraschungen, die während der Entwicklung hätte gefangen werden sollen.
Schreiben Sie Ihre Vorlagen mit einer intuitiven, taglosen Syntax mit Standard -Java -Ausdrücken für Logik, Iteration und Werte. Rocker's Special verwenden ?
Präsenzbetreiber für die Null-Safe-Bewertung. Das gesamte schwere Heben erfolgt der Rocker -Parser während der Entwicklung - was die Laufzeitabhängigkeiten auf nur eine Handvoll Klassen hinweg hält. Rocker analysiert Ihre Vorlagen und generiert gut dokumentierte Java-Quelldateien (so können Sie leicht inspizieren und verstehen, wie es funktioniert).
Enthält die folgenden Funktionen:
?
Der Präsenzoperator erweitert die Syntax für die vereinfachte Behandlung von Nullwerten.Projekt von Fizzed, Inc. (Folgen Sie auf Twitter: @Fizzed_inc)
Die Entwicklung und Aufrechterhaltung von OpenSource -Projekten erfordert erhebliche Zeit. Wenn Sie dieses Projekt nützlich finden oder kommerzielle Unterstützung benötigen, würden wir uns gerne unterhalten. Schreiben Sie uns eine E -Mail an [email protected]
Projektsponsoren können die folgenden Vorteile enthalten:
Basierend auf dem folgenden Vorlagen -Benchmark ist Rocker der klare Gewinner. ~ 250% schneller als Freemarker, während er gleichzeitig einen geringeren Gedächtnis erfordert.
Die meisten Vorlagen werden für Websites verwendet. Hier finden Sie ein kurzes Beispiel, das zeigt, wie Rocker -Vorlagen funktionieren und sich während des Rendering -Prozesses gegenseitig aufrufen können. Erstellen Sie eine Vorlage mit einem gemeinsamen Header und Fußzeile sowie einen Platzhalter für Körperinhalte. Erstellen Sie Vorlage src/main/java/views/main.rocker.html
@args (String title, RockerBody content)
< html >
< head >
< title > @title </ title >
</ head >
< body >
@content
</ body >
</ html >
Die Vorlage, die wir einem Benutzer tatsächlich vorstellen möchten, rendert seinen Inhalt im Kontext der Common/Header -Fußzeile. In Java -Begriffen gibt es einen Block des Renderns Code, der in einer anderen Vorlage ausgeführt werden soll. Erstellen Sie Vorlage src/main/java/views/index.rocker.html
@args (String message)
@views.main.template("Home") - > {
< h1 > Hello @message! </ h1 >
}
Hey, was ist mit dem Argument RockerBody content
? Wir behandeln es in der Syntax Readme ausführlicher, verstehen aber im Moment nur, dass es die einzige besondere Art von Argumentation ist und die Rocker anweist, dass eine Vorlage erwartet, dass ein "Körper" an ihn übergeben wird.
Der Rocker -Parser generiert für jede Vorlage eine Java -Quelldatei. Sie werden target/generated-sources/rocker/views/main.java
und target/generated-sources/rocker/views/index.java
sein. In Ihrer Anwendung können Sie die Indexvorlage so rendern.
static public void main ( String [] args ) {
String output = views . index . template ( "World" )
. render ()
. toString ();
}
Die Ausgabe ist gleich:
< html >
< head >
< title > Home </ title >
</ head >
< body >
< h1 > Hello World! </ h1 >
</ body >
</ html >
Sobald Sie die Java -Quellen generiert und in den Code schauen, ist es einfach zu sehen, wie dies funktioniert. Die Ansichten.Index -Klasse erstellt eine @content
. Die Syntax ist identisch mit der Definition einer Lambda in Java 8 (implementiert mit Lambdas für Java 8 und anonyme innere Klassen für Java 6/7). Rocker macht eine Reihe von Dingen hinter den Kulissen, um sicherzustellen, dass Vorlagen, die andere Vorlagen erstellen, denselben Rendering-Kontext (Ausgabepuffer, anwendungsspezifischer Kontext/implizite Zustand).
Schauen Sie sich die syntax.md -Datei für einen umfassenden Tauchgang auf der Rocker -Syntax an.
Rocker hat eine wachsende Liste von Frameworks, in die sie nahtlos integriert wurde. Wenn Sie zu einem neuen Rahmen verlinken möchten, stellen Sie bitte ein Problem ein oder senden Sie eine PR:
Statisch (einfacher Text) für jede Rocker-Vorlage wird (standardmäßig) intern als statische Byte-Arrays gespeichert, die bereits in Ihr Ziel-Charset (z. B. UTF-8) umgewandelt wurden. Wenn eine Vorlage gerendert wird, werden die statischen Byte -Arrays über alle Anfragen hinweg wiederverwendet. Die Rocker rendert einen optimierten Ausgangsstrom, der eine zusammengesetzte (verknüpfte Liste) der wiederverwandeten Byte -Arrays sowie Ihren dynamischen Inhalt speichert. Da Vorlagen hauptsächlich aus statischen Inhalten bestehen wieder. Diese Technik erzeugt schnelle und speichereffiziente Renderung.
Nehmen wir an, Sie haben eine Vorlage, die aus 9000 Bytes einfacher statischer Text und 1000 Bytes dynamischer Inhalte besteht. Ohne diese Optimierung würde es ~ 100 MB Speicher benötigen, um 10000 Anforderungen (10000 Bytes x 10000 Anfragen) zu bedienen. Mit dieser Optimierung müsste es ~ 10 MB Speicher benötigt, um 10000 Anforderungen (1000 Bytes x 10000 Anfragen) zu bedienen. Neben dem unteren Speicher haben Sie auch 90 MB Speicherkopien und 90 MB UTF-8-String-> -Byte-Conversions ausgeschnitten. Eine ziemlich nützliche Optimierung.
Alles wird vom Compiler Ihres Projekts zusammen mit Ihrem anderen Java -Quellcode zusammengestellt. Jeder dynamische Code in Ihrer Vorlage wird letztendlich in Standard -Java konvertiert und zusammengestellt. Keine Reflexion verwendet.
Version 0.10.0 führte die Unterstützung für heiße Nachladensvorlagen während der Entwicklung ein. Mit dem Hot Reloading können Sie den Quellcode des Vorlagenquellens ändern, ihn speichern und die Änderungen auf der nächsten Anfrage aktiv haben - ohne Ihren JVM neu zu starten. Rocker bietet zwei verschiedene Geschmacksrichtungen des heißen Nachladens für Flexibilität.
Das Hauptmerkmal von Rocker-Vorlagen besteht darin, dass Ihre Vorlagen vom Java-Compiler auf Nutzung, Argumente, Logik usw. überprüft werden.
In Version 0.10.0 wurde die zugrunde liegende Struktur einer Vorlage geändert, wobei eine Vorlage zwei zugrunde liegende Klassen generiert. Jede Vorlage generiert eine Modellklasse (ihre Schnittstelle) und eine Implementierungsklasse (ihr Renderer). Ihre Anwendung wird nur direkt mit dem Modell interagieren, sodass die Rocker die Implementierungsklasse dynamisch neu kompilieren und neu laden kann.
Der Hauptvorteil von Aroma One besteht darin, dass Ihr Anwendungscode gleich bleibt und vom Java-Compiler kompiliert wird, während der Vorlageninhalt zur Laufzeit automatisch neu geladen werden kann. Nur wenn Sie die Vorlagenargumente tatsächlich ändern, müssen Sie Ihre Anwendung neu starten.
Wenn Sie die Bequemlichkeit vollständig dynamischer Vorlagen bevorzugen, wird Two -unterstützt das heiße Nachladen sowohl der Vorlagenmodellklasse (ihrer Schnittstelle) als auch der Implementierungsklasse (dessen Renderer). Ihre Bewerbung verliert einen Teil der Kompilierungs-Zeit-Überprüfung und einen kleinen Leistungsverlust. Die Art und Weise, wie Ihre Anwendung Vorlagen verwendet, ist ebenfalls unterschiedlich.
import com . fizzed . rocker . Rocker
...
// dynamic interfaces, dynamic implementation
String rendered = Rocker . template ( "views/index.rocker.html" )
. bind ( "val" , "ValueA" )
. render ()
. toString ();
Der Vorlagenpfad und die Argumente werden von der Laufzeit überprüft. Bitte beachten Sie, dass jeder bindbare Wert mit dem Namen übereinstimmen und in Ihrer Vorlage deklariert wird.
Falls Ihre bindbare Karte mehr Werte enthält, die als die erforderlichen eine entspannte Bindung verfügbar sind. Die entspannte Alternative fehlschlägt nicht das Rendering, wenn ein Attribut für die erforderliche Liste zusätzlich ist. Zum Beispiel:
@args (String name)
Hello ${name}!
Wird im entspannten Modus als:
Map map = new HashMap ();
map . put ( "name" , "Joe" );
map . put ( "age" , 42 );
Rocker . template ( "views/hello.rocker.html" )
. relaxedBind ( map )
. render ();
// -> Hello Joe!
Die Unterstützung für das heiße Nachladen wird standardmäßig in Version 0.10.0 zu Ihren generierten Vorlagen hinzugefügt. Wenn Sie die Unterstützung deaktivieren möchten, setzen Sie den Konfiguration/System rocker.optimize
während Ihres Builds auf true. Da der Code standardmäßig in Ihren Vorlagen vorhanden ist, müssen Sie ihn lediglich zur Laufzeit einschalten.
Die Abhängigkeit rocker-compiler
muss zu Ihrem Build hinzugefügt werden. Diese Abhängigkeit muss nur während der Entwicklung vorhanden sein und kann in der Produktion entfernt werden. In Maven bedeutet dies, dass Sie die Abhängigkeit in den provided
Bereich hinzufügen möchten.
< dependency >
< groupId >com.fizzed</ groupId >
< artifactId >rocker-compiler</ artifactId >
< version >2.1.0</ version >
< scope >provided</ scope >
</ dependency >
Aktivieren Sie das heiße Nachladen zur Laufzeit. Sie können heißes Nachladen entweder mit einer Systemeigenschaft oder programmatisch aktivieren. Zum Aktivieren des heißen Nachladens mit einer Systemeigenschaft in Maven.
mvn -Drocker.reloading=true ...rest of args...
Alternativ können Sie heißes Nachladen programmatisch aktivieren.
import com . fizzed . rocker . runtime . RockerRuntime
...
RockerRuntime . getInstance (). setReloading ( true );
Es gibt ein einfaches Beispiel, das heißes Nachladen in Aktion zeigt. Dieses Projekt verwendet Blaze, um Skriptaufgaben zu helfen. Leiten Sie Folgendes aus
java -jar blaze.jar hot_reload
Zeigen Sie Ihren Browser auf http: // localhost: 8080
Dann ändern und speichern und rocker-test-reload/src/test/java/views/index.rocker.html
speichern und Ihren Browser aktualisieren.
Rocker besteht aus zwei Komponenten - dem Parser/Generator und der Laufzeit. Um Rocker in Ihrem Projekt zu verwenden, fügen Sie die Laufzeitabhängigkeit Ihrer Anwendung hinzu und aktivieren Sie den Parser in Ihrem Build -Tool, gefolgt vom Erstellen Ihrer ersten Vorlage.
Rocker wird in Maven Central veröffentlicht. Als Abhängigkeit in Maven hinzufügen:
< dependency >
< groupId >com.fizzed</ groupId >
< artifactId >rocker-runtime</ artifactId >
< version >2.1.0</ version >
</ dependency >
<!-- for hot-reloading support only during development -->
< dependency >
< groupId >com.fizzed</ groupId >
< artifactId >rocker-compiler</ artifactId >
< version >2.1.0</ version >
< scope >provided</ scope >
</ dependency >
Als Abhängigkeit im Gradle hinzuzufügen:
repositories {
mavenCentral()
}
dependencies {
compile group : ' com.fizzed ' , name : ' rocker-runtime ' , version : ' 2.1.0 '
// add rocker-compiler dependency as needed
}
Rocker unterstützt Maven und Gradle Out-of the Box.
Fügen Sie Ihrem Pom Folgendes hinzu
< build >
< plugins >
< plugin >
< groupId >com.fizzed</ groupId >
< artifactId >rocker-maven-plugin</ artifactId >
< version >2.1.0</ version >
< executions >
< execution >
< id >generate-rocker-templates</ id >
< phase >generate-sources</ phase >
< goals >
< goal >generate</ goal >
</ goals >
</ execution >
</ executions >
</ plugin >
</ plugins >
</ build >
Standardmäßig verarbeitet Rocker rekursiv alle Vorlagendateien, die mit .rocker.html
in src/main/java
enden. Das Verzeichnis, das die Vorlage gespeichert ist, wird zum Standard -Java -Paket, in das die generierten Java -Klassen platziert werden. Die generierten Java-Quelldateien werden in target/generated-sources/rocker
gespeichert. Das Plugin kümmert sich um das Hinzufügen dieses generierten Verzeichnisses zu Ihrem Quellenroot.
Die folgenden Eigenschaften werden unterstützt:
templateDirectory
ist das Basisverzeichnis, das bei der Suche und Parsen von Vorlagendateien rekursiv beginnt. Das Java package
das eine Vorlage generiert wird, wird dieses Verzeichnis als Basis verwenden. Wenn Sie also ${templateDirectory}/views/mytemplate.rocker.html
haben, generiert Rocker ${outputDirectory}/views/mytemplate.java
. Standardmäßig ${project.build.sourceDirectory}
.
outputDirectory
ist das Verzeichnis, den der Parser für Vorlagen Quellen erzeugt. Standardmäßig ${project.build.directory}/generated-sources/rocker
classDirectory
ist das Verzeichnis, das die Hot Reload -Funktion (neu) Klassen zur Laufzeit kompilieren wird. Standardmäßig ${project.build.outputDirectory}
failOnError
bestimmt, ob Parsing-/Erzeugenfehler dazu führen, dass Maven fehlschlägt. Standardmäßig true.
skip
bestimmt, ob die Ausführung des Plugins übersprungen werden sollte. Standardmäßig falsch.
touchFile
ist die Datei zum "Berühren", nachdem Java -Quellen erfolgreich generiert wurden. Nützlich, um einen anderen Workflow auszulösen. Viele IDEs werden generierte Quellen nicht automatisch für den Abschluss der Code neu laden, es sei denn, entweder wird entweder explizit nachgeladen oder wenn die Datei maven pom.xml geändert wird. Somit wird dieser Wert standardmäßig auf ${basedir}/pom.xml
festgelegt. Es ist normalerweise harmlos, dies aktiviert zu halten.
skipTouch
deaktiviert Touchfile. Standardmäßig falsch.
addAsSources
fügt Maven die zu kompilierte Quellen zu Maven hinzu. Standardmäßig true.
addAsTestSources
fügt Maven das Ausgabe -Verzeichnis als zu kompilierte Testquellen hinzu. Standardmäßig falsch. Wenn dies zutrifft, wird dies vor Addassources bewertet und fordert Maven effektiv an, Ihre Vorlagen als Testcode zu kompilieren.
Die folgenden Eigenschaften werden ebenfalls unterstützt, aber es ist wichtig zu verstehen, dass es sich im Wesentlichen um die Übersteuerung des Parsers handelt, und alle standardmäßig zum Standardwert der Rocker.
javaVersion
ist die Java -Version, mit der Ihre Vorlagen kompilieren und Laufzeit kompatibel sind. Standardeinstellung zur Java -Version des JVM -Ausführungsmaschinens Maven (z. B. "1.8").
optimize
fest, ob die heiße Wiederholungsunterstützung aus den generierten Vorlagen entfernt wird. Standardmäßig falsch.
extendsClass
ist die Klasse, die sich alle Vorlagenimplementierungen verlängern sollten. Nützlich für anwendungsspezifische Zwischenklassen, die alle Vorlagen erweitern möchten. Standardeinstellungen zu Rocker's Standard.
extendsModelClass
ist die Klasse, die sich alle Vorlagenmodelle erweitern sollten. Nützlich für anwendungsspezifische Zwischenklassen, die alle Vorlagenmodelle erweitern möchten. Standardeinstellungen zu Rocker's Standard.
plainTextStrategy
ist die Strategie, die zum Einbetten von Klartext als Teil von Vorlagen verwendet wird. Standard ist static_byte_arrays_via_unloadd_class, aber wenn Sie die Kompatabilität von Graalvm benötigen, würden Sie es versuchen, static_byte_arrays zu versuchen
discardLogicWhitespace
bestimmt, ob die Whitespace in Vorlagen als nur Teil der Logik-/Kontrollblöcke festgelegt wird. Hilft, dass gerenderte Inhalte professioneller aussehen und gleichzeitig einen Großteil Ihrer Formatierung intakt halten. Standardeinstellungen zu Rocker's Standard.
targetCharset
ist das Zielzeichen für die Vorlagenausgabe. Standardeinstellungen zu Rocker's Standard.
suffixRegex
ist der reguläre Ausdruck, mit dem Vorlagen zum Analysen finden können. Standardeinstellungen zu Rocker's Standard.
markAsGenerated
fügt den generierten Klassen eine @Generated Annotation hinzu. Die Aufbewahrung ist eine Klasse, damit die Annotation von Tools verwendet werden kann, die nur auf den Klassendateien und nicht auf dem Quellcode beruhen. Standardeinstellungen zu Rocker's Standard.
Vielen Dank an @victory
und @mnlipp
für den Beitrag zum Gradle -Plugin. @etiennestuder
hatte auch ein alternatives Gradle -Plugin, das Sie auch berücksichtigen möchten. Rocker's Gradle Plugin wird auf Gradle.org veröffentlicht. Fügen Sie einfach Folgendes zu Ihrem Build -Skript hinzu:
plugins {
id " com.fizzed.rocker " version " 2.1.0 "
}
sourceSets {
main {
rocker {
srcDir( ' src/main/java ' )
}
}
}
rocker {
// (All settings are shown with their defaults)
//
// Skips building templates all together
skip false
// Base directory for generated java sources, actual target is sub directory
// with the name of the source set. The value is passed through project.file().
outputBaseDirectory = " $b uildDir /generated-src/rocker "
// Base directory for the directory where the hot reload feature
// will (re)compile classes to at runtime (and where `rocker-compiler.conf`
// is generated, which is used by RockerRuntime.getInstance().setReloading(true)).
// The actual target is a sub directory with the name of the source set.
// The value is passed through project.file().
classBaseDirectory = " $b uildDir /classes "
failOnError true
skipTouch true
// must not be empty when skipTouch is equal to false
touchFile " "
javaVersion ' 1.8 '
extendsClass null
extendsModelClass null
optimize null
discardLogicWhitespace null
targetCharset null
suffixRegex null
postProcessing null
markAsGenerated null
}
Die Template -Syntax wird unten ausführlich beschrieben, erstellt jedoch im Moment eine neue Datei in ${templateDirectory}/views/HelloWorld.rocker.html
@*
Example of hello world
*@
@args (String message)
Hello @message!
Zeit, Ihr Projekt zu kompilieren und die Vorlage zu verwenden. Sie können es von Java wie so anrufen:
static public void main ( String [] args ) {
String output = views . HelloWorld
. template ( "World" )
. render ()
. toString ();
}
Rocker ist (standardmäßig) stark optimiert, um Vorlagen als Byte -Arrays auszugeben. Der Standard RockerOutput
Eine Vorlage wird von der Art com.fizzed.rocker.runtime.ArrayOfByteArraysOutput
erfolgen. Dies ist eine ausgezeichnete Wahl für Byte -Arrays oder asynchrones IO. Das Framework bietet jedoch die Fähigkeit zum optimierten Rendering für Zeichenfolgen (oder andere benutzerdefinierte Ausgänge).
Effizient zu einer Zeichenfolge rendern:
import com . fizzed . rocker . runtime . StringBuilderOutput ;
static public void main ( String [] args ) {
StringBuilderOutput output = views . HelloWorld
. template ( "World" )
. render ( StringBuilderOutput . FACTORY );
String text = output . toString ();
}
Effizient zu einem Ausgangsstream rendern:
import com . fizzed . rocker . runtime . OutputStreamOutput ;
static public void main ( String [] args ) throws Exception {
final OutputStream os = new FileOutputStream ( new File ( "test" ));
OutputStreamOutput output = views . HelloWorld
. template ( "World" )
. render (( contentType , charsetName ) -> new OutputStreamOutput ( contentType , os , charsetName ));
}
Bitte beachten Sie, dass der OutputStream, wenn es während des Renders eine Ausnahme gibt, eine teilweise Vorlage (bis zur Ausnahme) gerendert wird. In den meisten Fällen wäre es besser, den Standard com.fizzed.rocker.runtime.ArrayOfByteArraysOutput
zu rendern und seinen Puffer von Byte -Arrays direkt in Ihren Ausgangsstream zu schreiben.
Es gibt zahlreiche Demos von Rocker in Aktion. Vom Analyse von Vorlagen in ein Modell bis hin zum asynchronen Senden von Ergebnissen in einem HTTP -Server. Dieses Projekt verwendet Blaze, um Skriptaufgaben zu helfen. Führen Sie Folgendes für eine vollständige Liste aus:
java -jar blaze.jar -l
Copyright (C) 2015+ Fizzed, Inc.
Diese Arbeit ist unter der Apache -Lizenz, Version 2.0, lizenziert. Weitere Informationen finden Sie in Lizenz.