WoltLab Community Forum

Quoted from "Hawkes"

Das Argument gegen xPath müsste doch jedem klar sein. Das checkt doch kein "normaler" Admin mehr, wenn er dann an seinen Templates schrauben will. Außerdem: schon jetzt zerstören sich die Leute scharenweise die XHTML-Validität. Das ist meistens mehr oder minder "egal", aber bei XML ist die Validität nunmal essentiell! Wir wollen doch eine Forensoftware mit der auch bibini glücklich ist

Das sind doch Argumente die gar nichts mit der Realität zu tun haben...

1. XPath wird in den Templates vom WCF (und dem WBB) erst gar nicht verwendet, wozu auch: die Templates müssen hier nicht nachträglich verändert werden, sie sind bereits in der benötigten Ausführung vorhanden. Die Möglichkeit der nachträglichen Veränderung ist nur für Erweiterungen relevant. Wie auch bei Template-Events erscheinen die XPath-Regeln nicht in der Templateverwaltung vom ACP, wieso sollte sich der Administrator also mit XPath auseinandersetzen müssen? Er könnte sich höchstens wundern weshalb das ausgegebene XHTML nicht dem entspricht was er in den Templates stehen hat - aber das ist kein Problem von XPath, das war schon bei den Template-Platzhaltern so und wird auch bei den Template-Events so sein. Für den Administrator ändert sich also gar nichts.
   
2. Lediglich die Entwickler von Paketen müssen sich mit XPath beschäftigen - und auch nur dann wenn sie eine Erweiterung programmieren die mit Template-Events nicht arbeiten kann. Es ist für einen Entwickler besser sich im Zweifel mit einer etwas komplizierteren Technik zu beschäftigen als sein Vorhaben als unmöglich abgestempelt zu bekommen. Abgesehen davon war DAU-Kompatibilität für Entwickler (also dass Entwickler programmieren die es nicht mal schaffen sich in XPath einzulesen) nie ein Ziel und das sollte sie auch nicht sein.
   
3. Die Fehlerintoleranz von XML ist doch nur vorgeschoben. Wird ein Template so angepasst dass es kein gültiges XML mehr darstellt wird ein entsprechender Fehler ausgegeben. Das ist technisch überhaupt kein Problem, entsprechende Fehler würden dadurch schon aus dem Weg geräumt werden. Ein Entwickler kann kein Paket veröffentlichen das die XML-Kompatiblität zerschießt - denn dann würde es ja nicht funktionieren.

Quoted from "Marcel Werk"

Jetzt kann man neue Events aber direkt im Github via Pull Request vorschlagen, was die Aufnahme wohl deutlich beschleunigen wird.

Selbst wenn wir annehmen würden das funktioniert, was ich nicht tue denn wenn das konsequent umgesetzt wird würden die Templates geradezu von Template-Events überschwemmt werden, wäre zwar die Problematik der Template-Events in den Templates der LGPL-Pakete gelöst. Da gibt es nur ein klitzekleines Problem: Das WBB mit seinen zahlreichen proprietären Paketen ist nicht auf GitHub - und die bringen auch zahlreiche Templates mit. Da wird man wohl davon ausgehen können dass sich hier die Situation gegenüber den alten Template-Platzhaltern nichts ändern wird: Wird einfach nicht gemacht.

Quoted from "Hawkes"

Sollten Templatepatches unumgänglich sein, dann möge sich einer Erbarmen und das PIP wieder einfügen und WCF 2.0 kompatibel machen und an populärer Stelle (also vorzugswiese hier) veröffentlichen, sodass alle Entwickler etwas davon haben.

Ich würde mich sogar bereit erklären diesen Pull Request zu machen. Aber hey, du wirst es nicht glauben - der wird abgelehnt werden! Vollkommen egal, es wird nie passieren dass die Template-Patches ins WCF 2.0 wieder eingeführt werden nachdem es veröffentlicht wurde.

Quoted from "Marcel Werk"

