[3.3] Recent Topics NG

[IMC]

Hi Patrick,

ich habe eine Anregung zu deiner inline Confirmbox.
Ich bin gerade dabei diese in einer meiner Extensionen einzubauen. Dabei habe ich eine kleine optische Änderung vorgenommen.
Ich habe die Funktionen show() und hide() durch toggle('scale') ersetzt. Das Ein und Ausblenden der Box ist dadurch etwas geschmeidiger. Vielleicht findest du daran auch gefallen.

[LukeWCS]

nAbend Thorsten.

Interessant, wusste gar nicht, dass man das mit toggle() machen kann. Das setze ich durchaus auch ein, aber eben nur zum ein/ausblenden ohne Animation. Im Moment will der Funke aber noch nicht überspringen. Beim 3D Effekt war das anders, das war quasi sofort "gekauft".

Was mir beim Schalten via toggle('scale') weniger gefällt; das schaltet Zustands-bedingt einfach um. Das könnte z.B. bei einem Form-Reset, bei dem ja alle Boxen geschlossen werden, bei einem undefinierten Zustand der Boxen dazu führen, dass Boxen plötzlich eingeblendet werden. Bei hide() haben wir dagegen eine unbedingte Ausführung, das heisst egal in welchem Zustand die Boxen sind, sie werden auf jeden Fall bei einem Reset ausgeblendet.

Und man kann damit auch direkt einen undefinierten Zustand erzeugen; bei EMP habe ich ja 2 Boxen. Wenn man da toggle('scale') nutzt und eine der Boxen öffnet und dann einen Reset auslöst, wird die geöffnete Box zwar geschlossen, aber die andere - bisher geschlossene - geöffnet. Und bei jedem weiteren Reset haben wir quasi eine Flipflop Schaltung, bei der die Zustände der beiden Boxen invertiert werden.

Ansonsten arbeite ich auch mit toggle(), allerdings übergebe ich true/false und erzwinge so effektiv den gewünschten Zustand. Aber in Kombination mit Animation scheint das nicht zu gehen, zumindest hab ich es noch nicht rausgefunden. Die jQuery Doku zu toggle() ist da auch bisserl dürftig in Bezug auf Animationen. Dort ist von scale zum Beispiel gar keine Rede.

edit: Dass "scale" funktioniert, ist nur Zufall. Du könntest auch "test" angeben, hätte denselben Effekt. Gültige Werte sind nur "swing" und "linear", aber nur als zweiter Parameter. Also interpretiert jQuery das "scale" irgendwie als Anim-Para und führt eine Animation aus. Nämlich die einzige die per Standard bei jQuery enthalten ist.

Siehe: https://api.jquery.com/toggle/#toggle-d ... g-complete

[IMC]

Was mir beim Schalten via toggle('scale') weniger gefällt; das schaltet Zustands-bedingt einfach um. Das könnte z.B. bei einem Form-Reset, bei dem ja alle Boxen geschlossen werden, bei einem undefinierten Zustand der Boxen dazu führen, dass Boxen plötzlich eingeblendet werden.

Da hast du natürlich recht. Die Lösung könnte eine Abfrage vor dem toggeln sein.

Code: Alles auswählen

$('div[id$="_confirmbox"]').each(function() {
	if ($(this).is(":visible")) {
		$(this).toggle("scale")
	}
});

Die jQuery Doku zu toggle() ist da auch bisserl dürftig in Bezug auf Animationen. Dort ist von scale zum Beispiel gar keine Rede.

Hier steht etwas mehr.
https://api.jqueryui.com/scale-effect/

[LukeWCS]

Da hast du natürlich recht. Die Lösung könnte eine Abfrage vor dem toggeln sein.

Hmm, ist mir grad unklar, das würde die Animation ja nur dann starten, wenn die Box sichtbar ist.

Hier steht etwas mehr.

Ach jetzt verstehe ich. Du hast das in der jQuery UI Doku gefunden. UI ist eine zusätzliche Komponente, die wir bei phpBB gar nicht haben. Wie gesagt, scale hat keine Wirkung bei uns, da kann ein beliebiger String drinstehen. Vermutlich wird da nicht sonderlich streng geprüft und deshalb der String irgendwie als Anim-Para interpretiert.

[IMC]

Hmm, ist mir grad unklar, das würde die Animation ja nur dann starten, wenn die Box sichtbar ist.

Das habe ich so bei dem Zurücksetzen des Formulars eingesetzt. Dadurch werden die offenen Boxen geschlossen und keine Box geöffnet.

edit: Dass "scale" funktioniert, ist nur Zufall. Du könntest auch "test" angeben, hätte denselben Effekt. Gültige Werte sind ...

Hatte ich auch gemerkt, dass dort nicht das ausgeführt wurde was angegeben ist. Jedoch war die Animation genauso wie ich sie gern gehabt hätte. Deshalb war es für mich so i.O. (Ich weiß, dein Anspruch ist da höher)
Ich habe es nochmals getestet, die Animation läuft genauso mit einen leeren String.

Grundsätzlich bin ich gegen Animationen auf Webseiten. Deshalb setzte ich sie nur noch da ein, wo sie Übergänge und Änderungen auf der Seite etwas geschmeidiger/ruhiger erscheinen lassen.

[LukeWCS]

Das habe ich so bei dem Zurücksetzen des Formulars eingesetzt. Dadurch werden die offenen Boxen geschlossen und keine Box geöffnet.

Ah

Jedoch war die Animation genauso wie ich sie gern gehabt hätte. Deshalb war es für mich so i.O. (Ich weiß, dein Anspruch ist da höher)

Geht nicht um Anspruch, die Standard Animation von jQuery ist durchaus ansprechend. Mir ging es primär darum, dass das nicht zu meinem Konzept passt, weil ein Umschalten auf Basis des vorherigen Zustands etwas ist, das ruckzuck aus dem Ruder laufen kann. In rund 40 Jahren Software Entwicklung oft genug erlebt. Einmal ein undefinierter Zustand aus irgendeinem Grund und schon haben wir den Salat. In der Klasse verwende ich deshalb nur absolute Aktionen. So ist sichergestellt, das die Klasse das Formular stets in einem klar definierten Zustand hinterlässt.

Grundsätzlich bin ich gegen Animationen auf Webseiten. Deshalb setzte ich sie nur noch da ein, wo sie Übergänge und Änderungen auf der Seite etwas geschmeidiger/ruhiger erscheinen lassen.

Bin da auch eher konservativ und generell sparsam mit optischen Gimmicks. Ich setze das schon auch ein, wo es sinnvoll/hilfreich ist. Bei EMP gibts 2 Situationen wo ein animiertes FA Icon zum Einsatz kommt; bei Versionsprüfung und bei automatischen Bestätigungen um zu signalisieren, dass hier etwas automatisch abläuft.

Jut, zwischenzeitlich gabs von der Klasse auch v1.2.0, diese Version war erstmals Instanz-fähig. Das heisst, die Klasse bindet sich an ein spezifisches Formular und nicht mehr ans ganze Template. Das ist relevant wenn man Templates mit multiplen Formularen hat. Solche Exts gibts einige, EMP hatte bis 1.1.0 auch dazu gehört. Instanzen sind ja gerade eine interessante Eigenschaft von Klassen. Da ich mich aber erst seit kurzem überhaupt mit JS Klassen beschäftige, hatte ich multiple Formulare nicht sofort auf dem Schirm.

Und die nächste Version ist auch seit paar Tagen in Arbeit, primär Optimierung. Dabei habe ich mir mal den Animationspart angeschaut, wie man das zusammen mit absoluten Aktionen unter einen Hut bringen kann und eine Lösung gefunden. Es wäre kein grosses Problem, die Animation per zweitem Klassenparameter anzubieten, mit dem man dann die Geschwindigkeit regeln kann. Dann kann das jeder Ext Coder für sich selbst entscheiden, ob er Animation nutzen will oder nicht. Hängt aber davon ab, ob ich das so realisieren kann, dass eine zuverlässige Funktion stets sichergestellt ist, denn das hat immer Prio über optische Spielereien.

[IMC]

weil ein Umschalten auf Basis des vorherigen Zustands etwas ist, das ruckzuck aus dem Ruder laufen kann.

Kann ich nachvollziehen.

In rund 40 Jahren Software Entwicklung oft genug erlebt.

Da bin ich weit unter. Eigentlich erst seit 2 Jahren wieder etwas intensiver, davor von 1990 bis ca. 1998.

Da ich mich aber erst seit kurzem überhaupt mit JS Klassen beschäftige

Ich auch. Tatsächlich habe ich mich immer gesträubt OO zu Programmieren. Bin erst durch phpBB dazu gekommen und habe gelernt das einem vernünftig angelegte Klassen das Programmiererleben leichter machen können. Vor kurzen habe ich gelernt wie praktisch statische Eigenschaften und Methoden sein können.

Dabei habe ich mir mal den Animationspart angeschaut, wie man das zusammen mit absoluten Aktionen unter einen Hut bringen kann und eine Lösung gefunden.

Da ich eigentlich von jQuery weg bin löse ich meine kleinen Animationen meist mit CSS.

[LukeWCS]

Tatsächlich habe ich mich immer gesträubt OO zu Programmieren.

