Der Stand der Dinge..... (Entwicklersicht, Teil 2)

[B]Warnung[/B]: Das folgende Posting ist auch lang, sehr technisch, und nix für schwache Nerven! :smiley:

 OXID geht standardmäßig so vor:

Jede "Content"-Vorlage (verwendet von den "view"-Klassen) inkludiert als      erstes die "[B]_header.tpl[/B]"-Vorlage und gibt das Ergebnis des Renderns      dieser Vorlage direkt aus.

Dann wird die jeweilige "Content"-Vorlage selbst gerendert, und der Code      ausgegeben.

Abschließend inkludiert die "Content"-Vorlage die "[B]_footer.tpl[/B]"-Vorlage      und gibt deren Code aus.

Die Aufgabe bestand also darin, zu erreichen, dass das HTML der jeweiligen      gerenderten "Content"-Vorlage nicht direkt ausgegeben wird, sondern in einer      Smarty-Variable ("[B]$main_content[/B]") bereit gestellt wird. 
 (Und das, ohne die bestehenden Template-Dateien ändern zu müssen...)

Dies wurde durch Änderungen der "[B]_header.tpl[/B]"- und "[B]_footer.tpl[/B]"-Vorlagen      realisiert.

Die "[B]_header.tpl[/B]" startet jetzt kein Rendern und keine Ausgabe mehr,      sondern schaltet PHP nur in den [B]"Output-Buffering"-Modus[/B] um, damit      der folgende Inhalt der "Content"-Vorlagen nicht direkt ausgegeben, sondern      in einen Buffer geschrieben wird.

Sie besteht nur noch aus folgendem Code:
[{php}]
ob_start();
[{/php}]
In der "[B]_footer.tpl[/B]"-Vorlage muss nun (konsequenter Weise) der      Inhalt dieses Output-Buffers ausgelesen, und in der Smarty-Variablen "[B]$main_content[/B]"      gespeichert werden.

Und es muss natürlich dann das Rendern meiner neuen "[B]_index.tpl[/B]"-Vorlage      gestartet werden, um die komplette Seite endgültig aufzubauen.

Der Code der neuen "[B]_footer.tpl[/B]"-Vorlage ist wieder trivial;
[{php}]
$main_content=ob_get_clean();
$this->assign('main_content',$main_content);
[{/php}]
[{include file="_index.tpl"}]

(Der eigentliche “[B]_footer.tpl[/B]”-Vorlagen-Code wird jetzt an anderer Stelle (“boxes.php”) gerendert und in der Smarty-Variablen [B]$footer[/B] bereit gestellt.)

[B]Und, voilà, meine OXID-Seite ist komplett....[/B]

 Nun fühle ich mich mit dem OXID-Templating wieder "pudelwohl", und habe      mir damit einige Vorteile verschafft:

[ul]
[li] Es gibt [B]eine [/B]Stelle, an der das Seitenlayout komplett definiert, überschaubar und verständlich ist ("[B]_index.tpl[/B]").[/li][li] Die sehr einfache Möglichkeit, “[B]Boxen[/B]” innerhalb des Designs zu verlagern,[/li][li] Für Änderungen leicht identifizierbarer Boxen-Code (pro Box eine Vorlage)[/li][li] Mein in mehreren Jahren entwickeltes Templating-Konzept und Know-How aus dem xtc/Gambio-Bereich kann ich damit weitestgehend auf OXID übertragen, was die gedankliche und handwerkliche Umstellung sehr viel einfacher macht.[/li][/ul]
Zugegeben, ich musste dafür an ein paar Stellen die reine “Smarty”-Lehre über Bord werfen, und ein wenig PHP zu Hilfe nehmen.

Aber das sehe ich sehr pragmatisch: wenn das mir hilft, Dinge für mich      wesentlich zu vereinfachen, dann tue ich das (und pfeife auf die "[B]reine      Lehre[/B]")! 

[B]Noch ein paar Besonderheiten:[/B]

Wie man in der “[B]_index.tpl[/B]” sieht, werden hier nicht direkt die zuvor erwähnten Boxen-Namen verwendet (z.B. “[B]box_LOGIN[/B]”), sondern Namen wie “[B]box_l_01[/B]” usw…