Ich denke, Hawkes hat es gut auf den Punkt gebracht. Man sollte abwarten wie sich Template-Events in der Praxis bewähren. Wenn dann immer noch Bedarf vorhanden ist, kann man die Unterstützung für Template-Patches auch als separates Paket nachliefern (muss auch nicht von WoltLab selber kommen; Code ist eh LGPL).

Das würde erst mal voraussetzen dass man entsprechende Einstiegspunkte im Quelltext hätte. Jedenfalls sind mir keine Einstiegspunkte ins Templatesystem bekannt, als ich vor einiger Zeit für ein Projekt beim WCF 1.1 danach gesucht habe, habe ich jedenfalls keine passenden gefunden.

Quoted from "Rudi"

Das würde erst mal voraussetzen dass man entsprechende Einstiegspunkte im Quelltext hätte. Jedenfalls sind mir keine Einstiegspunkte ins Templatesystem bekannt, als ich vor einiger Zeit für ein Projekt beim WCF 1.1 danach gesucht habe, habe ich jedenfalls keine passenden gefunden.

Die Einstiegspunkte in den PIPs reichen bereits aus und die gibt es glaube ich sogar in WCF 1.1 schon. Ansonsten wohl auch ein leichtes, diese noch hinzufügen. Stell' doch bitte nicht alles so schlecht und endgültig dar!

Ob sich das System ohne Template-Patches bewährt wird man spätestens in der Betaphase sehen und dann kann man immer noch entsprechend handeln.

Quoted from "Rudi"

Das sind doch Argumente die gar nichts mit der Realität zu tun haben...

Ich glaube wir reden nicht über das Gleiche, oder? Also ich gehe davon aus, dass du willst, dass die Templates an stelle von (X)HTML 5, was in stricter Form ja nur ein Unter"dialekt" von XML ist, komplett mit einer XML Struktur aufgebaut werden. Hier sehe ich nur das Problem des späteren Admins. Ich helfe in mehrere Foren ab und an bei der Administration und in keinem davon werden unveränderte Templates verwendet. Die Admins dort, sind jedoch nicht mit der genauen Technik vertraut. Sie wollen beispielsweise einfach mal eben ein GA Snippet, einen Facebookbutton oder was auch immer einbinden. Dazu bekommen sie von den Serviceanbieter ja den entsprechenden HTML!-Code direkt vorgesetzt. Nun wollen sie diesen einfach irgendwie ins Template einbauen und versauen damit oftmals die Validität des Dokuments oder es geht zumindest nicht mehr als strict durch. Nun willst du aber einem Admin doch wohl nicht wirklich einen Validatorfehler direkt durchreichen. Ich denke die wenigsten können damit etwas anfangen.

Grundsätzlich müsste xPath bereits jetzt bei einem fertig kompilierten Template funktionieren. Testen kann man das ja mal...

Wenn ich fragen darf, wie viele Plugins (grob geschätzt) werden derzeit im Pluginstore angeboten, die auf Template-Patches zurückgreifen?

ich bin mit dem WBB System der Templatepatches nicht so vertraut, allerdings kenne ich im vB das TMS Addon was ähnlich funktioniert
beim WBB wage ich mich zu entsinnen, das sich das Forum erdreistet immer im Originaltemplate herumzumalen, was verständlicher Weise zu Fehlern führt (weil ein Patch auch mal rückgängig gemacht werden muss) und man diese dann immer ein Drama sind zu umgehen wenn die Stelle sich ändert, darum sollte man vielleicht dort mal ansetzten es "besser" zu machen

das TMS hingegen hat die Templatepatches einzeln gespeichert und führt diese bei Änderungen am Template immer von neuem aus, das geänderte Template wird dabei dann gesondert gespeichert und von der Software verwendet
im Fehlerfall muss man dann lediglich die betreffenden Stellen im TMS Eintrag überarbeiten
hat den Vorteil das der Admin auch selbst im ACP nur partielle Änderungen anlegen kann, statt ein ganzen Template wegen eines winzigen Eintrags zu überarbeiten

