Das kommt später noch in das Wiki, hier schon mal im Überblick: 1.) Änderungen Namespaces 1.a) Zugreifen auf fremde Namespaces per Textbaustein {s name="abc" namespace="a/b/c"} 1.b) Globale Definition der Textbaustein-Namespaces per Template-Datei {namespace ignore} // Die Namespaces werden in dieser Template-Datei komplett ignoriert {namespace name="frontend\_index"} // Die Namespaces werden in dieser Datei global von einem anderen Template übernommen 2.) Ausgabe des Controller-Namens als Body-Klasse Dadurch können CSS-Eigenschaften einfach per Controller definiert werden. Also
.checkout div… usw. 3.) Neues Benchmark-Plugins Zum erstellen von eigenen Benchmarks Syntax: $b = Shopware()-\>Benchmark()-\>Start("Start meines Benchmarks"); ... Code $b-\>Stop(); Damit kann man z.B. die Performance eigener Funktionen messen - wird im Firebug unter einem eigenen Punkt zusammengefasst - Übersicht über Zeit je Ausführung & Ram-Verbrauch. Die Werte werden unten auch nochmal kumuliert dargestellt 4.) Neue Plugin-MethodenEinfaches Erstellen von Shopware Cronjobs public function subscribeCron($name, $action, $interval=86400, $active=1, $next=null, $start=null, $end=null) // Beispiel-Registrierung in Install Methode $this-\>subscribeCron("abc","abc"); // Cronjob mit dem Namen ABC mit dem Controller / Event "abc" anlegen! Damit kann ein Plugin nun auch Cronjobs hinzufügen, Sinnvoll z.B. für Anbindungen an Warenwirtschaftssysteme, wo bestimmte Tasks regelmäßig ausgeführt werden sollen. Außerdem wurde der Plugin-Manager im Backend überarbeitet: - Sinnvollere Gruppierung der Plugins - Verbesserte Übersicht im Grid - Error-Reporting bei Installationsfehlern - Direkte Anbindung an den im Dez. verfügbaren CommunityStore 5.) Optimierungen CSS - Bugfixes IE 6 / IE 7 - Auslagerung der jQuery-Style-Zuweisungen in CSS-Klassen - Ausbau der AutoComplete Funktionen 6.) Block Replace Plugin Damit kann man den Inhalt von Blöcken per replace modifizieren - also wenn man z.B. die Anzeige der Bildgrößen im Template modifizieren will, muss man nun nicht mehr den ganzen Block ersetzen, sondern kann einzelne Parameter aus diesem Block überschreiben. {block name="HalloWelt"} Hallo Welt {/block} {block name="Hallo Welt} {replace search="Hallo Welt" replace="Hello World"} {$Smarty.block.parent} {/replace} {/block} Ausgabe: Hello World Hinzu kommen noch einige neue Blöcke, die im Template platziert werden. P.s. Hier geht es nur um technische Neuerungen, funktionale Änderungen und Bugfixes stehen im Changelog.
[quote]Technische Änderungen 3.5.3[/quote] Das ist doch eine feine Sache, wenn der Entwickler so genau zuhört/mit liest, und dann sogar noch willens ist, Änderungen einzubauen… :thumbup: :thumbup: :thumbup: :thumbup: :thumbup: Mein größtes (bisheriges ) Templating-Problem ist damit erst mal vom Tisch, und ich kann frohgemut weiter machen. Viele Entwickler tendieren ja eher dazu, das, was sie sich ausgedacht haben, mit allen Mitteln zu verteidigen und als größte Errungenschaft seit Erfindung des Toastbrots zu rechtfertigen. Die Shopware AG ist da offenbar anders, und ist willens, sinnvolle Vorschläge umzusetzen, und zwar von jetzt auf gleich… Das dürfte einer der größten Pluspunkte für Shopware in D sein: dieser direkte Zugang zur Entwicklung, und die Bereitschaft, zuzuhören… Dagegen ist der eine oder andere Bug nur Peanuts. Weiter so!
[quote=“Stefan Hamann”] 1.) Änderungen Namespaces 1.a) Zugreifen auf fremde Namespaces per Textbaustein {s name="abc" namespace="a/b/c"} 1.b) Globale Definition der Textbaustein-Namespaces per Template-Datei {namespace ignore} // Die Namespaces werden in dieser Template-Datei komplett ignoriert {namespace name="frontend\_index"} // Die Namespaces werden in dieser Datei global von einem anderen Template übernommen [/quote] Gibt es irgendwelche Performance-Aspekte zu berücksichtigen, oder kann ich allen Templates ein {namespace ignore} “verpassen”? @Stefan: Hast Du meine PM von heute erhalten?
@Avenger Ja, schicke dir gleich den Quellcode. Die Datei wird ohne hin in 3.5.3 unverschlüsselt sein, da diese keinen Lizenzrelevanten Code mehr enthält. Performancemäßig dürfte das relativ egal sein, da die Snippets ja nur beim kompilieren ausgelesen werden.
P.s. Danke für das Lob - wir werden uns bemühen auch zukünftig schnell auf sich ändernde Anforderungen zu reagieren. Die 3.5.3 kommt übrigens Morgen als Beta-Release - auch da wäre viel Feedback super! Nächste Woche muss die noch in die QA, so dass das Release vermutlich auf Donnerstag oder Freitag fällt.
[quote=„Stefan Hamann“]Performancemäßig dürfte das relativ egal sein, da die Snippets ja nur beim kompilieren ausgelesen werden.[/quote] Beim kompilieren? Was geschieht denn dann bei einer Textänderung nach der Kompilierung?
Wenn man die Bausteine über das Backend ändert, muss man anschließend Einstellungen > Cache > Textbausteine aufrufen. Die Ändern sich ja i.d.R. nicht so häufig, deshalb haben wir die aus Performance-Gründen fest in die Templates eingebunden. Wenn man die Bausteine direkt in einer Template-Datei anpasst, wird diese ja automatisch neu kompiliert, da sind also auch keine Probleme zu erwarten.