[1.16/2.0] Überarbeitung Tag-Parser

Dieser Bereich dient dazu, neue Features zu diskutieren und für die Entwicklung zu dokumentieren. // This area is dedicated to new features including proposals and documentation.
Benutzeravatar
dave
Beiträge: 903
Registriert: 04.02.2011, 19:03:57
Wohnort: Berlin
Kontaktdaten:

Re: [1.16/2.0] Überarbeitung Tag-Parser

Beitrag von dave » 15.07.2012, 12:57:29

Ich habe mir die Erläuterungen mal angeshen, während ich folgendes nebenebei gehört habe: http://vimeo.com/10377992 Sehr schöne Musik! ;)

Folgendes:

Unter 2. Definition eines Tags gibt es das Beispiel <current:date format="H:i" /> mit anschliessender Erklärung. Bei der Erklärung ist zweimal die Rede von "date" (einmal als Name und einmal als Attribut für das Ausgabeformat). Ist das nicht falsch`? Müsste es nicht so lauten:
Dabei ist current das Prefix des Tags, date der Name und das Attribut format beinhaltet das Ausgabe-Format. Der Tag definiert keinen
Inhalt.
Gut, dass es wenige Programmiererinnen gibt. Es ist immer wieder nur die Rede vom Vater. Frauen würden sich da möglicherweise untergraben fühlen :roll:

Ab Kapitel 5.2. Komplexer Tag wird mir das persönlich zu kompliziert. Als dann auch noch Interfaces hinzu kommen, habe ich mich erstmal ausgeklingt. Jemand, der so tief in die Materie muss, wird sich garantiert darüber freuen.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: [1.16/2.0] Überarbeitung Tag-Parser

Beitrag von dr.e. » 15.07.2012, 13:21:31

Hallo dave,

danke für dein Feedback, das Attribut heißt in der Tat "format". Habe es gleich ausgebessert.
Gut, dass es wenige Programmiererinnen gibt. Es ist immer wieder nur die Rede vom Vater. Frauen würden sich da möglicherweise untergraben fühlen :roll:
:D Das stimmt. Aber neutral formulieren kann ich das leider nicht, den "Eltern" stimmt nicht, es gibt nur eine Beziehung zu einem "höheren" Baum-Element. Blöd, trägt aber der Männer-dominierten Welt irgendwie Rechnung. 8-)
Ab Kapitel 5.2. Komplexer Tag wird mir das persönlich zu kompliziert. Als dann auch noch Interfaces hinzu kommen, habe ich mich erstmal ausgeklingt. Jemand, der so tief in die Materie muss, wird sich garantiert darüber freuen.
So war das ja auch gedacht. Das Kapitel sollte von einfach bis komplex aufbauen. Musst aber keine Angst vor Interfaces haben, die tun nicht weh.
Viele Grüße,
Christian

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: [1.16/2.0] Überarbeitung Tag-Parser

Beitrag von jwlighting » 15.07.2012, 17:04:53

Ich nochmal ;)

In Kapitel 3 schreibst du:
Jeder Tag bzw. ab einem definierten Zeitpunkt seine Instanz durchläuft einen definierten Zyklus.
Da bin ich gestolpert, bis ich deine Einfügung kapiert habe:
Jeder Tag, bzw. ab einem definierten Zeitpunkt seine Instanz, durchläuft einen definierten Zyklus.
Dann nochmal, vielleicht hast du es wegen des Seitenwechsels überlesen. Ginge das?
Mir fiel gerade noch ein, ob sich nicht eine Methode transformChildren() gut machen würde. Dann müsste man zur Transformierung der Kinder nicht immer die selbe Foreach-Schleife neu schreiben
LG :)
Jan

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: [1.16/2.0] Überarbeitung Tag-Parser

Beitrag von dr.e. » 15.07.2012, 19:55:42

Hallo Jan,
Da bin ich gestolpert, bis ich deine Einfügung kapiert habe:
Hmm, das wäre mir garnicht aufgefallen - danke! Habe es nun mit Gedankenstrichen explizit markiert.
Dann nochmal, vielleicht hast du es wegen des Seitenwechsels überlesen. Ginge das?
Mir fiel gerade noch ein, ob sich nicht eine Methode transformChildren() gut machen würde. Dann müsste man zur Transformierung der Kinder nicht immer die selbe Foreach-Schleife neu schreiben
Hatte ich tatsächlich überlesen - entschuldige bitte. Grundsätzlich eine gute Idee, hat jedoch den Nachteil, dass du bei der kleinsten Änderung steuernd eingreifen und diese wieder selbst implementieren musst. Für die Standardfälle würde das jedoch ausreichen. Sollen wir das für 1.16 auf die Roadmap nehmen?
Viele Grüße,
Christian

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: [1.16/2.0] Überarbeitung Tag-Parser

Beitrag von jwlighting » 15.07.2012, 21:05:53

Grundsätzlich eine gute Idee, hat jedoch den Nachteil, dass du bei der kleinsten Änderung steuernd eingreifen und diese wieder selbst implementieren musst. Für die Standardfälle würde das jedoch ausreichen.
Klar. Und ein wenig stört mich das auch. Aber genau der Code wird halt sehr oft gebraucht, oft geht es ja nur um die Transformierung der Kinder.
Wie ist das eigentlich, wenn ich alle erkannten Kind-Tags als leeren String transformieren will? Dann muss ich doch wahrscheinlich auch den Platzhalter mit "" ersetzen, oder? Das wäre der einzige andere häufige Fall, der mir noch einfällt. Ließe sich dann als transformChildrenAsEmpty() implementieren. Damit überschreibt/ignoriert man dann die eigentliche Ausgabe der Kindtags.
Sollen wir das für 1.16 auf die Roadmap nehmen?
Im Sinne von DRY auf jeden Fall, oder?

LG :)
Jan

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: [1.16/2.0] Überarbeitung Tag-Parser

Beitrag von dr.e. » 15.07.2012, 21:23:18

OK, dann nehmen wie die beiden Methoden in die Roadmap auf und refactorieren die betroffenen Stellen.

--> http://wiki.adventure-php-framework.org ... rsion_1.16
Viele Grüße,
Christian

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: [1.16/2.0] Überarbeitung Tag-Parser

Beitrag von jwlighting » 15.07.2012, 22:06:44

Ich werde mich aber erst einmal auf die Änderungen und Optimierungen am (DI)ServiceManager, die ID-Singletons und die SMS-Extension konzentrieren.

LG :)
Jan

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: [1.16/2.0] Überarbeitung Tag-Parser

Beitrag von dr.e. » 16.07.2012, 12:23:03

Das ist eine gute Idee. :)
Viele Grüße,
Christian

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: [1.16/2.0] Überarbeitung Tag-Parser

Beitrag von MrNiceGuy » 27.07.2012, 05:44:47

Ich musste gerade erstmal tief in mich gehen - und etliche Monate APF-Abstinenz hinter mir lassen ;) - bevor ich verstanden habe, was du da eigentlich machst, aber: Sehr schön! Dadurch fällt es dann endlich weg sich für eigene TagLibs dann Kopien von placeholder, getstring, etc. anlegen zu müssen. Das wird einem eine Menge Arbeit sparen!

In diesem Zusammenhang fände ich ein Renaming sinnvoll, bei dem sehr zentrale Klassen im APF am Besten ohne Prefix benamt werden. Grundsätzlich wäre es aber ohnehin praktisch, wenn man die Konvention auf "TaglibPrefixName" ändert, dann könnte man auch mit Sortierung aller Klassennamen alle TagLib-Klassen unmittelbar hintereinander haben.

Oder hätte nach dieser Umstrukturierung das Prefix für eine Klasse, die ÜBERALL genutzt werden kann noch irgendeinen Sinn? Also innerhalb der TagLibs ja, aber der Klassenname benötigt diese ja nicht mehr!?
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: [1.16/2.0] Überarbeitung Tag-Parser

Beitrag von dr.e. » 27.07.2012, 16:56:39

Hi Lutz,

schön, dass es dir gefällt.
In diesem Zusammenhang fände ich ein Renaming sinnvoll, bei dem sehr zentrale Klassen im APF am Besten ohne Prefix benamt werden.
Das ist auch der Plan - allerdings erst in 1.17 um die Kompatibilität möglichst noch lange zu gewährleisten. Aktuell ist das Release 1.16 komplett abwärtskompatibel und das finde ich sehr schön. So lässt sich ein Feature oder ein Namespace step-by-step migrieren.
Grundsätzlich wäre es aber ohnehin praktisch, wenn man die Konvention auf "TaglibPrefixName" ändert, dann könnte man auch mit Sortierung aller Klassennamen alle TagLib-Klassen unmittelbar hintereinander haben.
Die Änderung sieht vor, dass es garkeine Konvention mehr braucht und du dir selbst einen Namen suchen kannst.
Oder hätte nach dieser Umstrukturierung das Prefix für eine Klasse, die ÜBERALL genutzt werden kann noch irgendeinen Sinn? Also innerhalb der TagLibs ja, aber der Klassenname benötigt diese ja nicht mehr!?
Die Klassennamen der Implementierung sind ab 1.16 unabhängig von Tag-Präfix und -Namen. Damit ist ein Präfix für eine Klasse nicht technisch nicht mehr notwendig.
Viele Grüße,
Christian

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: [1.16/2.0] Überarbeitung Tag-Parser

Beitrag von MrNiceGuy » 27.07.2012, 19:12:07

Schön klar, dass nun jeder Name möglich ist, aber innerhalb des APF sollte man meiner Meinung nach eine einheitliche Struktur waren und da fände ich es zumindest konsequent den teil "taglib" voran zu stellen!?

Schade, dass das renaming erst in 1.17 kommen wird, ich fand' die abwärtskompatibilität nicht so wichtig wie die schöneren Namen :D
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: [1.16/2.0] Überarbeitung Tag-Parser

Beitrag von dr.e. » 27.07.2012, 22:21:55

Hallo Lutz,

in der Dokumentation habe ich bisher alle Klassen mit dem Suffix "Tag" versehen um klar zu machen, dass es sich um eine Tag-Implementierung handelt. Eine Formular-Tag-Implementierung könnte demnach zukünftig FormTag heißen, ein Platzhalter PlaceHolderTag. Dies würde ich gerne als APF-Coding-Convention so verbreiten und bei der Umbenennung auch so vorantreiben. Passt das aus deiner Sicht?
Schade, dass das renaming erst in 1.17 kommen wird, ich fand' die abwärtskompatibilität nicht so wichtig wie die schöneren Namen :D
Neue Features sollen natürlich direkt so umgesetzt werden und falls Zeit bleibt können auch schon bestehende Features umgestellt werden. Ich würde nur gerne den Vorteil schneller release können wie ein Update der bestehenden Funktionen und Dokumentation.
Viele Grüße,
Christian

Benutzeravatar
MrNiceGuy
Beiträge: 749
Registriert: 03.02.2009, 16:49:42
Wohnort: Nienburg / Weser

Re: [1.16/2.0] Überarbeitung Tag-Parser

Beitrag von MrNiceGuy » 28.07.2012, 11:03:12

Gefallen tut mir das eher weniger, wenn der "starre" Teil hinten steht. Wenn ich an Dinge wie Sortierung usw. denke halte ich es für erheblich einfacher den starren Part ("Tag") an den Anfang zu stellen, also TagForm und TagPlaceHolder. Wenn man sich dann nur mal als Beispiel eine Liste aller Taglib-Klassen ausgeben lassen will, die geladen sind, erreicht man mit get_declared_classes() wesentlich einfacher sein Ziel!? Aber irgendwie kommt mir die Situation auch gerade etwas ähnlich vor, ich fand damals ja auch schon die Ordner-Struktur etwas gewöhnungsbedürftig und habe dann schnell meine eigene Struktur implantiert, weil die Situation dort ähnlich war/ist: In meinen Augen macht es auch eher Sinn auf /context/config/core/database/ zu setzen, als auf /config/core/database/context/, denn so müsste man ja auch in zig Unterordnern umhertollen, um alle Dateien zusammen zu finden, anstatt einfach nur den Context-Ordner anzufassen. Irgendwie eine ähnliche Situation :)
There are only 10 Types of people in the world:
Those who understand binary and those who don't.

TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: [1.16/2.0] Überarbeitung Tag-Parser

Beitrag von TipTop » 28.07.2012, 12:27:37

MrNiceGuy hat geschrieben:Gefallen tut mir das eher weniger, wenn der "starre" Teil hinten steht. Wenn ich an Dinge wie Sortierung usw. denke halte ich es für erheblich einfacher den starren Part ("Tag") an den Anfang zu stellen, also TagForm und TagPlaceHolder.
Im APF (sowie den meisten anderen Frameworks) steht der starre Teil eines Klassennamens doch immer am Ende (MyManager, MyMapper, MyController, MyAction, MyConfigurationProvider, MyValidator, ...) - wieso diese Konvention bei Tags brechen?
TagLibs werden ja stets (bis auf die in pagecontroller.php) in seperaten taglib-Verzeichnissen untergebracht - daher lassen die sich ja auch problemlos sortieren - und bei der neuen Namensgebung ändert sich das ja nicht.
MrNiceGuy hat geschrieben:Wenn man sich dann nur mal als Beispiel eine Liste aller Taglib-Klassen ausgeben lassen will, die geladen sind, erreicht man mit get_declared_classes() wesentlich einfacher sein Ziel!?
get_decalred_classes() gibt doch nur ein Array zurück? Welche Klassen nun Tags sind, muss ja dann extra mit einer Funktion wie substr_count() geprüft werden und bei der spielt es ja keine Rolle, ob Tag am Anfang oder Ende steht.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: [1.16/2.0] Überarbeitung Tag-Parser

Beitrag von dr.e. » 28.07.2012, 15:11:14

Hallo Lutz,

ich gehe da eher mit TipTop. Ob eine Klasse ein Tag ist siehst du ihr ohnehin zukünftig nicht mehr an. Du kannst sie auch FormManager nennen und als Tag registrieren. Entscheidend ist da die Klassen-Hierarchie.
Viele Grüße,
Christian

Gesperrt

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast