WBB 1.0 => WBB 2.3 => WBB 3.1 => WCF 2.1 bzw. WBB 4.1 => WSC 3.0 bzw. WBB 5.0 => WSC 3.1 bzw. WBB 5.1 => WSC 5.2 bzw. WSC 5.2 => WSC/WBB 5.3 => WSC/WBB 5.4 => WSC/WBB 5.5 => WSC/WBB 6.0 =>
Du hast das super Wbb 3.0 vergessen 😝
-
-
Was passiert dann 2100?
Da gibt es das Internet nicht mehr, sondern nur noch das Metaverse
-
Nooooooooooooooooooo, die 20 als Präfix muss schon sein ☝️ Aber ein neuer Name wäre auch mal cool, dann könnte man wieder bei 1.0 anfangen. Und möglichst so das die Abkürzung gleich oder ähnlich bleibt:
WoltLab Webapplication Core
WoltLab Webapplication Forum
WoltLab Webapplication Filebase
…
WWC 1.0
Tada:
WBB 1.0 => WBB 2.3 => WBB 3.1 => WCF 2.1 bzw. WBB 4.1 => WSC 3.0 bzw. WBB 5.0 => WSC 3.1 bzw. WBB 5.1 => WSC 5.2 bzw. WSC 5.2 => WSC/WBB 5.3 => WSC/WBB 5.4 => WSC/WBB 5.5 => WWC 1.0
😬
-
Aber ein neuer Name wäre auch mal cool
Einfach die Firma umbenennen. Es gibt ja genug Vorschläge von Leute, die WoltLab nicht richtig schreiben können.
-
WoltLab Webapplication Core
WoltLab Webapplication Forum
WoltLab Webapplication Filebase
*MEGA" Kunden die das 3x hintereinander fehlerfrei aufsagen können bekommen beim 2. Update Zugang 25% Rabatt.dann könnte man wieder bei 1.0 anfangen
Das wäre ein ganz neues Geschäftsmodell, so könnte jeder immer von Anfang an mit dabei sein.
-
Es gibt immer genug Leute die was nicht schreiben können 😆 Aber ich könnte das hier mal umbenennen, macht mal gute Vorschläge 🤔
-
Das hier? Also cls ?
dein ernst?
Würde ich nicht tun, in allen Stilen steht das doch drin und dafür seid ihr/ bist du doch bekannt ..
Wobei mit immer noch nicht bekannt ist, wofür die Abkürzung steht 🤔
-
Wobei mit immer noch nicht bekannt ist, wofür die Abkürzung steht 🤔
Mörzedehs?
-
ahhh okay, ja, stimmt, da war ja was 🙈 danke flo 🙃
-
Hallo,
Alles in TS sinnvoll und mit Type-Hinting verwenden zu können, ist also kein Mehrwert?
[…]
Ein dynamisches Formular, das nur die Felder anzeigt, die für die aktuelle Auswahl nutzbar sind (z.B. AbstractCustomOptionForm), und die Daten ggf. benutzerdefiniert aufbereiten und anpassen lässt, ist also kein Mehrwert?
Stichwort: Diminishing Returns. Eine nicht-triviale Menge des JavaScripts ist „nur für den Dienstgebrauch“, du wirst wohl eher nicht mit dem WCF.ACP.Cronjob.ExecutionHandler interagieren. Dieses … ich nenne es mal Modul existiert nur für genau einen spezifischen Einsatzzweck auf genau einer Seite. Es funktioniert und macht was es soll, nicht mehr und nicht weniger. Das jetzt in TypeScript umzuschreiben, nur damit es TypeScript ist, ist keine sinnvolle Investition von Arbeitszeit. Im besten Fall funktioniert die Seite hinterher ganz genau so wie vorher. Im schlechtesten Fall hat man einen Bug eingebaut, der dann noch einmal zusätzliche Zeit benötigt, um ihn zu korrigieren. Die Zeit, die man ver(sch)wendet, um das auf TypeScript umzubauen, kann man besser in etwas investieren, das tatsächlich einen Mehrwert bietet.
Das ist vielleicht aus Sicht von WoltLab nicht nachvollziehbar, da es sich für dich leichter gestaltet mal schnell Schnittstellen zu schaffen, meiner Ansicht nach bieten diese Änderungen aber deutlich spürbare Mehrwerte für Entwickler und schlussendlich die Kunden, wenn die Entwicklung stabiler und schneller möglich ist, wenn es Kunden nicht eh direkt betrifft.
„Mal schnell Schnittstellen schaffen“ kommt sicherlich hin und wieder mal vor, ich erinnere mich, dass letztens ein Event bei den Konversationen ergänzt wurde, aber im Wesentlichen arbeite ich mit den gleichen Rahmenbedingungen wie du auch. Dadurch, dass ich selbst privat nicht-triviale Plugins entwickle, Kundenprojekte umsetze und natürlich auch durch die Prüfung im Plugin-Store habe ich denke ich einen guten Überblick darüber, welche Änderung wo einen Mehrwert bringt. Die Umstellung vom BBCodeAddForm auf den FormBuilder ist's definitiv nicht
Gleichzeitig habe ich aber auch umfangreiche Erfahrungen über den Tellerrand von WoltLab Suite hinaus (bspw. habe ich privat zwei nicht-triviale Anwendungen in Laravel) und weiß was gut funktioniert und was nicht. Faustregel: Mach genau das Gegenteil von dem was Laravel macht und es wird gut
Nicht zuletzt habe ich jetzt auch durch meine beiden PHP-RFCs (der zweite war der hier: https://wiki.php.net/rfc/iterator_xyz_accept_array) besseren Kontakt zur größeren PHP-Community bekommen und konnte auch da einiges an „Tipps“ mitnehmen. Beispielsweise steht empty() für mich in neuem Code auf der Verbotsliste, weil der Verhalten sehr intransparent ist.Ein Resultat des Ganzen ist die Integration von Guzzle, was ich durch Laravel kennengelernt und für gut befunden habe und von der API-Ergonomie deutlich angenehmer ist. HTTPRequest steht aber weiter zur Verfügung, weil das ein Bruch um des Brechens wegen wäre. Aber auch die Integration von PSR-7/15 für das Request-Handling ist auf diese Weise entstanden. Letzteres ist tatsächlich etwas, das die Entwicklung stabiler und schneller machen wird, einfach weil der Kontroll- und Datenfluss in einem Controller deutlich einfacher zu verstehen ist, wenn man nicht durch 57 verschiedene Methoden springen muss.
Ansonsten habe ich erst heute zwei kleine gut getestete externe Bibliotheken hinzugefügt (https://github.com/WoltLab/WCF/pull/4918, https://github.com/WoltLab/WCF/pull/4923), um alten gammeligen Code von uns loszuwerden. Für den Nutzer und auch den Entwickler ist die Änderung am Ende unsichtbar, aber jede Zeile Code die ich nicht selbst schreibe und warten ist eine gute Zeile. Selbst wenn ich mal einen Bug in der Bibliothek fixen muss, profitiert am Ende jeder davon.
Ich schätze du hast den falschen Teil zitiert, denn das danach ist meine Interpretation.
Nein, es geht eher um die Begrifflichkeit „suggeriert“, die nach meinem Sprachgefühl und auch nach einer der Duden-Definitionen, für eine Aussage verwendet wird, die nicht den Tatsachen entspricht. In anderen Worten: Nach der Definition des Wortes hältst du es für unzutreffend, dass die Änderungen größere Änderungen sind.
Es gibt ja genug Vorschläge von Leute, die WoltLab nicht richtig schreiben können.
👁👄👁
