[3.3] [CDB]Recent Topics NG

[LukeWCS]

Wegen Klasse, okay dann ist das bestätigt, das hatte ich nach Sichtung auf GitHub auch so angenommen.

Wegen der Variable die nicht geändert werden darf, dann ist das geklärt und ich setze es mit um. Die Variable kann ja bleiben, damit sie Übersetzer ändern können. Dann entferne ich nur den Kommentar.

Kann aber dauern, meine Exts werde ich auch nur in grösseren Abständen auf den für mich neuesten Technik Stand (von EMP) hieven. Ich muss erstmal ein grösseres Update bei EC vornehmen, was jetzt leider zwingend nötig ist.

[IMC]

Kann aber dauern,

Kein Problem. RTNG ist derzeit nicht das Wichtigste.

[IMC]

Extension wurde validiert.
Link zum Download der Version 1.0.1 ist im Startbeitrag.

[IMC]

Hi Patrick,

ich habe den Branche dev-1.0.1 in den Master eingefügt und gelöscht.
Auch habe ich ein neues Release für die Version 1.0.1 erstellt.

[LukeWCS]

Alles klar Thorsten, das mit dem Branch wollte ich auch schon vorschlagen. Nächste Updates von mir dann im dev Branch, dann setze ich die Version wie besprochen auch auf 1.1.0 und Code Basis ändert sich auf PHP 8.0.

[IMC]

Hi Patrick,

ich hoffe, dass du ein paar entspannte Tage hattest und noch haben wirst.

Mir ist eben folgendes aufgefallen. Zum Beispiel:
{% if loops.pagination|length && (S_RTNG_LOCATION_TOP) %}

Ich nehme an das loops aus der vor TWIG Ehra stammt. Es schadet nicht, nützt aber auch nichts. Deshalb bin ich der Meinung, dass wir es aus den RTNG-Templates entfernen können. Soll ich oder möchtest du?

Die Anfrage von halil16 bei .com hat mich nochmals veranlaßt die DB-Anfragen genauer anzuschauen. Da konnte ich durch kleine Änderungen die Laufzeit messbar verkürzen. Diese Änderungen wollte ich später hochladen, nachdem du die Anpassungen für die Constructor Property Promotion Syntax vorgenommen hast.

[LukeWCS]

Hi Thorsten

Da nimmst du richtig an, das ist ein typisches Produkt wenn man die alte Template Syntax mittels Twig Konverter behandelt. Bei Exts schon lange nicht mehr gesehen, ich dachte wir hätten den ganzen alten Kram entsorgt. ^^ Sämtliche "Verrenkungen" aus der 3.0 Ära bezüglich Arrays sind hinfällig, weil Twig mit Arrays nativ umgehen kann, schon seit phpBB 3.1. Dazu gehört auch die phpBB Funktion assign_block_vars() die - aus heutiger Sicht - nur alles komplizierter macht.

Mach du ruhig.

Was CPP für RTNG angeht, das steht auf meiner ToDo ganz oben. Heute nochmal ein stilles Update für Ext Check, dann mache ich mich an RTNG, bevor ich meine Exts alle anpacke für die nächste Modernisierungswelle. Wie Mike schon schrieb, die Arbeit reisst nicht ab.

edit: die Klammern um S_RTNG_LOCATION_TOP sind auch sinnfrei.

[IMC]

Dazu gehört auch die phpBB Funktion assign_block_vars() die - aus heutiger Sicht - nur alles komplizierter macht.

Kann ich für mich nicht bestätigen. Es erspart mir die Arbeit selbst Arrays in Schleifen aufzubauen. Was in einigen Fällen durchaus zu mehr Übersichtlichkeit führen kann. Sicherlich wird der Code auch schneller und moderner.
Sollten wir die Funktion aus deiner Sicht ersetzen? Dann kann ich dies mit erledigen.

Mach du ruhig.

Ok.

die Klammern um S_RTNG_LOCATION_TOP sind auch sinnfrei.

Ich bin immer wieder überrascht, welche Kuriositäten man findet, wenn man später, mit etwas Abstand, auf einem Code schaut.

Edit:
Eben testweise in einer meiner Extensionen assign_block_vars() und assign_block_vars_array() entfernt. Der Code wirkt etwas kompakter.

[Mike-on-Tour]

Es erspart mir die Arbeit selbst Arrays in Schleifen aufzubauen.