vielleicht hat sich dahingehend auch schon mal was getan und meine Infos sind veraltet, im WCF ACP finde ich aber nur die möglich Templates auf die alte "schlechte" Weise zu bearbeiten, mit templatepatchen hab ich wie gesagt nie selbst gearbeitet mich nur mit einigen widerporstigen Addons herumgeschlagen

Quoted from "Rudi"

Ich würde mich sogar bereit erklären diesen Pull Request zu machen. Aber hey, du wirst es nicht glauben - der wird abgelehnt werden! Vollkommen egal, es wird nie passieren dass die Template-Patches ins WCF 2.0 wieder eingeführt werden nachdem es veröffentlicht wurde.

Sind wir heute mal wieder auf der absolut negativen Tour? Das man mal unterschiedliche Ansichten bei der Entwicklung haben kann, ist doch völlig normal. Da streckt man sogar die Hand aus und schlägt dir vor, nen konkreten Vorschlag via Pull-request einzureichen, und du schmetterst dieses Angebot einfach ab, find ich auch nicht fair.


Zu deinen Auführungen mit XPath gibt es noch folgendes zu sagen:
Bereits jetzt nehmen viele Admins immer wieder templatemodifikationen vor, die mit validem XMl recht wenig am Hut haben. Das führt bereits jetzt, v.a. im Zusammenhang mit dem portal, aber auch an anderen Stellen, zu darstellungsfehlern und teils JS Fehlern. Ich möchte mir ehrlich gesagt gar nicht erst vorstellen, was passiert, wenn man sich mit invalidem Code dann uch noch viele Plugins u.a. total abschießt. ich seh da schon jede Menge Hilfethemen auf das Supportforum zurollen. Das sollte man da auch noch im Hinterkopf behalten. Das selbe Argument spricht auch gegen die Templatepatches, sie führen in der Praxis zu viel mehr Fehlern, als sie wirklich nützen. An dieser Stelle möchte ich z.B. nochmal folgendes auszeigen:
Brotkrümelnavigation auch unten anzeigen

Arian Glander zeigt in dem Blogartikel sehr schön, wie man das sehr elegenat und einfach mit JS umsetzen kann - funktioniert super, sieht gut aus. Ich habe auch schon Plugins gesehen, die so etwas mit Templatepatch machen.

manchmal gibt es eben nicht die perfekte Lösung - Templatepatches sind für Entwickler sicherlich reizvoll, weil man damit beliebige Freiheiten hat - andererseits sind sie auch eine große fehlerquelle. XPath ist sicherlich eine attraktive Möglichkeit, sehr flexibel, kann aber auch wieder sehr sehr leicht vom unbedarften Admin effektiv lahmgelegt werden, ohne, dass sich dieser groß seiner Schuld bewusst ist.

Ich möchte hier nicht umbedingt für oder gegen das eine sprechen - aber prinzipiell sollte man immer im Hinterkopf behalten, dass dies immer eine Sache der Abwägung ist. Und wenn das WCF 2.0 wie bisher möglichst "deppensicher" sein soll, dann ist das natürlich etwas, was man auch in die Betrachtung mit einbeziehen muss.

Bezüglich der Templateevents wäre es imho auch eine gute Idee, wenn man das Templatesystem so gestaltet, dass prinzipiell immer am Anfang eines neuen Templates ein Event abgefeuert wird (e.g. "templateNameStart" und "templateNameEnd") - selbst wenn dies nicht explizit im Quellcode steht. So würde man zumindest sicherstellen, dass am Anfang und Ende jeden Templates ein Event vorhanden ist.

Quoted from "Hawkes"

Nun willst du aber einem Admin doch wohl nicht wirklich einen Validatorfehler direkt durchreichen. Ich denke die wenigsten können damit etwas anfangen.

(Ich zitiere jetzt mal nicht alles, die Antwort bezieht sich aber auf deinen kompletten Beitrag) Da existieren verschiedene Lösungsansätze derartige Probleme zu umgehen. Der wichtigste Faktor wäre den Administratoren beizubringen dass es nicht ihre Aufgabe ist an den Templates etwas zu verändern wenn sie nicht wissen was sie tun. Aber gut, das kann man auch als vorgeschobenes und etwas realitätsfernes Argument betrachten. Viel wichtiger ist dass auch wirklich technische Lösungen existieren welche diese Problematik beheben.

