[B]Warnung[/B]: Das folgende Posting ist lang, sehr technisch, und nix für schwache Nerven! 
HTML clipboardIch hatte ja in Post http://www.oxid-esales.com/forum/showthread.php?t=1578 schon meine Eindrücke von OXID aus Anwendersicht niedergeschrieben (nach einiger Beschäftigung damit), und auf auf http://oxid.powertemplate.de/ ein paar Dinge gezeigt, die ich mittlerweile da “templatemäßig” realisieren konnte.
Heute will ich mal (aus Entwicklersicht) beschreiben, wie ich das OXID-Templating so umgebaut habe, dass es m.E. wesentlich übersichtlicher und leichter handhabbar ist. Und mir meine Arbeit als Templateentwickler auf Dauer erleichtert.
Vielleicht sind die folgenden Erläuterungen ja auch hilfreich für andere, die sich, wie ich, von der xtc-Erfahrung her dem OXID-Templating nähern…
Vielleicht auch als Anregung an die OXID-Entwickler, da sich meine im folgenden beschriebenen Änderungen natürlich sehr viel eleganter im OXID-Core realisieren lassen…
Mein erster Eindruck vom OXID-Templating war: sehr unübersichtlich.
Was mir am OXID-Templating insbesondere nicht gefiel, war, dass die Templatestruktur zu sehr auf das jetzige OXID-Standard-Template ausgerichtet ist, und Änderungen am Code und der Plazierung der “Boxen” ziemlich unübersichtlich sind.
Es gibt in OXID 4 Template-Dateien ("_header.tpl", “_left.tpl”, “_right.tpl”, “_footer.tpl”), die das Layout der Seite definieren, und in denen [B]inline(!)[/B] (Iiiigiiiittttt!) der Smarty-Code (der auch noch wie PHP-Code aussieht!) der verschiedenen “Boxen” enthalten ist.
In diesen Vorlagen “sieht man den Wald vor lauter Bäumen nicht” (zumindest ich nicht), d.h., Änderungen in den Codes für die “Boxen” bzw. deren Umplazierung sind m.E. sehr unübersichtlich.
Andererseits fand ich die xtc-Template-Struktur schon immer sehr übersichtlich: es gibt eine “[B]index.html[/B]”, in der die [B]komplette[/B] Seitenstruktur [B] übersichtlich[/B] definierbar ist, und in der individuelle Boxen über ihre Smarty-Platzhalter sehr einfach eingebaut und verlagert werden können.
Und jede “Box” ist als eine separate Smarty-Template-Datei vorhanden, so dass man sehr genau weiß, wo man ggfs. etwas ändern kann.
Hinzu kommt, dass mir diese Struktur über die letzten ca. 6 Jahre einfach sehr vertraut geworden ist, und ich mir (mit Hilfe einer (per Subclassing) modifizierten Smarty-Version und ein paar PHP-Modulen) im Laufe der Zeit einige Automatismen geschaffen habe, die mir das Leben als Template-Entwickler [B]sehr[/B] vereinfachen.
Und so habe ich denn OXID auch eine solche Strukturierung und ein übersichtliches Zentral-Template (a.k,a “index.html” in xtc) “verpasst”, damit komme ich einfach sehr viel besser klar.
Nach Analyse der OXID “_header.tpl”-, “_left.tpl”-, “_right.tpl”-Vorlagen habe ich folgende “Boxen” in OXID identifiziert (die xtc Nomenklatur habe ich dabei weitestgehend beibehalten):
box_ACCESSORIES
box_ALSO_PURCHASED
box_BESTSELLERS
box_CART
box_CATEGORIES
box_CONTENT
box_CROSS_SELLING
box_CURRENCIES
box_INFORMATION
box_LANGUAGES
box_LOGIN
box_MANUFACTURERS
box_MINI_CART
box_NAVBAR
box_NEWS
box_NEWSLETTER
box_PARTNERS
box_SEARCH
box_SERVICE
box_SIMILIAR
box_SPECIALS
box_TELL_FRIEND
box_TOP_LINKS
box_TOP_NAVI
box_TOP_NAVI_LINKS
box_VENDORS
box_WHISHLIST_LINK
(Interessant, dass “cross-selling”, “also-purchased” und “accessories” bei OXID als Boxen behandelt werden. In xtc gehört das ja bekanntlich zum Content. Wohin ich das mittlerweile (alternativ) auch verlagert habe…)
Den relevanten “Smarty”-Code für diese “Boxen” aus den “_header.tpl”-, “_left.tpl”-, “_right.tpl”-Vorlagen habe ich dann in jeweils eine [B]separate[/B] Vorlagen-Datei für jede Box ausgelagert. (Richtig, der xtc-Kenner ahnt es schon: die liegen im Unterverzeichnis “[B]boxes[/B]” des Template-Verzeichnisses…)
Diese ausgelagerten (Boxen-)Code-Teile wurden dann aus den “_header.tpl”-, “_left.tpl”-, “_right.tpl”-Vorlagen entfernt. ("_left.tpl" und “_right.tpl” werden deswegen jetzt gar nicht mehr benötigt…)
So weit, so gut!
[B]
Aber wie kommen jetzt diese “Boxen” wieder in das Template hinein?[/B]
Man ahnt es schon (xtc lässt grüßen!): indem es ein PHP-Modul “[B]boxes.php[/B]” gibt, das die verwendeten Boxen mit Hilfe von Smarty rendert, und deren gerenderten HTML-Code der Box als Smarty-Variable dem Template zur Verfügung stellt!
Diese “[B]boxes.php[/B]” ist ziemlich simpel:
$oView=$this->_tpl_vars['oView'];
if (SHOW_NAVBAR)
{
$box_content=$this->fetch("boxes/box_navbar.tpl");
$this->assign("box_NAVBAR",$box_content);
}
if (SHOW_SEARCH && $oView->showSearch())
{
$box_content=$this->fetch("boxes/box_search.tpl");
$this->assign("box_SEARCH",$box_content);
}
if (SHOW_NEWSLETTER && $oView->showNewsletter())
{
$box_content=$this->fetch("boxes/box_newsletter.tpl");
$this->assign("box_NEWSLETTER",$box_content);
}
if ($oView->showTopBasket())
{
$box_content=$this->fetch("boxes/box_mini_cart.tpl");
$this->assign("box_MINI_CART",$box_content);
}
.... u.s.w. ....
(Die “SHOW_XXXXX”-Konstanten sind Teil des schon erwähnten Automatismus’, mit dem ich u.a. sehr einfach festlegen kann, welche Boxen wo verwendet werden sollen. Mehr dazu später.)
Damit habe ich jetzt das HTML jeder verwendeten Box als jeweils eigene Smarty-Variable im Template verfügbar.
Zusammengeführt wird das OXID Seiten-Layout, wie bei xtc & Co., dann über eine (vollständig definierte, abgeschlossene und übersichtliche!) “[B]_index.tpl[/B]”-Seite (analog zur “index.html” in xtc), und nicht aus mehreren losen Enden ("_header.tpl" & Co.)!
Meine "[B]_index.tpl[/B]" sieht wie folgt aus:
<html>
<head>
.... head-data .....
</head>
[{php}]
//Do the templating magic!
include(INC_PATH.'pt_setup.inc.php');
[{/php}]
<body>
<div id="page">
<div id="header">
[{$pt_header_image}]
[{$box_m_04}]
[{$box_m_05}]
[{$box_m_06}]
[{$box_m_07}]
[{$box_m_08}]
[{$box_m_09}]
[{$box_m_10}]
[{$box_m_11}]
[{$box_m_12}]
[{$box_m_13}]
[{$box_m_14}]
.......
[{$box_m_nn}]
<div class="clear"></div>
</div>
<div id="content">
<div id="left">
[{$box_l_01}]
[{$box_l_02}]
[{$box_l_03}]
[{$box_l_04}]
[{$box_l_05}]
[{$box_l_06}]
[{$box_l_07}]
[{$box_l_08}]
[{$box_l_09}]
[{$box_l_10}]
.......
[{$box_l_nn}]
</div>
<div id="right">
[{$box_r_01}]
[{$box_r_02}]
[{$box_r_03}]
[{$box_r_04}]
[{$box_r_05}]
[{$box_r_06}]
[{$box_r_07}]
[{$box_r_08}]
[{$box_r_09}]
[{$box_r_10}]
.......
[{$box_r_nn}]
</div>
<div id="body">
[{include file="inc/error.tpl" Errorlist=$Errors.default}]
[{oxid_include_dynamic file="dyn/newbasketitem_message.tpl"}]
[{$main_content}]
<div class="clear"></div>
</div>
<div id="footer" align="center">
[{$footer}]
</div>
</div>
<div id="mask"></div>
[{oxid_include_dynamic file="dyn/newbasketitem_popup.tpl"}]
[{if $popup}][{include file=$popup}][{/if}]
</body>
</html>
(Wer den Code der OXID "_header.tpl"-, "_left.tpl"-, "_right.tpl"-Vorlagen kennt, weiß diese Übersichtlichkeit sicher ebenso zu schätzen wie ich....)
HTML clipboardDas große Problem dabei war, dass OXID den Template-Code seriell (“wie er kommt”) rendert und ausgibt.
Und die einzelnen Elemente [B]nicht[/B] als Smarty-Variable bereit stellt, die dann in einer “[B]_index.tpl[/B]”, gemäß dem darin festgelegten Bauplan, “zusammengerendert” werden können.
Damit das alles dennoch so funktioniert, musste ich allerdings etwas von der reinen “Smarty”-Lehre abweichen…
Mit
[{php}]
include(INC_PATH.'pt_setup.inc.php');
[{/php}]
in der “[B]_index.tpl[/B]” rufe ich nämlich im Template den PHP-Code auf, den ich brauche, um die ganzen notwendigen Umsetzungen für mein neues OXID Template-Konzept vorzunehmen.
Aber die Vorteile, die mir diese Vorgehensweise bringt, sind m.E. so immens, dass ich diese kleine “Sünde” gerne in Kauf nehme…
[B]Wie wurde das realisiert?[/B]
Weiter geht es in: [B]Der Stand der Dinge… (Entwicklersicht, Teil 2)[/B]