[3.3] Recent Topics NG

[LukeWCS]

Eigentlich bin ich ein Fan von einem einheitlichen Erscheinungsbild für den Benutzer. Da kämen dann nur die in phpBB integrierten JS oder PHP Confirmboxen in Frage.

Denselben Standpunkt vertrete ich ebenfalls. Nicht ohne Grund sieht z.B. EMP auf den ersten Blick aus wie der Original ExtMgr, obwohl mein Konzept es mir erlauben würde, die Seite radikal umbauen zu können, so das es keinerlei Wiedererkennung zum Original gäbe.

Aber wenn das phpBB Konzept zu starr ist, weiche ich von meinem Standpunkt ab. Die phpBB confirm_box setze ich ja auch ein, bei EMP werden damit die Rückfragen beim Deaktivieren/Aktivieren geregelt. Das Konzept ist aber Overkill für simple Sicherheits-Rückfragen, deren Ergebnis man nicht auswerten muss und ist ungeeignet/umständlich, wenn es darum geht, mehr als eine Rückfrage pro Einstellungs-Seite zu realisieren.

Davon abgesehen, die JS ConfirmBox ist dem Layout der phpBB confirm_box nachempfunden.

Deine Lösung hat jedoch 2 entscheidende Vorteile. Sie blockiert nicht die weiteren Eingaben auf der Seite und die Meldung ist dem Switch zugehörig angeordnet. Dadurch wird es für den Nutzer übersichtlicher. Deshalb war die Entscheidung nicht sonderlich schwer, ich werde die in EMP verwendete Technik verwenden.

Die Rückfrage wird auch codetechnisch simpel dem gewünschten Control zugeordnet, so das es im Template sehr einfach ist, einen Schalter mit einer Rückfrage auszustatten und zwar beliebig viele davon auf der gleichen Seite. Daher flexibel.

Okay, in dem Fall würde ich vorschlagen, das ich das initial in RT einbaue, weil ich die ConfirmBox Funktionalität dann noch umbauen und universell und transportabel gestalten würde, da ich WWH ebenfalls damit ausstatten will. Denn momentan ist das eine Funktionalität, die auf EMP spezialisiert ist.

Aktueller Zustand (bei EMP):

• 1 Twig Makro
• 3 CSS Definitionen
• 3 JS Funktionen
• 3 JS Event Registrierungen (pro Control)

Geplanter Zustand:

• 1 Twig Makro
• 3 CSS Definitionen
• 1 JS Klasse die sich um alles kümmert

[IMC]

Okay, in dem Fall würde ich vorschlagen, das ich das initial in RT einbaue, weil ich die ConfirmBox Funktionalität dann noch umbauen und universell und transportabel gestalten würde, da ich WWH ebenfalls damit ausstatten will.

Ups, habe ich schon Fertig, aber noch nicht hochladen.
Wenn du deinen Code universeller gestalten möchtest werde meine Änderungen verwerfen. Kein Problem.

Edit:
Ich hatte der Box einen dezenten Schatten hinzugefügt. Vielleicht gefällt er dir auch.

Code: Alles auswählen

	-webkit-box-shadow: 2px 2px 10px 1px rgba(121, 162, 179, 0.5);
	box-shadow: 2px 2px 10px 1px rgba(121, 162, 179, 0.5);

[LukeWCS]

Ups, habe ich schon Fertig, aber noch nicht hochladen.
Wenn du deinen Code universeller gestalten möchtest werde meine Änderungen verwerfen. Kein Problem.

Ist doch prima. Wenn du die aktuelle Technik von EMP übernommen hast, dann hast du jetzt auch schon den Grossteil umgebaut, den ich ansonsten hätte umbauen müssen.

Du könntest das als pl11 einpflegen, dann setze ich darauf auf. Den Schatten könntest auch gleich dazu packen, dann kann ich mir das auch anschauen.

Mit der geplanten JS Klasse hatte ich einige Probleme und auch ziemlich geflucht in den letzten Tagen, weil bei JS auch bei Klassen mal wieder einiges anders ist, als man das von anderen Sprachen kennt. Das verflixte this hat mich einige Nerven gekostet. Inzwischen hab ich das aber im Griff und die Klasse wird jetzt so, wie ich mir das vorgestellt habe.

edit: Hab bei mir im TB wo ich gerade an der ConfirmBox Klasse arbeite, mal testweise den Schatten eingebaut. Gefällt mir sehr gut! Dadurch gibts einen kleinen Tiefeneffekt und die Box "hebt" sich optisch ein wenig vom Hintergrund ab, quasi wie ein eingeblendetes Fenster. Das übernehme ich dann auch bei mir als Standard.

[IMC]

Du könntest das als pl11 einpflegen, dann setze ich darauf auf.

pl11 ist jetzt online.

Das verflixte this hat mich einige Nerven gekostet.

Damit hatte ich neulich auch Probleme. Es verwies nur bei jedem 2. bis 3. Aufruf auf das Element.

[LukeWCS]