Die XML-Validität muss nur innerhalb der Templates gegeben sein um auf den Code XPath anwenden zu können (wie vormals bereits erläutert wäre die Anwendung von XPath rein serverseitig). XHTML-Validität ist, wie gehabt, in keinem Fall notwendig - den XML-Parser der XPath anwendet interessiert es ja nicht was das XML beschreibt, ihn interessiert vielmehr nur dass der Code XML-valide ist. Auch dass der an den Browser übertragene Quellcode XML-valide ist, ist nicht notwendig. Dadurch dass die Daten wie gehabt mit dem Content-Type text/html übertragen werden, werfen die Webbrowser ihre SGML-Parser an wodurch XML-Fehler kein Problem darstellen. XML-Fehler sind in der Praxis aber eigentlich auch kein wirkliches Problem, Code-Snippets, wie von dir angesprochen, sind in den meisten Fällen XML-valide. Das liegt einfach daran dass der SGML-Standard mit der Etablierung von XHTML 1.0 angepasst wurde und die XML-Syntax auch bei SGML zur bevorzugten Syntax wurde.

Dennoch, natürlich hast du Recht - ausgeschlossen sind derartige Fälle nicht. Soll also XML-invalider HTML-Code in ein Template eingefügt werden kann dies über ein Pseudo-Element geschehen. Ich denke da beispielsweise an Lösungen wie <wcf:html><![CDATA[<img src="http://example.com/example.png">]]></wcf:html> die vom WCF dahingehend interpretiert werden, dass lediglich der Inhalt, also <img src="http://example.com/example.png">, an den Browser übertragen werden soll. Die XML-Validität bleibt gegeben und auch in Sachen Performance stellt das kein Problem dar, wird diese Interpretation doch bereits bei der Templatekompilierung durchgeführt.

Es bleibt natürlich das Problem bestehen dass der Admin davon nichts weiß und sich über irgend welche mysteriösen Fehlermeldungen wundert. Das lässt sich aber eigentlich ohne größere Probleme beheben, Stichwort Dokumentation. Wird ein entsprechender Fehler ausgegeben wird immer auch die fehlerhafte Stelle im Code genannt. Zusätzlich kann man den Admin darauf hinweisen dass wenn er Code einfügen möchte diesen unter Umständen in <wcf:html><![CDATA[...]]></wcf:html> einschließen muss. In der Praxis werden die Admins das also hinbekommen, man muss sie lediglich richtig an die Hand nehmen und eben nicht die Validatorfehler einfach direkt durchreichen.

Optimal ist dies natürlich nicht, irgendwo muss man aber Abstriche machen. Das ist noch immer 100x besser als die Erweiterbarkeit des WCF auf massive Art und Weiße einzuschränken, viele Anwendungsfälle werden gar komplett unmöglich. Ich möchte außerdem noch mal betonen dass XML-Validitätsfehler die absolute Seltenheit sein werden. XHTML-Validität wäre da schon eher ein Problem, diese wird aber zu keinem Zeitpunkt benötigt.

Quoted from "Netzwerg"

Sind wir heute mal wieder auf der absolut negativen Tour? Das man mal unterschiedliche Ansichten bei der Entwicklung haben kann, ist doch völlig normal. Da streckt man sogar die Hand aus und schlägt dir vor, nen konkreten Vorschlag via Pull-request einzureichen, und du schmetterst dieses Angebot einfach ab, find ich auch nicht fair.

