» Template-Enginecrusy.net

Die Überschrift ist etwas irreführend. Es geht darum, dass referenzierte Templates nach dem Muster

bundle:section:template.format.engine

aufgebaut sein müssen. Der Teil “template” muss (?) dabei den relativen Pfad enthalten, zB

MyProjectBundle::pages/testpage.html.twig

, andernfalls kommt es zu der Fehlermeldung aus der Überschrift. Nun will man vielleicht nicht an drölf Stellen diesen Pfad (oder das Bundle!) angeben (sei es der Zentralisierung wegen, sei es aus Faulheit beim Tippen). Lösung: FilesystemLoader, bzw. das geerbte Twig_Loader_Filesystem->addPath(…):

class TestpageController extends Controller
{
  public function indexAction($name, Request $request)
  {
    // ...

    $loader = $this->container->get('twig')->getLoader();
    // add bundle and everything below:
    $loader->addPath('my/template/root');
    $loader->addPath('my/template/root/subfolder');

    // no more redundant stuff required:
    return $this->render('testpage.html.twig', $vars);
  }
}

class TestpageController extends Controller

{

public function indexAction($name, Request $request)

{

// ...

$loader = $this->container->get('twig')->getLoader();

// add bundle and everything below:

$loader->addPath('my/template/root');

$loader->addPath('my/template/root/subfolder');

// no more redundant stuff required:

return $this->render('testpage.html.twig', $vars);

}

bzw. im Template:

{% extends 'layout.html.twig' %}

{# instead of #}
{# extends 'MyProjectBundle::layout.html.twig' #}

{% extends 'layout.html.twig' %}

{# instead of #}

{# extends 'MyProjectBundle::layout.html.twig' #}

Wer Velocity auf ‘nem Tomcat laufen hat, stolpert vielleicht mal über das Problem, dass das Character Encoding falsch gesetzt ist. Sprich, dass Umlaute falsch gerendert werden.

Nun könnte man vermuten, dass das am String selbst liegt. Tut es nicht: In Java sind Strings UTF-16.

Dann könnte man den Fehler in Velocity suchen. Etwa könnte man die Templates explizit als UTF-8 öffnen:

Template template = Velocity.getTemplate( name, "UTF-8" );
// statt Template template = Velocity.getTemplate( name );

1 2	Template template = Velocity.getTemplate( name, "UTF-8" ); // statt Template template = Velocity.getTemplate( name );

Das hat bei mir nicht geholfen. Allerdings kann man Velocity das Default-, Input- und Output-Encoding vorgeben:

Velocity.setProperty( Velocity.ENCODING_DEFAULT, "UTF-8" );
Velocity.setProperty( Velocity.INPUT_ENCODING, "UTF-8" );
Velocity.setProperty( Velocity.OUTPUT_ENCODING, "UTF-8" );

Velocity.setProperty( Velocity.ENCODING_DEFAULT, "UTF-8" );

Velocity.setProperty( Velocity.INPUT_ENCODING, "UTF-8" );

Velocity.setProperty( Velocity.OUTPUT_ENCODING, "UTF-8" );

Das scheint schon mal was zu bewirken. Allerdings wird einem hier auffallen, dass die meisten (wenn nicht alle) Umlaute nicht im Template liegen, sondern dort nur reingeschrieben werden. In unserem Fall wurden zum Beispiel zum Teil Daten eines Webservice, zum Teil aber auch lokal gespeicherte XMLs verwendet. Die XMLs müssen UTF-8-kodiert gespeichert worden sein:

XmlOptions options = New XmlOptions();
options.setCharacterEncoding("UTF-8");

org.apache.xmlbeans.XmlTokenSource document;
String xml = document.xmlText(options);

org.apache.commons.io.FileUtils.writeStringToFile( myFile, xml, "UTF-8" );

XmlOptions options = New XmlOptions();

options.setCharacterEncoding("UTF-8");

org.apache.xmlbeans.XmlTokenSource document;

String xml = document.xmlText(options);

org.apache.commons.io.FileUtils.writeStringToFile( myFile, xml, "UTF-8" );

Und sie müssen vor allem auch UTF-8-kodiert gelesen werden:

XmlOptions options = New XmlOptions();
options.setCharacterEncoding("UTF-8");

org.apache.xmlbeans.XmlTokenSource document = org.apache.xmlbeans.XmlObject.Factory.parse(myFile, options);

XmlOptions options = New XmlOptions();

options.setCharacterEncoding("UTF-8");

org.apache.xmlbeans.XmlTokenSource document = org.apache.xmlbeans.XmlObject.Factory.parse(myFile, options);

Update

Kommen die XML-Daten (hier als ZIP) aus der Schnittstelle, müssen sie als UTF-8 in einen String konvertiert werden:

String unzipped = new String( myByteArrayOutputStream.toByteArray(), "UTF-8" );

1	String unzipped = new String( myByteArrayOutputStream.toByteArray(), "UTF-8" );

So. Last but not least müssen die Daten, die serverintern jetzt in UTF-8 vorliegen sollten, auch als solches an den Browser ausgegeben werden. Während normalerweise der Writer des Response ausreicht, um den OutputStream dieses Response zu handlen:

template.merge( myVelocityContext, myResponse.getWriter() );

1	template.merge( myVelocityContext, myResponse.getWriter() );

, muss man diesen für UTF-8 manchmal mit einem Writer mit explizit gesetztem UTF-8 ersetzen (Danke an Ralf!):

PrintWriter writer = new PrintWriter( new OutputStreamWriter( response.getOutputStream(), "UTF-8" ) );
template.merge( myVelocityContext, writer );

1 2	PrintWriter writer = new PrintWriter( new OutputStreamWriter( response.getOutputStream(), "UTF-8" ) ); template.merge( myVelocityContext, writer );

Achtung: Für JSON-Response musste ich dagegen das Encoding des Response selbst setzen:

ResourceResponse myRp;
myRp.setCharacterEncoding("UTF-8");

1 2	ResourceResponse myRp; myRp.setCharacterEncoding("UTF-8");

Vermutlich ist das ein wenig kompliziert gemacht (ich meine, hey, das muss einfacher gehen!), aber so scheint es hier zu funktionieren. HTH

Update

Für Spring gilt es außerdem, dieses Setting zu beachten:

spring.velocity.properties.input.encoding=UTF-8

1	spring.velocity.properties.input.encoding=UTF-8

crusy.net

♪ Commit ins Abenteuerland ♫

Tag Archives for Template-Engine

Symfony: “Unable to find template”

Velocity: Unterschied zwischen #parse und #include

Java/Velocity, XML/JSON: UTF-8 [UPDATE]

Update

Update