A world without rules or controls, borders or boundaries.
A world without rules or controls, borders or boundaries.
Englisch: HomePage  |
PmWikiDe /
WYSIWYG
Administratoren
Q: Unterstützt PmWiki irgend eine Art von WYSIWYG? Q: Hat jemand den FCKEditor in PmWiki integriert? 17. Mai 2011: Eine Geldsammlung? ist ins Leben gerufen worden, um die Kosten für die Erstellung von WYSIWYG-Fähigkeiten in PmWiki zu finanzieren. July 2017: Sehen Sie sich das Addon Worse? an und probieren Sie es aus: PMs Antwort: Die kurze Antwort auf die Frage ist, dass WYSIWYG-Bearbeitung in großem Maße die Typen der Anpassungen reduziert, die man anstellen kann, und die Browser einschränkt, auf denen man Änderungen durchführen kann. Als solches tendiert sie dazu, stark gegen die PmWiki-Philosophie #5 zu gehen ("Sei einfach zu installieren, zu konfigurieren und zu pflegen."). Das haupsächliche Problem ist, das Browser beschränkt sind im Umfang, in dem sie WYSIWYG-Änderungen unterstützen können. Zum Beispiel sind die meisten Im-Browser-Editoren wie FCKEditor von Natur aus darauf beschränkt, nur die Markups zu behandeln, für deren Durchführung sie vorprogrammiert worden sind. Darüber hinaus führen diese Editoren ihre Änderungen direkt am HTML-Code aus und nicht an den Markups, die benutzt werden, um den HTML-Code zu produzieren. In anderen Worten, Im-Browser-Editoren benutzen HTML als ihr zugrunde liegendes Speicherformat. Unglücklicherweise bedeutet das, dass Leute mit Browsern, die kein JavaScript behandeln können, nur dann in der Lage sind, die Seiten zu pflegen, wenn sie HTML direkt ansehen und bearbeiten können. Das bedeutet auch, dass es unmöglich ist (oder wenigstens schon aus sich heraus schwierig), Markups zu behandeln, die keine direkte Entsprechung in HTML haben. Eine Annäherung, die versucht wurde (mit wenig Erfolg), ist, dem Browser zu erlauben, den HTML-Quelltext direkt mit WYSIWYG zu ändern und dann anschließend zu versuchen, den HTML-Code wieder zurück zu übertragen auf Wiki-Markup-Code zur Speicherung und für das Bearbeiten mit Browsern ohne WYSIWYG-Fähigkeiten. Unglücklicherweise kann das nur für einen begrenzten Satz von Markups funktionieren und wird zu einem Albtraum, wenn wir Wiki-Administratoren erlauben wollten, eigene Markups zu entwickeln. (Mit anderen Worten, sag Goodbye zu den meisten Kochbuchrezepten.) In der Theorie kann man eine Renderingmaschine in JavaScript schreiben, die on-the-fly Wiki-Markups in HTML übersetzt für die WYSIWYG-Anzeige während der Bearbeitung, aber ich kenne keinen, der das ernsthaft probiert hätte. Noch mal, es kann möglicherweise funktionieren, wenn der vollständige Satz von verfügbaren Markups bekannt ist, aber sowie die Möglichkeit der benutzerdefinierten Markup-Erweiterungen in das System eingeführt ist, wird die Komplexität riesig. Da die lokale Anpassung von Markups eine von PmWikis bedeutenden Stärken ist, schlägt das die Tür zum WYSIWYG-Ändern ziemlich feste zu, es sei denn, wir entscheiden benutzerdefinierte Markups zu verbieten, oder bis die Browsertechnologie so weit gediehen ist, dass es leichter ist, einen erweiterbaren WYSIWYG-Editor im Browser zu haben. AJAX zeigte einige Verheißungen, aber ich denke, dass WYSIWYG immer noch etwas unterhalb von dessen Reichweite ist, es sei denn, die Site hätte eine Menge Bandbreite, um die Renderinganfragen zu behandeln. Ich bin sehr fasziniert davon, was so etwas wie 'Writely' zu tun in der Lage sein könnte, aber ich denke, es ist begrenzt in seinem Potential zu benutzerdefinierten Anpassungen. (Im Übrigen ist es auch keine gute Idee, hier Googles Fähigkeiten zu unterschätzen.) Seit PmWikis Einführung habe ich die grundsätzliche Einstellung eingenommen, dass die Segnungen des WYSIWYG-Bearbeitens, welche anerkennenswert sind, den Verlust an Flexibilität und an Fähigkeiten (wie benutzerdefinierte Markups und andere Punkte), den man hinnehmen müsste, nicht wert sind. Und ich denke, dass die Tatsache, dass andere Web-Editing-Framworks fortfahren, die symbolischen Markups zu nutzen anstelle von WYSIWYG-Editoren, ein guter Indikator dafür ist, wie schwierig diese Aufgabe wirklich ist. OTOH, wenn mir irgend jemand eine Menge Geld bezahlen möchte dafür, dass ich das Problem in Angriff nehme, will ich sehen, was ich tun kann. --Pm? "Be easy to install, configure, and maintain." HTML ist einfach, Wikisyntax ist es nicht. Obwohl es eine vorherrschende Attitüde einiger ist, ist es doch in Wirklichkeit nicht wahr. HTML ist ein riesiger Sprachraum, mit Tonnen von Inkonsistenzen, der über lange Zeit von vielen Leuten entwickelt wurde, die es gut meinten, die aber mehr interessiert waren in ihren eigenen Zielen als daran, etwas "gesundes" herzustellen. Siehe auch PMs Gedanken zu Markup-Auswahl (englisch).
Siehe die Rezepte
Übersetzung von PmWiki.WYSIWYG, Originalseite auf PmWikiDe.WYSIWYG — Backlinks
|