[QUOTE=tjungcl;56545]Im Einführungsvideo zum Thema 4.5 Template Blocks wird gesagt, Vorschläge für neue Blöcke seien sehr willkommen.
Wo und wem schlage ich in welcher Form vor, wenn ich neue Blöcke für die Azure Templates benötige? Und wie lange dauert es dann, bis so ein Blockelement aufgenommen wird?
Beispielsweise:
Um am Ende jeder Seite Code für Tracking JS einzubinden zu können, würde ich vorschlagen, in der base.tpl direkt vor </body> einen
[{block name=“LastInsideBody”}]
[{/block}]
einzuführen.
Ist dies die richtige Stelle, das vorzuschlagen? Oder sollte das lieber als Featurerequest in den Bugtracker?
Das Problem an der Sache ist, dass man bei der Entwicklung von neuen Templates für 4.5 doch recht spontan merkt, wenn man irgendwo einen neuen Block benötigt. Wenn so ein Block-Element-Vorschlag nun aber erst durch diverse Instanzen läuft um dann im nächsten Major Release vielleicht aufgenommen zu werden, ist mir damit erstmal nicht geholfen.
Was wäre Ihre vorgeschlagene Vorgehensweise, um hier ein beiderseits flüssiges Vorankommen zu erreichen?
Gruß,
Tjungcl[/QUOTE]
Ich hatte die letzten Monate, im “Shopware”-Kontext, Gelegenheit, das Smarty-Block-Konzept zu verstehen und in Aktion zu sehen.
Mit dem Ergebnis, dass ich beschlossen habe, das fürderhin nicht mehr zu nutzen, da ziemlich sinnlos.
Zum einen macht das m.E. überhaupt nur irgendeinen Sinn, wenn man vorhat, knallhart am Shop-Standard-Template zu bleiben.
(Aber wer will das schon, vor allem wenn man, als Agentur, viele Templates macht.)
Andererseits erschwert es das Template-Updating bei neuen Software Releases ungemein…
Weil man jetzt nicht nur eine Template-Datei auf Anpassungen untersuchen, sondern auch noch prüfen muss, ob ein Block definiert ist, der anzupassen ist.
Und bei dem in OXID implementierten “Block-System für Arme”, wo das Ganze auch noch über die Datenbank und notwendige Admin-Aktionen realisiert ist (statt in den normalen Template-Dateien), um so schwieriger…
Da ist man, m.E., sehr viel besser bedient, wenn man die zu ändernden Template-Dateien in das Custom-Template holt, und dort, ohne den Umweg über Block-Vererbung, direkt so ändert, wie man das braucht.
(Aus der Erfahrung von vielen Shop-Projekten weiß ich, dass man max. 5 bis 10 Template-Dateien ändert, um shopspezifische Layouts und Designs zu berücksichtigen: Struktur-Definition, Startseite, Artikelliste, Detailseite,… Und die kann man locker und bequem im Custom-Template verwalten.)
Damit wird das Updating wieder überschaubar, und man muss bei der Installation eines Templates nicht im Admin Blöcke eintragen, die man ändert, sondern kann das einfach im Rahmen des Templates kopieren.
Auch das Debuggen von Templates geht da wesentlich einfacher von der Hand…
Denn in Smarty 3 beginnt die Zeilenzählung bei jedem Block von vorne. D.h., wenn Smarty z.B. einen Fehler in einer Seite mit mehreren Blöcken auf Zeile 25 meldet, dann muss man erst mal schauen, die Zeile 25 welchen Blocks das ist…
Wobei, dummerweise, die Zeilenzählung in einem Editor diese Blockaufteilung natürlich nicht kennt, und man dann erst mal ziemlich auf dem Schlauch steht…
Bei dem OXID “Block”-Verfahren, das letzten Endes “Smarty Captions” aus den Datenbankeinträgen macht, ist das vermutlich noch wesentlich schlimmer…
Wenn Smarty nämlich dann einen Fehler in Zeile x eines Templates meldet, hat das keinerlei Bezug mehr zum Quelltext des Templates, da Smarty bei der Kompilierung diese Captions in die Template-Datei einbezieht, und die gemeldeten Zeilen dann überhaupt nicht im Template-Quelltext sichtbar sind.
[B]Fazit: [/B]
m.E. ist diese Smarty-Blockerei eine Fehlentwicklung, die Probleme löst, die es vorher gar nicht gab…
Diese Funktionalität braucht eigentlich kein Mensch, man handelt sich aber im Gegenzug eine ganze Reihe von Zusatzproblemen ein.
Und wenn ich dann noch sehe, was für ein Aufwand es vermutlich ist, einen neuen “Block” zu beantragen…
)