Dies ist ein weiterer Teil der schon erwähnten Automatismen, die mir mein Template-Entwickler-Leben erleichtern: die [B]externe [/B]Definition (in einer Datei) welche Boxen verwendet, und wo die plaziert werden sollen!

“box_[B]m[/B]xxxx"-Boxen werden dabei im Header-Bereich, die "box[B]l[/B]xxxx"- und "box[B]r[/B]_xxxx”-Boxen im linken bzw. rechten Navibereich plaziert.

Mit einfachen Anweisungen wie z.B. “[B]box_bestsellers=r,5[/B]” wird damit die “[B]Bestsellers[/B]”-Box aktiviert, und als 5. Box im rechten Navi-Bereich plaziert.
(Man muss damit also gar nicht mehr irgendwelchen Code umkopieren, um eine Box hinzuzufügen/zu entfernen/zu verlagern, das regelt sich alles automatisch…)

Gleichzeitig werden daraus auch die “SHOW_XXXXX”-Konstanten definiert, so dass man damit in der “boxes.php” prüfen kann, ob eine Box verwendet werden soll oder nicht.

Diese Konfigurationsdatei für das Template auf http://oxid.powertemplate.de/ sieht beispielsweise wie folgt aus:


#
# box-name=navi-area (l,m,r),box-position in navi-area
#
box_accessories=
box_also_purchased=
box_bestsellers=l,4
box_cart=
box_categories=l,1
box_content=l,2
box_cross_selling=
box_currencies=
box_languages=
box_login=m,8
box_longruns=l,6
box_manufacturers=
box_mini_cart=m,7
box_news=
box_navbar=m,4
box_newsletter=m,6
box_partners=
box_search=m,5
box_service=l,3
box_similiar=
box_specials=
box_tell_friend=
box_top_links=
box_top_navi=
box_top_navi_links=m,14
box_vendors=
box_whatsnew=l,5
box_wishlist_link=m,11

Ein (teilweise schon ereichtes) Ziel ist es auch noch, die OXID-Konfigurations-Parameter daraus gleich so zu setzen, dass [B]nicht [/B] verwendete Boxen gar [B]nicht [/B]erst erstellt werden.
(Bisher kann man das im Admin-Bereich steuern, aber da ich keine Lust habe, das bei jeder Kunden-Installation mühsam wieder händisch konfigurieren zu müssen, mache ich das lieber programmatisch.)

Mit Hilfe meiner (per Subclassing) erweiterten Smarty-Version erhalten die “Boxen” auch gleich die richtigen CSS-Klassen und IDs zugewiesen.

So ist jede Box eingeschlossen in einen DIV wie “[B]<div class=“left_box box_CATEGORIES” id=“box_CATEGORIES”>[/B]”, so dass die Boxen [B]automatisch[/B] die CSS-Eigenschaften der linken, rechten und Header-Boxen erben, aber auch die Möglichkeit eines individuellen CSS-Stylings geben.

Ich kann damit sehr einfach das Layout der linken und rechten Boxen und Navi-Spalten (unterschiedlich) gestalten, [B]ohne[/B] jede Box einzeln anpassen zu müssen, egal, wohin ich sie plaziere!.

Weiterhin habe ich OXID für einen [B] dynamischen Template-Wechsel [/B]vorbereitet!

Es gibt viele Gründe, wofür so was nützlich ist:

[ul]
[li] URL-abhängiges Template-Design.[/li][li] Kategorie-abhängiges Template-Design.[/li][li] Sprach-abhängiges Template-Design.[/li][li] Tages-/Jahreszeit-abhängiges Template-Design.[/li][li] Demo verschiedener Template-Designs in einem Shop.[/li][/ul]
usw. (Das sind alles Dinge, die wir im xtc/Gambio-Umfeld für Kunden schon gemacht haben…)

Standardmäßig scheitert das in OXID daran, dass a.) der Template-Name [B]fest[/B] in der Datei “[B]config.inc.php[/B]” festgelegt wird, und dass es b.) [B] shopweit [/B]nur [B]ein [/B]Smarty “Compile”-Verzeichnis gibt (“out/tmp”).

(Letzteres würde dazu führen, dass immer die zuletzt kompilierten Vorlagen aus allen Templates dargestellt würden, bzw. die Vorlagen immer neu kompiliert würden…)