hrhr ich auch, um OOP hab ich bisher immer einen grossen Bogen gemacht, in jeder Sprache. Hab ich nie gebraucht, ging auch klassisch mit Funktionen und gutem altem Coder Handwerk. Immer dieser neumodische Kram.

Bin erst durch phpBB dazu gekommen und habe gelernt das einem vernünftig angelegte Klassen das Programmiererleben leichter machen können.

Hmja, bei phpBB haben wir gar keine Wahl, erst Recht nicht als Ext Coder. Da ist man schlicht gezwungen, sich zumindest die Klassen Grundlagen anzueignen.

Aber was die inline ConfirmBox Lösung angeht, da hat das als Klasse erhebliche Vorteile, vor allem was die Migrationsfähigkeit angeht. Du erinnerst dich? 3 unabhängige Funktionen die man einzeln zu seinem JS Objekt hinzufügen musste, damit das gekapselt ist. Dann noch den Form-Reset mit ConfirmBoxHide verdrahten und ebenso alle benötigten Element-Events in der ready Funktion registrieren. Das ist alles schön und gut für eine einzelne Ext, wird aber schnell lästig und fehlerträchtig, wenn man das in mehrere einbauen will.

Jetzt nur noch Klasse einfügen, eine Instanz davon anlegen und schon läuft das. Ohne Ext spezifische Anpassungen, ausser den Klassen-Parametern. Das ist schon ne feine Sache. Deswegen feile ich auch gerade laufend daran, um das a) optimal zu gestalten und dabei b) zu lernen was alles geht.

Da ich eigentlich von jQuery weg bin löse ich meine kleinen Animationen meist mit CSS.

Hmm irgendwo hab ich gelesen, dass du dich jetzt doch mal an Validierungen wagen willst. Da solltest du dich nicht komplett von jQuery lösen, weil die Validatoren klar jQuery präferieren und das kritisieren, wenn man pures JS nutzt.

[IMC]

Hmm irgendwo hab ich gelesen, dass du dich jetzt doch mal an Validierungen wagen willst. Da solltest du dich nicht komplett von jQuery lösen, weil die Validatoren klar jQuery präferieren und das kritisieren, wenn man pures JS nutzt.

Vor ein paar Jahren hatte die Benutzung von jQuery als Bibliothek sicherlich Vorteile. Mittlerweile ist die Unterstützung der unterschiedlichen Browser in JS, CSS und HTML so gut das man auf Bibliotheken verzichten kann. Vorausgesetzt man benutzt nicht die allerneusten Funktionen.

Den Vorteil von jQuery sehe ich Moment nur darin, dass ich mit einer Zeile Code eine Funktion abbilden kann für die ich in Vanilla JS eine Schleife mit 4 Zeilen bilden muss. Animationen sind mit jQuery auch sehr einfach zu lösen. Brauch ich für mich jedoch nicht mehr.

Mit Vanilla JS brauch ich ein paar Zeilen mehr Code. Ich habe aber das Gefühl dichter am Kern zu sein. Deshalb fand ich damals auch Assembler so spannend. Da hat man noch gelernt wie eine Schnittstelle seriell/parallel bedient wird. Was der Rechner bei einen Interrupt macht. Wofür der Stack gut ist. Mit den Grundlagen habe ich auch C besser verstanden und konnte mich leichter in die Programmierung mit Zeigern rein denken. Es macht mir einfach mehr Spaß. Das andere fühlt sich an wir das Zusammenstückeln von Modulen.

Wenn ich an einen Validator gerate der, der Meinung sind das Scripte nur mit jQuery gut funktionieren habe ich, oder die, die meine Extension dadurch nie kennenlernen Pech gehabt. Ich werde mich deshalb bei meinen Extensions nicht verbiegen. Ich mag das pure JavaScript.

Da könnte es nur eine Ausnahme geben. Das ist "Image upload use ImageMagick". Das ist im Moment so ein richtig schlimmer mischmasch, da ich dort phpBB JS Funktionen abändern musste. Ich bin aber inzwischen von jQuery so weit weg, dass dies für mich in sehr viel Arbeit ausarten würde.
Vielleicht würde ich da eher die jQuery Passagen zu Vanilla konvertieren.

[LukeWCS]

Vor ein paar Jahren hatte die Benutzung von jQuery als Bibliothek sicherlich Vorteile. Mittlerweile ist die Unterstützung der unterschiedlichen Browser in JS, CSS und HTML so gut das man auf Bibliotheken verzichten kann. Vorausgesetzt man benutzt nicht die allerneusten Funktionen.