Ja, ich bin da auf einer absolut negativen Tour. Das hat den einfachen Grund: Ich bin davon direkt betroffen. Ich habe zahlreiche Projekte am Laufen die essentiell auf Templatepatches angewiesen sind. Diese Template-Events sind nicht mehr als maginal aufgebohrte Template-Platzhalter die in vielen Fällen einfach nicht ausreichen. Das Angebot ins WCF 2.0 ein XPath-System zu implementieren ist doch nur vorgeschoben, das ist jedenfalls der Eindruck der hier am laufenden Band vermittelt wird. Es wird doch zu jedem nur möglichen Zeitpunkt verdeutlicht dass man eine XPath-Lösung nicht haben will, warum sollte ich also glauben dass mein Pull Request, in dem Stunden über Stunden Arbeit stecken würde, angenommen wird?

Quoted from "Netzwerg"

An dieser Stelle möchte ich z.B. nochmal folgendes auszeigen: Brotkrümelnavigation auch unten anzeigen

Arian Glander zeigt in dem Blogartikel sehr schön, wie man das sehr elegenat und einfach mit JS umsetzen kann - funktioniert super, sieht gut aus. Ich habe auch schon Plugins gesehen, die so etwas mit Templatepatch machen.

Es ist in den wenigsten Fällen so einfach. Es ist etwas vollkommen anderes zusätzlichen, und noch dazu optionalen, sprich nicht zwangsläufig benötigten, Code einzufügen als bestehenden Code zu manipulieren. Das ist dan alles andere als elegant und einfach mit JS umzusetzen. Klar, es ist meist möglich - aber extrem kompliziert, hässlich, unperformant und in einigen Fällen sogar gar nicht möglich.

Quoted from "Netzwerg"

Ich möchte hier nicht umbedingt für oder gegen das eine sprechen - aber prinzipiell sollte man immer im Hinterkopf behalten, dass dies immer eine Sache der Abwägung ist. Und wenn das WCF 2.0 wie bisher möglichst "deppensicher" sein soll, dann ist das natürlich etwas, was man auch in die Betrachtung mit einbeziehen muss.

Irgendwo muss die Deppensicherheit aufhören. Das WBB war schon immer primär aus einem Grund so erfolgreich: Die riesige Community welche die Software massiv erweitert hat. Die Entwicklung muss demnach in erster Linie das Ziel verfolgen es den Entwicklern leichter und nicht schwerer zu machen, direkt danach folgt dann die Weiterentwicklung der eigentlichen Software. Wie viel Supportaufwand es bedeutet wenn Menschen etwas tun was sie nicht tun sollten, sprich eine Software verändern ohne auch nur die geringste Ahnung zu haben was sie tun, sollte bedeutend weiter hinten stehen. Man sollte nicht vergessen dass das die Minderheit ist, die große Mehrheit möchte von der Erweiterbarkeit profitieren und hatte hier noch keine Probleme.

Außerdem: XPath wird weniger Probleme verursachen als Templatepatches. Das größte Problem der Templatepatches war immer dass sie sich gegenseitig behindert haben, besonders krass wurde es dann immer wenn sogar die Deinstallation von Paketen wegen Templatepatches unmöglich wurde. Derartige Auswüchse können bei XPath nicht auftreten, modifiziert es den Code doch erst bei der Templatekompilierung und speichert nicht etwa veränderten Templatecode ab.

Zu deinem übrigen Beitrag siehe die Antwort an Hawkes.

Quoted from "Rudi"

(Ich zitiere jetzt mal nicht alles, die Antwort bezieht sich aber auf deinen kompletten Beitrag) Da existieren verschiedene Lösungsansätze derartige Probleme zu umgehen. Der wichtigste Faktor wäre den Administratoren beizubringen dass es nicht ihre Aufgabe ist an den Templates etwas zu verändern wenn sie nicht wissen was sie tun. Aber gut, das kann man auch als vorgeschobenes und etwas realitätsfernes Argument betrachten. Viel wichtiger ist dass auch wirklich technische Lösungen existieren welche diese Problematik beheben.

