Bei der Template-Erstellung stößt man oft an Grenzen, die von xt:Commerce gewissermaßen vorgegeben werden - Zwar ist man bei der Gestaltung schon recht flexibel, aber bei etlichen Dingen scheint man auf den Code angewiesen zu sein, der aus den System-Dateien kommt.

Die Tabellen beim “Product-Navigator” sind z.B. nicht jedermanns Sache. Oder die Form, in der Preise ausgegeben werden - der durchgestrichene Preis, der eigentliche Preis, das “ab”, das Währungssymbol - Das alles kann im Template eigentlich nicht getrennt “angesprochen” werden …

Solange man das so haben möchte, ist das auch ganz praktisch.

Aber in einem aktuellen Projekt sollte die Ausgabe der Preise mit sIFR realisiert werden. Und dazu musste so Einiges umgestellt werden, um Anzeigeprobleme auf verschiedenen Browsern zu vermeiden …

Denn sIFR-Texte innerhalb von Links “mögen” sich bisweilen nicht anklicken lassen - wenn “vor ihnen” im Link “normale” Schrift auftaucht. Bei Preisen mit direkten Produkt-Links (wie z.B. in der “Specials-Box”) wäre das natürlich ärgerlich.

 

Die “üblichen” Methoden

Oben beschriebenes Szenario also nur als ein Beispiel für die verschiedenen denkbaren Fälle, in denen gravierendere Änderungen am HTML-Output der grundlegenden System-Funktionen nötig werden können.

Und dabei sollte man vermeiden, sein System für ein paar Layout-Besonderheiten auf den Kopf zu stellen, denn reines “Bugfixing” wäre das dann ja nicht mehr.

1. In System-Dateien (in meinem Fall die “xtcPrice.php”) wollte ich nicht schon wieder herumfummeln. Da funktioniert die endlich mal, wie sie soll - und bloß für ein paar spans mehr oder weniger … Nee, lieber nicht.
2. Smarty bietet unterschiedliche “Output-Filter”, mit denen man die Tags vor der Ausgabe beeinflussen kann. Einige von denen beherrschen auch reguläre Ausdrücke, aber das wäre in meinem Fall nicht ausreichend gewesen, weil zu viel umgestellt werden musste.
3. Dann kann man zwischen {php} und {/php} innerhalb seiner Template-Dateien PHP einsetzen, allerdings hätte man dann die “eigenen Änderungs-Funktionen” in jede Template-Datei packen müssen, in der ein Preis angezeigt wird. Nicht sonderlich praktisch.
4. Außerdem funktioniert bei “Smarty-PHP” nicht ganz alles so, wie man es bei normalen PHP-Dateien gewohnt ist. Ausgerechnet bei Regulären Ausdrücken wird’s schwierig, vermutlich gibt’s bei Smarty ein paar andere Regeln, wie bestimmte Zeichen “escaped” werden müssen u.ä.

Fehlersuche bei “Smarty-PHP” ist überhaupt ein bisschen unbequem, aber ziemlich interessant. Denn die PHP-Fehler werden nie in der Datei gefunden, die man gerade in Arbeit hat, sondern im Cache-Ordner “templates_c” … Aber dort sieht man dann quasi immer den “Schritt zwei”: Nämlich die “Übersetzung” nach PHP.

Der Witz an der Sache ist, dass man diese “Übersetzungen” meistens direkt in seinen HTML-Files verwenden kann - und das bringt auf Ideen.

 

Es geht auch entspannter

globale Funktionen

In jedem Template gibt es die Datei “xtc_show_category.inc.php” - Und was das Schöne daran ist: Alle Funktionen, die man dort abspeichert, kann man aus jeder Template-Datei heraus ansprechen. Also alles global verfügbar.

Das erspart einem schon mal, eine neue PHP-Datei anzulegen, die dann in jedem Template-File mit einer “include-” bzw. “require-”Anweisung eingebunden werden muss. Und trotzdem kann man von überall aus irgendwelche Daten an “seine” Funktionen schicken - und sich die (wie gewünscht veränderten) Werte wieder zurück geben lassen.

Inhalte abfangen und weitergeben …

Wenn man die Inhalte der Template-Tags nicht ausgeben, sondern weiterverwenden möchte, muss man die Ausgabe abfangen. Allerdings kommt man mit {capture} nicht weiter, die damit “gewonnenen” Variablen sind scheinbar nur zur Weiterverwendung mit Smarty gedacht.

Allerdings kann man auch mit PHP auf die Inhalte der Smarty-Tags zugreifen - und diese Ergebnisse können dann problemlos “weitervermittelt” werden:

Dazu benutzt man das Konstrukt $this->_tpl_vars['irgendwas']

Beispiel: “box_best_sellers.html”

Ausgangszustand - Die Replace-Anweisung bei den Verlinkungen ist übrigens nur dazu da, valide Links zu generieren. Der Rest dürfte ja bei den meisten mehr oder weniger ähnlich aussehen:

{config_load file="$language/lang_$language.conf" section="boxes"}

<div class="Box" id="BoxBestSellers">