Das Smarty “Compile”-Verzeichnis wurde daher jetzt nach “[B]out/template_name/tpl_c[/B]” verlagert, so dass die verschiedenen Templates sich nicht mehr gegenseitig stören können.

Und der Template-Name wird dynamisch gesetzt, so dass OXID unterschiedliche Templates verwenden kann.

[B]
Fazit:[/B]

Das Standard-OXID-Templating ist m.E. etwas “sperrig” (was sich m.E. auch darin äußert, dass viele Shops sich nur mit kosmetischen Änderungen (andere Farben und anderes Logo) am Standard-Design zufrieden geben (müssen)).

Aber es ist auch so flexibel (vor allem Dank der Verwendung von Smarty), dass man sich das relativ einfach nach seinen Vorstellungen zurecht biegen kann…

Und es bietet durch die Bereitstellung der kompletten Shop-Objekte im Template, mächtige Möglichkeiten, das Shop-Aussehen zu beeinflussen.

Bei Magento z.B., das von Hause aus um Größenordnungen sperriger ist (weil es im Grunde kein akzeptables Templating-Konzept besitzt), würde ich noch nicht mal wagen, an so eine Änderung zu denken…

Die von mir auf Template-Basis durchgeführten Änderungen könnte man natürlich wesentlich eleganter im OXID-Core vorsehen.

Vielleicht ist das ja eine Anregung für die OXID-Entwickler: das OXID-Templating kann man definitiv (und ohne allzu große Mühe) übersichtlicher gestalten!

[B]To do:[/B]