Wenn man das fragliche Array erst aufbauen muss, dann ist es aus meiner Sicht egal. Aber wenn man schon ein Array hat - z.B. aus einer DB-Abfrage, dann ist es einfacher, dieses Array einfach an eine Template-Variable zu übergeben und in einer TWIG-Schleife auszugeben anstatt es nochmals zu durchlaufen und ein anderes Array (nichts anderes tut assign_block_vars()) zu erstellen.
In der alten phpBB-Template-Ära hatte das durchaus seinen Sinn, weil das HTML nicht mit Arrays umgehen konnte.

Nur meine Gedanken dazu (und ja, ich finde die Möglichkeiten von TWIG einfach toll, ergänzt sich aus meiner Sicht wunderbar mit PHP).

[LukeWCS]

Kann ich für mich nicht bestätigen. Es erspart mir die Arbeit selbst Arrays in Schleifen aufzubauen.

Was aber eigentlich nicht mehr notwendig ist, da Twig sämtliche Array Arten nativ verarbeiten kann. Wenn du in PHP ein Array hast, egal mit welcher Struktur, kannst du das ohne jegliche Aufbereitung direkt an Twig weitergeben. Eine Aufbereitung kann aber sinnvoll sein, wenn das Array in Twig an zig Stellen verwendet wird und den Twig Code kompakter/übersichtlicher machen würde. Aber rein technisch ist eine Aufbereitung nicht zwingend nötig.

Ich bin immer wieder überrascht, welche Kuriositäten man findet, wenn man später, mit etwas Abstand, auf einem Code schaut.

Jupp, egal welcher Code, auch eigener ist nicht gefeit vor "interessanten" Konstrukten. Du findest in meinen Changelogs öfter den Eintrag "Code Optimierung", wo ich ab und an auch veralteten (oder umständlichen) Code überarbeitet habe.

assign_block_vars() diente - soweit ich das überblicken kann - vor allem in der 3.0 Ära dazu, solche Konstrukte wie das Folgende, mit der richtigen Array Struktur zu versorgen:

Code: Alles auswählen

<!-- BEGIN array_name -->
...
<!-- END array_name -->

Ist auch uralt, ich finde hier bei uns solche Beiträge dazu:

Mulitdimensionaler Array aufbauen und auslesen (2008)

Das meinte ich aber alles nicht mit "kompliziert", sondern einen - zugegebenermassen - Grenzfall: ich hatte vor vielen Jahren mal das Problem, das ich bei einer Ext nachträglich ein Template Array auslesen, ändern und wieder zurückschreiben musste. Eine "normale" Template Variable kann man recht simpel so bearbeiten. Aber, wie ich dann feststellte, das trifft leider nicht auf ein Array zu, welches mittels assign_block_vars() generiert wurde. Erst Jahre später, als die besagte Ext und meine Änderung längst schon kein Thema mehr waren, fand ich heraus (weil ich es genau wissen wollte ), ob und wie ich ein solches Array nachträglich bearbeiten kann. Es geht, aber das ist super umständlich/aufwendig und in meinen Augen ein hochgradiges Gemurkse.

Ist das Array dagegen mit assign_vars() oder assign_var() zugewiesen worden, ist das alles kein Problem.

In der alten phpBB-Template-Ära hatte das durchaus seinen Sinn, weil das HTML nicht mit Arrays umgehen konnte.

Jupp, die alte Template Syntax war allgemein sehr rudimentär. Bei Twig hat man umfangreiche Möglichkeiten der Array Iteration. Zum Beispiel Filter, die bei Bedarf noch dazu genommen werden können. Bei EMP mache ich starken Gebrauch von Arrays und dementsprechend werden auch etliche Array Funktionen von PHP und Twig genutzt. Ein Beispiel für die mächtige Twig Syntax:

https://github.com/LukeWCS/ext-mgr-plus ... .html#L170

Eine Iteration aller Ext Gruppen in Kombination mit einem Filter und einer Pfeil-Funktion und das alles elegant in der Schleifen-Deklaration.

(und ja, ich finde die Möglichkeiten von TWIG einfach toll, ergänzt sich aus meiner Sicht wunderbar mit PHP)

Um eine Auto-Analogie zu verwenden: die alte Syntax verhält sich zu Twig wie ein Trabi zu einem Tesla. ^^

edit: Was RTNG angeht, wenns ohne grosse Umbauten ginge, würde ich auf assign_block_vars() verzichten wollen.