<h4><span>{#heading_best_sellers#}</span></h4>

{foreach name=aussen item=box_data from=$box_content}
<p class="productName"><a href="{$box_data.LINK|replace:"&":"&amp;"}">{$box_data.NAME}</a></p>
{if $box_data.IMAGE}
<p class="productImage"><a href="{$box_data.LINK|replace:"&":"&amp;"}"><img src="{$box_data.IMAGE}" alt="{$box_data.NAME}" /></a></p>
{/if}
<p><a href="{$box_data.LINK|replace:"&":"&amp;"}"><strong class="productPrice">{$box_data.PRICE}</strong></a> <br />
<small>{if $box_data.TAX_INFO}{$box_data.TAX_INFO}{/if}{$box_data.SHIPPING_LINK|replace:"&":"&amp;"}</small></p>
{/foreach}

</div>

$this->_tpl_vars

Nun sollte aber ja mit dem Inhalt von {$box_data.PRICE} etwas bestimmtes passieren.

Was genau, ist eigentlich egal - Es geht hier nur darum, zu zeigen, wie man Boxen- oder Modul-Inhalte an eigene Sonderfunktionen weiter-übermitteln kann. Okay - unser Preis soll für eine korrekte Ausgabe mit sIFR umformatiert werden, nehmen wir einfach mal an, es gäbe dazu schon eine passende Funktion namens “sIFRprice();”.

Diese funktion “kennt” das System schon, weil wir sie ja (siehe oben) in mit in die “xtc_show_category.inc.php” geschrieben haben. Also kein require oder include, gleich drauflos …

{config_load file="$language/lang_$language.conf" section="boxes"}

<div class="Box" id="BoxBestSellers">

<h4><span>{#heading_best_sellers#}</span></h4>

{foreach name=aussen item=box_data from=$box_content}
<p class="productName"><a href="{$box_data.LINK|replace:"&":"&amp;"}">{$box_data.NAME}</a></p>
{if $box_data.IMAGE}
<p class="productImage"><a href="{$box_data.LINK|replace:"&":"&amp;"}"><img src="{$box_data.IMAGE}" alt="{$box_data.NAME}" /></a></p>
{/if}

<!-- Hier Aufruf und Werte-Übergabe an sIFRprice(); -->
{php} echo sIFRprice($this->_tpl_vars['box_data']['PRICE'],$this->_tpl_vars['box_data']['LINK']);{/php}
<!-- Wie üblich weiter -->

<p><small>{if $box_data.TAX_INFO}{$box_data.TAX_INFO}{/if}{$box_data.SHIPPING_LINK|replace:"&":"&amp;"}</small></p>
{/foreach}

</div>

In diesem Beispiel werden zwei Werte an die (weil nur Beispiel nicht näher erläuterte) Funktion “sIFRprice();” übergeben - Einmal der “nackte” Preis und zusätzlich der Link zum Produkt.

 

Allgemein:

Jedenfalls: Beide Werte sind mit PHP über $this->_tpl_vars['irgendwas'] erreichbar. Und was für die “Bestsellers” gilt, kann man auf alle Boxen bzw. Module übertragen.

Als “Keys” für unser “this”-Objekt brauchen wir lediglich die Benennungen der Template-Tags zu übernehmen. Und mit den Inhalten können wir dann anstellen, was immer wir wollen.

Tipp: Wenn man sich nicht ganz sicher ist, welche Möglichkeiten man in welcher Datei hat, kann man sich auch dadurch helfen, dass man zum Testen folgende Anweisung ausführt: {php}print_r($this);{/php} - Damit werden alle Template-Variablen aufgelistet, die in der jeweiligen Box bzw. im jeweiligen Modul “verfügbar” sind.

 

Zusammenfassung:

Für kleine Veränderungen an der HTML-Ausgabe reichen meistens die üblichen Smarty-Funktionen aus. Wenn’s aber umfangreicher wird, kann man nach folgendem Muster vorgehen:

1) Global verfügbare “Ersetzungs”-Funktion

Alles, was in der “xtc_show_category.inc.php” bereitgestellt wird, kann überall im Template benutzt werden.

function myLayout($Wert1,$Wert2){
	//irgendetwas machen
	return $Wert1.'etwas Besonderes'.$Wert2;
}

2) Inhalte übergeben

In den .html-Dateien im Template müssen die Inhalte nicht unbedingt angezeigt werden, die Daten stehen auch für PHP zur Verfügung:

Auf den Wert von {$box_data.BEISPIEL} kann man über {php}$this->_tpl_vars['box_data']['BEISPIEL']{/php} zugreifen.

Auf den Wert von {$EXEMPEL} entsprechend über {php}$this->_tpl_vars['EXEMPEL]{/php} etc. - und das alles kann beliebig weiterverwendet werden.

3) Einsatz in eigenen Funktionen

Die “eigenen Zusatz-Funktionen” können dann direkt in den .html-Dateien angesprochen werden.

In der Weise programmierte Templates dürften auch keine Probleme bei System-Updates machen. Denn alles, was für die Spezial-Funktionen nötig ist, geschieht ausschließlich innerhalb der Template-Files:

...
{php} echo myLayout($this->_tpl_vars['EXEMPEL], $this->_tpl_vars['EXEMPEL2]); {/php}
...
	

… und wenn man mag, kann man eventuelle “Sprach-Extras” ebenfalls zusammen mit allen anderen Besonderheiten des eigenen Templates abspeichern.

 

Noch ein Tipp

Wenn man Probleme hat, ein Template von einer älteren xtc-Version auf eine neuere anzupassen, leistet {php}print_r($this);{/php} ebenfalls gute Dienste … Eventuelle Änderungen an den “Smarty-Tags” sind auf diese Weise schnell ausfindig zu machen.