Auch wenn inzwischen der Browser-Engine-Wildwuchs weitestgehend beendet ist und vor allem eine Browser Engine sich durchgesetzt hat, gibt es noch immer Browser spezifische Eigenschaften und Macken. In den letzten Jahren haben Udo und ich ein paar solche "Spezialitäten" ausgemacht, bei der Entwicklung verschiedener Exts.

Dadurch das sich eine Engine durchgesetzt hat, ist das aber inzwischen ganz anders als noch vor 15-20 Jahren oder noch älter. Da musste man ständig bei allem, egal ob CSS oder HTML oder JS, für jeden Browser eine Extrawurst braten, das war fürchterlich. Dazu kommt noch, das ich noch die Anfangszeiten von JS kenne und damals war JS ein unausgegorener Kram; unzuverlässig und jeder Browser Hersteller hatte eigene Vorstellungen der Implementierung. Das haben wir glücklicherweise weit hinter uns gelassen. Auch wegen sehr willkommener Standards.

Den Vorteil von jQuery sehe ich Moment nur darin, dass ich mit einer Zeile Code eine Funktion abbilden kann für die ich in Vanilla JS eine Schleife mit 4 Zeilen bilden muss.

Gerade das ist für mich eine der wichtigsten Vorteile, warum ich sehr gerne mit jQuery arbeite. Bei jQuery sage ich nur "spring" und jQuery frägt nur noch "wie weit?". Bei JS muss ich das erst alles haareklein notieren und jedes Detail einzeln ausarbeiten. Mein Fokus ist aber eher PHP, JS ist für mich nur eine sekundäre Sprache um das realisieren zu können, was mit PHP nicht geht. Das ist also eine Frage des Standpunktes.

Darüber hinaus hat jQuery weitere Vorteile:

• Browser-Kompatibilität: Wie oben bereits angedeutet, gibt es auch heute noch Browser-spezifische Eigenschaften. Das wird bei jQuery berücksichtigt und darum muss ich mir keinen Kopf darum machen, ob mein Code auch bei Browser x, y, oder z läuft. Das heisst, verwendet eine Ext jQuery statt purem Javascript, ist sie automatisch robuster, weil Browser-Kompatibilität schon mit an Bord ist.
• Leichter zu lesen: Nutzt man pures JS, dann müssen bestimmte Funktionen wie erwähnt Detail für Detail aufgebaut werden. Es gibt aber für jede Aufgabe zig verschiedene Lösungswege und das noch gepaart mit individuellem Programmier-Stil sorgt dafür, das ein Kollege oder Validator zum Lesen und Verstehen eines JS (Micro) Codes deutlich länger braucht, als für einen jQuery (Macro) Code.
• Zuverlässigkeit: Gerade für JS Anfänger ist jQuery im phpBB Ext Umfeld besser geeignet, weil die Chance einen sauber funktionierenden und kompatiblen Code zu erzeugen, mit jQuery deutlich höher ist, als mit purem JS. Bei reinem JS müssen sehr viel mehr Grundlagen gelernt werden und es gibt ungleich mehr Möglichkeiten, grossen "Mist" zu programmieren. Hier muss man auch berücksichtigen, das veröffentlichte Exts nicht mehr auf das persönliche Umfeld begrenzt sind, sondern auf einer Vielzahl von verschiedenen Webservern und Browsern laufen müssen. Auch das dürfte ein Grund sein, warum Validatoren lieber jQuery als pures JS sehen.

Wenn ich an einen Validator gerate der, der Meinung sind das Scripte nur mit jQuery gut funktionieren habe ich, oder die, die meine Extension dadurch nie kennenlernen Pech gehabt. Ich werde mich deshalb bei meinen Extensions nicht verbiegen. Ich mag das pure JavaScript.

Hat mit verbiegen nichts zu tun. Bei jedem grossen Software Projekt gibt es Projekt-spezifische Vorgaben/Richtlinien/Empfehlungen an die man sich halten muss/sollte. Und die Vorgaben von phpBB sind noch sehr human so nebenbei. Ich komme aus einer komplett anderen Software-Welt und für mich war alleine PHP ein regelrechter Kulturschock. Es hat eine Weile gedauert, bis ich da einige für mich sehr schwer verdauliche Brocken verarbeitet hatte. Dazu gehörte auch, mich an Coding Richtlinien zu halten, die für mich ungewohnt waren. Richtlinien und Empfehlungen dienen ja dazu einen Standard zu etablieren, damit man austauschbaren und einfach wartbaren Code bekommt und nicht jeder macht, was er will.

edit: Ich habe das Anim-Feature mal Testweise in die Klasse eingebaut. Mal sehen, ob ich das als feste Option drin lasse, ist noch nicht entschieden. Wir testen das jetzt mal in unserem privaten Bastelforum.