pl11 ist jetzt online.

Habs im TB übernommen und gesichtet.

Zum Beispiel das CSS das du übernommen hast, da ist einiges EMP spezifisch. Das ist gemischt, weil ich das damals nicht eingeplant hatte, die ConfirmBox transportabel zu gestalten. Ich habe inzwischen wohl alles isoliert, das werde ich sehen, sobald ich das woanders (RT/WWH) einbaue.

Die Klasse ist grundsätzlich fertig, die wird jetzt erst noch in EMP getestet. Seit etwa einem Monat läuft die Entwicklung zu 1.1.3. Da ich jetzt zum ersten Mal mit Klassen bei JS hantiere, war da viel Recherche und auch einige Abende mit Try&Error angesagt.

Die Klasse wird so wie sie ist, ins bestehende JS eingefügt und dann braucht es lediglich 1 Codezeile, um die Klasse zu initialisieren. Bei RT würde das dann so aussehen:

Code: Alles auswählen

$(window).ready(function() {
	'use strict';

	$('input[name="reset"]').on('click', RecentTopics.FormReset);

	RecentTopics.ConfirmBox = new LukeWCSphpBBConfirmBox('input[name="submit"]');
});

Also keine Funktionen mehr umbenennen und auch kein hardcoded Submit-Selector mehr, letzterer wird einfach als Parameter übergeben. Das wars, den Rest macht die Klasse. Dann wäre nur noch das Twig Makro und CSS einfügen.

Es verwies nur bei jedem 2. bis 3. Aufruf auf das Element.

Na super, das braucht auch niemand. Hast die Ursache gefunden, oder einen Workaround benutzt?

[IMC]

Die Klasse wird so wie sie ist, ins bestehende JS eingefügt und dann braucht es lediglich 1 Codezeile, um die Klasse zu initialisieren.

Das hört sich sehr vielversprechend an.

Na super, das braucht auch niemand. Hast die Ursache gefunden, oder einen Workaround benutzt?

Die Ursache habe ich nicht gefunden. Ich denke das es ein Timing Problem bei jQuery ist. Mein Workaround war event.target. An einer anderen Stelle musste ich ein Timeout von 1000ms setzen, 500ms hatte nicht gereicht.
Hatte ich vorher noch nie. Das hat mich jedoch in meiner Entscheidung bestärkt alles in Vanilla JS zu Programmieren. jQuery mache ich nur noch wenn ich bestehenden Code ergänzen muss.

[LukeWCS]

Das hört sich sehr vielversprechend an.

In der neuesten EMP Beta ist das bereits integriert, ist aber erstmal nur ein funktionierender Zwischenstand an dem ich noch feile.

Stelle musste ich ein Timeout von 1000ms setzen, 500ms hatte nicht gereicht.
Hatte ich vorher noch nie.

Urgs... Mich würde bei Gelegenheit mal der Code Kontext interessieren. Versuchst du evtl. Events für Elemente zu registrieren, die vielleicht noch gar nicht im DOM vorhanden sind? Das wäre eine Erklärung für derlei Probleme.

[IMC]

Versuchst du evtl. Events für Elemente zu registrieren, die vielleicht noch gar nicht im DOM vorhanden sind?

Ja, es geht um Events. Die Elemente sind auch im DOM vorhanden. Es wird daran liegen das es meinen Eventhandler, und noch mindesten einen weiteren gibt. Ich habe mich aber noch nicht weiter damit beschäftigt, weil es im Moment gut funktioniert. Zur Zeit bin ich gedanklich bei einer anderen Extension die ich für mich abändern möchte. Danach werde ich mich wieder darum kümmern. Dann werde ich den anderen Handler entfernen, und falls nötig mit den meinigen zusammenführen.

Edit:
Weil du mich wieder auf das Thema gestoßen hast habe ich eben einen kurzen Test gemacht. Die zwei Handler haben sich beeinflusst. Dies war die Ursache und ist leicht zu lösen.

[LukeWCS]

Weil du mich wieder auf das Thema gestoßen hast habe ich eben einen kurzen Test gemacht. Die zwei Handler haben sich beeinflusst. Dies war die Ursache und ist leicht zu lösen.

Das hört sich doch gut an. Weil, wenn ich irgendwas lese von Timing Problemen im Code die mittels sleep/wait/delay/pause/etc/pp gelöst werden müssen, dann krieg ich Bauchweh. Mit dem Hintergrund das ich sowas natürlich auch kenne und daher weiss, dass derlei Workarounds einen mit absoluter Sicherheit früher oder später böse in den Hintern kneifen.

[IMC]

... Timing Problemen im Code die mittels sleep/wait/delay/pause/etc/pp gelöst werden müssen, dann krieg ich Bauchweh.

Ich auch.
Manchmal kriegt man bei der Fehlersuche einen Tunnelblick und ist froh irgendeine Lösung gefunden zu haben. Mit etwas Abstand schaut man etwas anders auf das Problem. In diesem Fall warst du mein Trigger. Danke dafür.