Als [B]Entwickler [/B]finde ich diese über den Admin-Bereich gesteuerten Änderungen des Templates (“Look & Feel”) einfach [B]ätzend[/B] (wie bei Gambio auch),
Das ist mindestens 10 mal ineffizienter, als wenn ich die resultierenden CSS-Änderungen direkt in der CSS-Datei vornehme…
(Man stelle sich mal vor, ein komplexes Template wie das auf http://oxid.powertemplate.de/ auf diese Art und Weise bei einem Kunden installieren zu wollen…)

Das war also das erste, was ich über Bord geschmissen habe, ich verwende jetzt meine eigene CSS-Datei!

Was mich jetzt noch stört sind die diversen eMail- und sonstigen CMS-"[B]Snippets[/B]", die ja auch über den Admin-Bereich geändert werden müssen…

Für mich als [B]Entwickler [/B]wäre das wieder sehr viel einfacher, wenn diese CMS-"[B]Snippets[/B]" auch in Dateien in meinem Template-Verzeichnis liegen würden…

Ich denke, ich werde mal das OXID Smarty-Plugin “[B]oxcontent[/B]” so modifizieren, dass es erst mal nachschaut, ob eine Datei des gesuchten Namens im Template-Verzeichnis existiert, bevor es in der Datenbank sucht…

Dann kann man diese CMS-“Snippets” nämlich auch einfach mit dem Template ausliefern…

@avenger
Interessantes Posting, auch wenn ich nur die Hälfte davon verstanden habe :smiley:

Stellst Du ein Template mit diesen Features im OpenScource Bereich zur Verfügung oder nur bei Bezahltemplates?

Sind durch dieses Template schnellere Ladezeiten zu erreichen?

Wir werden die Standard SEO Features geregelt?
(Content oben, Indexierung, interne Verlinkungen, H1-H3 etc. …)

Hört sich wirklich sehr interessant an, vorallem das man doch alles fix in einer CSS Datei ändern kann und die einzelnen Boxen beliebig verschieben sowie ein/ausblenden kann.

Leider fehlt es mir eindeutig an Kenntnissen um dies für mich selber umsetzen zu können. Daher die Frage 1. von worner auch für mich sehr interessant.

MfG und danke für diesen Beitrag, schndRrr

Hallo avenger,

ich bin schwer begeistert! Und gehe grad mit einer Idee schwanger:
Was hälst Du davon, beide Forenbeiträge vorerst in Deutsch zu einem Artikel im Workshop-Stil zusammenzuschreiben? Wir könnten einen Verlag finden, der das veröffentlicht.
Dann gäbe es noch die Möglichkeit, das ganze in Englisch zu publizieren…

Was sagst Du?

Gruß

[QUOTE=Marco Steinhäuser;9982]Hallo avenger,

ich bin schwer begeistert! Und gehe grad mit einer Idee schwanger:
Was hälst Du davon, beide Forenbeiträge vorerst in Deutsch zu einem Artikel im Workshop-Stil zusammenzuschreiben? Wir könnten einen Verlag finden, der das veröffentlicht.
Dann gäbe es noch die Möglichkeit, das ganze in Englisch zu publizieren…

Was sagst Du?

Gruß[/QUOTE]
Freut mich, dass es Dir gefällt.

(Die wahre Schönheit des Konzepts erschließt sich eben eher erfahrenen OXID-Entwicklern… :D)

[B]Ich fände eigentlich die 3. Möglichkeit am besten:[/B]

dass die OXID AG meine Anregung zur Strukturierung des OXID-Templates aufgreift, und das in den OXID-Core übernimmt (was sicher überhaupt nicht schwierig wäre).

Ich fürchte nämlich, dass die jetzt notwendigen PHP-Eingriffe in das Template (und auch das Smarty-Subclassing) “Otto Normalanwender” eher verwirren, als dass sie hilfreich wären…

Wenn allerdings diese Dinge im OXID-Core verankert wären, und man es auf Anwenderebene wieder nur mit Smarty-Template-Code zu tun hätte, wäre die von mir vorgenommene Template-Strukturierung für viele sicher eine willkommene Hilfe und Vereinfachung.

Mir ging es im Moment eher darum, für mich als Template-Entwickler eine besser handhabbare (und automatisierbare) OXID-Template-Umgebung zu schaffen.

Und durch die Veröffentlichung hier im Forum aufzuzeigen, wie man das OXID-Templating m.E. übersichtlicher und einfacher gestalten könnte.

Aber ich bin grundsätzlich auch für andere Lösungen offen…

Moin,

was denkst Du denn? Natürlich habe ich das längst in Richtung Entwicklung geschoben :slight_smile: Wir wollen uns das in den nächsten Tagen (auch nach Ralf’s Rückkehr aus dem Urlaub) mal genauer Anschauen.
Aber das ist eine ganz andere Nummer, die durchaus parallel laufen kann.

Gruß

@avenger
Sehr interessant. Ich habe mich jetzt seid ein paar Tagen in den OXID Shop vertieft und kann nur zustimmen, dass die Handhabung der Templates sehr verwirrend wirkt.
Ein neuer, oder besser ein renomierter :wink: Ansatz wie Du ihn vorschlägst, ist schon fast unabdingbar. Und wie es in so vielen anderen OS Communities gang und gebe ist, wäre es doch für die nicht “Otto Normalanwender” schon ein Schritt nach vorne, ein möglicher “Workshop” würde hier allen zur Verfügung gestellt werden. :smiley:

Hat sich in der Richtung denn mal was getan?
Schaue jeden Tag in dem Thread nach, doch irgendwie ist die ganze Sache irgendwie wieder unter gegangen, soweit ich das verfolgen kann…

Ich find den Artikel wirklich sehr gut - nur leider kann ich in Deinem Mustershop nicht den Warenkorb aufrufen.

Function ‘getMissingArticlesIds’ does not exist or is not accessible! (myarticlelist)

Ich muss sagen, dass die Umstrukturierung daher schwer ist, weil viele Dinge sehr tief im Quellcode verankert sind. Eine Aufteilung ist aber dank Smarty sehr einfach zu realisieren.
Ich arbeite zur Zeit an dem Backend und fluche pausenlos, weil Oxid wirklich unordentlich geschrieben wurde. Wer genauer unter die Haube guckt entdeckt eine Menge unschöner Sachen.

Hallo leolezner,

der Admin-Bereich ist seinerzeit um das Refactoring herumgekommen. Aber das haben wir ja bereits in der mittelfristigen Planung. Vielleicht sollten wir uns besser abstimmen, damit keine doppelte Arbeit in Größenordnungen passiert?

Gruß

Seitens der Comunity kommt keine Beteiligung, sonst bekommt man auch keine Hilfe im Forum. Beteiligung der Entwickler wäre notwendig, weil vieles in Backend in PHP fest eigebaut ist, was den Umbau erheblich erschwert.
Ich bin gerne Bereit an dem Umbau mitzuwirken, aber so wie es bisher aussieht, wir daraus nichts.

Hallo,

Ich bin gerne Bereit an dem Umbau mitzuwirken

Genau davon rede ich. Gib mir bitte etwas Zeit, damit wir intern die Vorgehensweise und die zeitlichen Gegebenheiten abstimmen können.

Gruß

Hallo,

Ich bin gerne Bereit an dem Umbau mitzuwirken

Genau davon rede ich. Gib mir bitte etwas Zeit, damit wir intern die Vorgehensweise und die zeitlichen Gegebenheiten abstimmen können.

Gruß

@ Avenger: Super und vielen Dank für die super tollen Anregungen und den wirklich gehbaren Lösungsansatz.

@ Marco S.: was ist nun aus den Workshops geworden? Es wäre schade, wenn die Superidee und das tolle Konzept von Avenger untergeht.

Gruß aus Riga!
ahaller

was ist nun aus den Workshops geworden?

Ich fände es nach wie vor am besten, wenn man das ganze mal wie eine Art Konzept “zu Papier” bringt. Dafür wurde die OXIDforge erfunden. Man könnte das zum Beispiel mit in die Tutorials schreiben, gern auch in Deutsch:
http://www.oxidforge.org/wiki/Tutorials/de

Hier steht, wie es funktioniert:
http://www.oxidforge.org/wiki/Help/de

Gruß

@avenger
wunderbar, diese Änderung! Wesentlich übersichtlicher.

Was mir u.a. noch nicht so richtig gefällt, ist die Tatsache, dass im Template z.B. beim
<div id=“left_box”> alle Boxen einzeln aufgelistet werden müssen. Will man eine bestimmte Box gar nicht mehr haben, muss man die _index.tpl editieren. Will man die Box rechts haben, ebenfalls.

Nun habe ich mich in den letzten Jahren sehr intensiv mit dem CMS Joomla beschäftigt.
Dort steht auch alles in einer Template-Datei (sehr gut ;))
Wenn dort die Boxen eingebunden werden sollen, erfolgt einfach ein Aufruf von z.B.:
<jdoc:include type=“modules” name=“left” style=“xhtml” />
(modules sind in Joomla quasi die Boxen von Oxid)
Die Module werden im Backend verwaltet, u dort wird denen auch eine “Position” (wie “left”) mitgegeben. Beim Includen werden dann alle Module (boxes) geladen, die diese entsprechende “position” haben. Ausserdem kann auch ein “style” mitgegeben werden.
Bei z.B. style=“rounded” erfolgt die Ausgabe in der Form <div><div><div><div>Content</div></div></div></div>
Und das gleich für alle Module (boxes)
Ausserdem gibt es bei Joomla vom BE aus die Möglichkeit, Fremdmodule zu importieren u sofort auf einer gewählten Position sichtbar zu haben. Tolle Sache.