Das ist aber denke ich immer noch ein Knackpunkt. Dein Ansatz mit einem Pseudoelement ist nicht schlecht, aber es bleibt dabei, dass es viele viele Admins gibt, die einfach und unkompliziert mal eben ein Snippet einfügen wollen und ich denke das ist eher die Regel und nicht die Ausnahme. Diesen Admins nun zu sagen "Das Template ist tabu für euch!" wird nicht funktionieren. Es war schon schwer genug den Leuten klar zu machen, dass man nicht in den css files rumeditiert und das man für Templateänderungen doch bitte den ACP Templateeditor verwenden soll. Auch musste man besonders beim WBB 3.0 einer nicht gerade kleinen Anzahl an Leuten klipp und klar machen, dass PHP Hacks tabu sind!

Quoted from "Rudi"

Es wird doch zu jedem nur möglichen Zeitpunkt verdeutlicht dass man eine XPath-Lösung nicht haben will, warum sollte ich also glauben dass mein Pull Request, in dem Stunden über Stunden Arbeit stecken würde, angenommen wird?

Uff... so wäre der Linuxkernel nie entwickelt worden

Nimm mal Toby als Beispiel. Er diskutiert oft ja recht hitzig und kontrovers mit WoltLab oder im speziellen mit Marcel, hat aber manchmal einfach einen Patch vorgeschlagen oder sogar noch umfangreichere Mockups erstellt und manches davon ist im WCF gelandet, manches aber auch nicht. Ich finde die Idee mit dem xPath-Parser nicht schlecht und verfolgenswert. Ich beginne momentan ein neues Semester, daher habe ich momentan nicht die Zeit an einer Draft-Implementation mitzuwirken, ansonsten würde ich dir das jetzt anbieten, ob man das einfach mal konzeptionieren, implementieren und testen will.

Quoted from "Hawkes"

Das ist aber denke ich immer noch ein Knackpunkt. Dein Ansatz mit einem Pseudoelement ist nicht schlecht, aber es bleibt dabei, dass es viele viele Admins gibt, die einfach und unkompliziert mal eben ein Snippet einfügen wollen und ich denke das ist eher die Regel und nicht die Ausnahme. Diesen Admins nun zu sagen "Das Template ist tabu für euch!" wird nicht funktionieren. Es war schon schwer genug den Leuten klar zu machen, dass man nicht in den css files rumeditiert und das man für Templateänderungen doch bitte den ACP Templateeditor verwenden soll. Auch musste man besonders beim WBB 3.0 einer nicht gerade kleinen Anzahl an Leuten klipp und klar machen, dass PHP Hacks tabu sind!

Wie ich ausgeführt habe ist in den meisten Fällen die Lösung mit dem Pseudoelement gar nicht notwendig da Snippets meist schon XML-kompatibel sind. Es ist außerdem möglich dass das WCF versucht das Problem selbst zu lösen, wird beispielsweise ein <img> oder <br> ohne abschließendes / eingefügt, fügt das WCF dies hinzu. Wenn dies nicht funktioniert kann der eingefügte Code vollautomatisch mit <wcf:html><![CDATA[...]]></wcf:html> umschlossen werden. Technisch stellt das kein größeres Problem dar, in diesem Fall sollte dem Administrator natürlich eine entsprechender Hinweis ausgegeben werden, der ihn darüber aufklärt, was verändert wurde und warum. Damit wären wir dann endgültig an einem Punkt bei dem im schlimmsten Fall noch 1 von 1.000.000 Fällen Probleme verursachen.

Quoted from "Hawkes"

Uff... so wäre der Linuxkernel nie entwickelt worden

Naja, mit dem Unterschied dass hinter dem WCF ein Unternehmen steht dessen Wort Gesetz ist. Beim Kernel sieht das etwas anders aus, da werden Lösungen gesucht mit denen alle zufrieden sind. Aktuelles Beispiel sind da die WLAN-Treiber von Broadcom...

Quoted from "Hawkes"

Ich finde die Idee mit dem xPath-Parser nicht schlecht und verfolgenswert. Ich beginne momentan ein neues Semester, daher habe ich momentan nicht die Zeit an einer Draft-Implementation mitzuwirken, ansonsten würde ich dir das jetzt anbieten, ob man das einfach mal konzeptionieren, implementieren und testen will.

dito