Ist natürlich, ohne groß in den Core eingreifen zu wollen, nicht so einfach bei Oxid realisierbar.
Aber gefallen würds mir :wink:

edit:
habs grad erst so richtig mitbekommen, dass Du das ja bereits umgesetzt hast mit den box_m_1 usw.
Meine runtergeladene _index.tpl vom 7.10.09 sah doch noch irgendwie anders aus…sorry

[QUOTE=Alan;16784] habs grad erst so richtig mitbekommen, dass Du das ja bereits umgesetzt hast mit den box_m_1 usw.
Meine runtergeladene _index.tpl vom 7.10.09 sah doch noch irgendwie anders aus…sorry[/QUOTE]
Hey, ein Mann mit Durchblick, der das Konzept verstanden hat! :slight_smile:

Ja, in der Tat, für meinen Bedarf als Template-Entwickler geht das Konzept noch [B]wesentlich [/B]weiter…

Da muss ich fast kaum noch in das Template selbst (editierend) eingreifen, sondern ich konfiguriere das alles innerhalb einer Konfigurationsdatei … (Diese Konfiguration in das Backend zu verlagern lohnt sich nicht, da wäre der Aufwand viel zu groß.)

Ich habe die bisherigen Konfigurationsmöglichkeiten der “Boxen” im Rahmen einer aktuellen Template-Entwicklung noch wesentlich weiter getrieben, da ich nun auch noch das Verhalten des Listen- und Detail-Templates extern konfiguriere: (War 'ne Mordsarbeit, die sich aber ganz sicher auszahlen wird…)

[B]In welchem Format sollen die verschiedenen Artikellisten dargestellt werden (“big”, “small”, “thin”, “thinest”).

[/B]Das sieht dann z.B. so aus…

define('LIST_FORMAT_THIN','thin');
define('LIST_FORMAT_THINEST','thinest');
define('LIST_FORMAT_SMALL','small');
define('LIST_FORMAT_BIG','big');
define('LIST_FORMAT_STANDARD','');

define('ACCESSORIES_LIST_FORMAT',LIST_FORMAT_SMALL);
define('ACTIONPRODUCT_LIST_FORMAT',LIST_FORMAT_BIG);
define('ALSO_PURCHASED_LIST_FORMAT',LIST_FORMAT_SMALL);
define('ARTICLES_LIST_LIST_FORMAT',LIST_FORMAT_SMALL);
define('COMPARE_LIST_FORMAT',LIST_FORMAT_THIN);
define('CROSS_SELLS_LIST_FORMAT',LIST_FORMAT_SMALL);
define('CURRENT_PRODUCT_LIST_FORMAT',LIST_FORMAT_THIN);
define('FIRST_ARTICLES_LIST_FORMAT',LIST_FORMAT_BIG);
define('LAST_SEEN_LIST_FORMAT',LIST_FORMAT_SMALL);
define('LONG_RUNS_LIST_FORMAT',LIST_FORMAT_STANDARD);
define('NEWEST_ARTICLES_LIST_FORMAT',LIST_FORMAT_SMALL);
define('NOTICE_LIST_LIST_FORMAT',LIST_FORMAT_SMALL);
define('OFFER_ARTICLES_LIST_FORMAT',LIST_FORMAT_BIG);
define('RECOMMENDATIONS_LIST_FORMAT',LIST_FORMAT_THIN);
define('SEARCH_LIST_FORMAT',LIST_FORMAT_BIG);
define('SIMILIAR_LIST_FORMAT',LIST_FORMAT_SMALL);
define('TAGS_LIST_FORMAT',LIST_FORMAT_BIG);
define('TOP_ARTICLES_LIST_FORMAT',LIST_FORMAT_BIG);
define('VARIANT_LIST_FORMAT',LIST_FORMAT_THINEST);
define('WISHLIST_LIST_FORMAT',LIST_FORMAT_SMALL);

[B]Welche Elemente sollen auf der Startseite angezeigt werden…[/B].

Das sieht dann z.B. so aus…

define('START_SHOW_CAT_OFFER_ARTICLES',true);
define('START_SHOW_FIRST_ARTICLES',true);
define('START_SHOW_LONGRUNS',true);
define('START_SHOW_NEWEST_ARTICLES',true);
define('START_SHOW_TOP_ARTICLES',true);
define('START_SHOW_WELCOME',false);

[B]Welche Elemente sollen in der Detailseite angezeigt werden…[/B].

Das sieht dann z.B. so aus…

define('DETAILS_SHOW_ACCESSORIES',true);
define('DETAILS_SHOW_ATTTRIBUTES',true);
define('DETAILS_SHOW_CURRENT_PRODUCT',false);
define('DETAILS_SHOW_LAST_SEEN',false);
define('DETAILS_SHOW_MEDIA',false);
define('DETAILS_SHOW_MOREPICS',true);
define('DETAILS_SHOW_PERSPARAM',false);
define('DETAILS_SHOW_PRICEALARM',true);
define('DETAILS_SHOW_RECOMMLIST',false);
define('DETAILS_SHOW_REVIEWS',false);
define('DETAILS_SHOW_STOCKMESSAGE',true);
define('DETAILS_SHOW_TAGS',true);
define('DETAILS_SHOW_VARIANTS',true);
define('DETAILS_SHOW_WISHLIST',false);

(Die nächste Verbesserung hier wird sein, dass ich auch noch die [B]Reihenfolge[/B] der möglichen Detailseitenmodule konfigurierbar mache, so dass ich das Detailseiten-Template selbst nicht mehr editieren muss, um diese Elemente der Detailseite zu positionieren…)

Wenn man dauernd neue Templates erstellt (und dazu noch mit kreativen Designern zusammen arbeitet, die möglichst jeden Shop anders aussehen lassen wollen), muss man sich einfach solche Hilfsmittel schaffen, damit das handhabbar bleibt…

Und Dank der segensreichen Nutzung von “[B]Smarty[/B]” als Template-Engine in OXID kann man alles das ganz prima lösen, [B]ohne [/B]in die Shop-Software selbst eingreifen zu müssen.

(Bei Magento z.B. hätte ich noch nicht mal davon [B]träumen [/B]können, so etwas zu realisieren.)

Ich verwende auch eine (per Subclassing) für meinen Bedarf ziemlich erweiterte “Smarty”-Version, da “Smarty” diese ganzen Automatismen ja verstehen und unterstützen muss.

Und im Gegensatz zu xtc/Gambio, wo ich dazu einen kleinen Eingriff in “Smarty” vornehmen musste (der Smarty-Klassenname muss geändert werden), habe ich es (dank des OXID-Modul-Erweiterungs-Mechanismus) mittlerweile geschafft, “Smarty” hier zu erweitern, [B]ohne [/B]das standardmäßig ausgelieferte Smarty ändern zu müssen. (In der Beziehung ist OXID wirklich unglaublich mächtig…)

Und das wird noch weiter gehen, indem ich, wie schon für xtc und Gambio realisiert, das Template in 2 Teile aufspalte: in ein “[B]common[/B]”-Template (das so eine Art Standard-Template ist, das alle “tpl”-Dateien außer der “_index.tpl” enthält), und das eigentliche Shop-Template ("[B]powertemplate[/B]"-Template), das die wirklich shop-bezogenen Teile enthält (Buttons, Grafiken, CSS-Dateien…). (Letztere sind [B]sprachabhängig [/B]abgespeichert (beim CSS nur die Teile, die Hintergrundgrafiken und Buttons definieren). Da unsere Templates grafikorientiert sind, ist das notwendig, um (sprachbezogen) die richtigen Grafiken und Buttons zu verwenden.)

Warum diese Aufteilung?

Nun, 95% des Codes aller Shop-Templates ist erfahrungsgemäß identisch, und nur der “Rest” ist wirklich shop-spezifisch.

Und dieser “Rest” ist dann das eigentliche Shop-Template ("[B]powertemplate[/B]"-Template).

Um aber dennoch shop-bezogen Änderungen im Template zu ermöglichen (es gibt nichts, was Designern und Kunden nicht alles so einfällt…), sieht das Konzept vor, dass man in dem “[B]powertemplate[/B]”-Template (in der gleichen Verzeichnis-Struktur) [B]auch [/B]“tpl”-Dateien haben kann, die dann [B]Vorrang [/B]vor den entsprechenden “tpl”-Dateien im “[B]common[/B]”-Template haben!

Wenn also z.B. jemand die Selektlisten statt als Dropdown- als Radio-Button-Liste haben möchte, muss ich nur die zuständige “tpl”-Datei in das “[B]powertemplate[/B]”-Template kopieren und entsprechend anpassen.

Der Vorteil für uns ist: man muss nicht jedes Shop-Template unserer Kunden neu erfinden, und funktionale Verbesserungen in den Templates (die ja vorwiegend im “[B]common[/B]”-Template stattfinden), kann man bei Bedarf sehr leicht auch allen bestehenden Kunden zur Verfügung stellen…

Der Vorteil für den Kunden ist, dass er ein durchoptimiertes Template erhält, und er einfach an allgemeinen Verbesserungen der Templates teilhaben kann.

Und dass auch sehr individuelle Templates bezahlbar bleiben…

Die schlechte Nachricht zum Schluss ist:

diese erweiterte Funktionalität werde ich (natürlich!) nicht zur allgemeinen Nutzung frei geben, weil man ja seinen Mitbewerbern das Leben nicht [B]zu [/B]leicht machen muss… :smiley:

Aber ich meine, dass für den Endanwender (Shop-Betreiber) der veröffentlichte Template-Stand vollkommen ausreicht, und schon eine [B]wesentliche [/B]Vereinfachung mit sich bringt.

Eine Template-Anpassung macht man “in diesen Kreisen” ja nicht so oft…