Ein kleiner Einwurf zu einem etwas älteren Thema: Aspektorientierte Programmierung (AOP).

Das FLOW3-Framework, die Basis für zukünftige TYPO3-Versionen, zeigt, wie man aspektorientierte Programmierung in PHP realisiert - und das ohne native Implementierung und dennoch auf eine elegante Art und Weise. TYPO3 ist zwar momentan nur ein indirekter Konkurrent für WoltLab, insbesondere die Bestrebungen weitere Endanwendungen neben dem WBB auf dem Markt zu platzieren, werden TYPO3 zu einem direkten Konkurrenten machen. Demzufolge sollte man diese Entwicklungen nicht vollständig ausblenden. Wie AOP in FLOW3 angewendet wird kann man in der Dokumentation nachlesen: FLOW3 - Aspect-Oriented Programming

Wie ich darauf komme? Heise berichtet gerade darüber dass die finale Version erschienen ist.

Cool, basteln wir lustig mit der Reflection-API + RegEx zur Laufzeit an den Klassen rum. Ich will nicht wissen, wie sich das auf die Performance auswirkt…

Mal weitergedacht: Bedeutet das dann für Forenbetreiber die nicht die Standardtemplates nutzen, dass sie quasi nur die passenden „Platzhalter“ in ihre eigenen Templates einfügen müssen und sämtliche Plugins sind damit auch funktionsfähig? Momentan muss man ja die Plugins entpacken, die vorgenommenen Templateänderungen heraussuchen und manuell durchführen. Das gleiche gilt natürlich auch für Abschnitte der Standardtemplates die von mehr als einem Plugin gepatched werden.

Quoted from "Geronimo"

Mal weitergedacht: Bedeutet das dann für Forenbetreiber die nicht die Standardtemplates nutzen, dass sie quasi nur die passenden „Platzhalter“ in ihre eigenen Templates einfügen müssen und sämtliche Plugins sind damit auch funktionsfähig? Momentan muss man ja die Plugins entpacken, die vorgenommenen Templateänderungen heraussuchen und manuell durchführen. Das gleiche gilt natürlich auch für Abschnitte der Standardtemplates die von mehr als einem Plugin gepatched werden.

Das ist doch bereits jetzt so? Wenn ein Plugin einen Platzhalter benutzt, so funktioniert dieses Plugin auch in deinen eigenen Templates, wenn du den Platzhalter dort wieder eingebaut hast. Die Platzhalter verschwinden nun halt und an ihre Stelle treten die Template-Events. Die Templatepatches fallen komplett weg, und somit brauchst du dich auch nicht weiter drum kümmern, irgendwelche Patches in eigene Templates einzubauen - die gibts einfach nicht mehr.

Nur damit ich das richtig verstehe: Mal angenommen eine Erweiterung benötigt eine zusätzliche CSS-Klasse für beispielweise das Element body. Dann bin ich darauf angewiesen, dass da schon mal jemand einen entsprechenden Platzhalter hinterlegt hat, und kann nicht wie bisher eine eigene Änderung vornehmen?

Das ist korrekt, aber das ist auch ein gutes Beispiel für eine Änderung, die man sehr einfach per jQuery machen kann.

Vieleicht versteh ichs ja falsch aber ist es nicht so das JQuery auf Javascript basiert?
Und heist das nicht im Umkehrschluss das wenn man JS Deaktiviert hat, Änderungen nicht sehen kann?

Das ist richtig. WCF 2.0 / Burning Board Dragon wird für die meisten Funktionen Javascript zwingend benötigen, um eine komfortable und zeitgemäße Bedienung zu ermöglichen. Lediglich die "Grundfunktionen" des Forums wie z.B. Themen lesen / schreiben werden weiterhin ohne Javascript funktionieren.

Wird der CK-Editor auch im ACP zu Verfügung stehen?

Der CKEditor ist in einem eigenen Paket gekappselt und kann dementsprechend auch im ACP eingebunden werden.

Gibt es noch mehr Screenshots von Burning Board 4, außer die vom Woltcafe?