brainstorming: dashboard template UI mit jquery + x

[Timbalu]

Ich muss dieses alte Jahr noch einmal darauf zurückkommen. Eine Antwort darf ruhig bis ins nächste Jahr dauern...

Du kannst im frontend_configure event hook durchaus $serendipity['templatePath'] oder $serendipity['template'] umbiegen...

Das ist insofern gut machbar, gilt aber unter bestimmten Umständen (zb wenn ich aus einem modalem Container eine Folgeseite abrufe) bei bestimmten Dateien nicht, die über serendipity_getTemplateFile laufen (zb admin/entries.tpl und admin/media_upload.tpl).

3. Warum werden die textarea serendipityPrettyButton input_buttons für bbc-code und media library serendipity_admin_image_selector.php window.open, so a la:

Code: Select all

<script type="text/javascript" language="JavaScript">document.write('<input class="serendipityPrettyButton input_button" type="button" ...

in der admin entries.tpl, sowie im entryproperties plugin und anderen, grundsätzlich mit javascript document.write() hergestellt? Ist das unbedingt nötig? Und wenn ja warum genau?

Das ist, damit nur bei Browsern mit Javascript diese Buttons ausgegeben werden. Dient also dazu bei deaktiviertem Javascript auch nur die Buttons zu sehen die auch funktionieren...

Ansonsten denke ich könnte man um das document.write auch herumkommen indem man den Code so ändert dass man ein leeres HTML-DIV erstellt und im javascript darauf per "document.getElementById('blabla').innerHTML += 'xxx' zugreift und das so reinschreibt. Ob das allerdings in das modale dialogkonzept reinpasst weiß ich auswendig nicht; ich denke das wird nicht so trivial sein das in beiden Kontexten mit einem Code abzubilden...

Die Benutzung von innerHTML ist ziemlich auszuschließen, da es m.W. javascript herausrechnet und nur der Standard HTML DOM-Spezifikation folgt.
Ich habe für den BBCode auch schon eine nicht allzu aufgeblähte Lösung mit nativem Javascript gefunden, die vollständig auf document.write verzichtet. Allerdings - bevor ich das dann hochlade - wüßte ich gerne, warum eigentlich in der admin/entries.tpl der BBCode der normalen body toolbar mit document write geschrieben während der BBC der extended_body toolbar in reinem Html geschrieben wird. Ich sehe den Unterschied nicht! Ist das damals möglichweise einfach vergessen worden?
https://github.com/s9y/Serendipity/blob ... es.tpl#L90
https://github.com/s9y/Serendipity/blob ... s.tpl#L159
Wenn dem so ist, wäre ja die Frage ob man das heutzutage in 1.7 und up nicht gänzlichst lässt oder aber konsequent nutzt?

[garvinhicking]

Hi!

(Wo ich hier gerade schreibe und im Forum ein paar Artikel aufgeholt habe - toll wie Du dich hier für Fragen von anderen einsetzt und denen hilfst, das freut mich riesig)

Das ist insofern gut machbar, gilt aber unter bestimmten Umständen (zb wenn ich aus einem modalem Container eine Folgeseite abrufe) bei bestimmten Dateien nicht, die über serendipity_getTemplateFile laufen (zb admin/entries.tpl und admin/media_upload.tpl).

Hast Du konkrete Beispiele, was möchtest Du wo erreichen?

Ich habe für den BBCode auch schon eine nicht allzu aufgeblähte Lösung mit nativem Javascript gefunden, die vollständig auf document.write verzichtet. Allerdings - bevor ich das dann hochlade - wüßte ich gerne, warum eigentlich in der admin/entries.tpl der BBCode der normalen body toolbar mit document write geschrieben während der BBC der extended_body toolbar in reinem Html geschrieben wird. Ich sehe den Unterschied nicht! Ist das damals möglichweise einfach vergessen worden?
https://github.com/s9y/Serendipity/blob ... es.tpl#L90
https://github.com/s9y/Serendipity/blob ... s.tpl#L159
Wenn dem so ist, wäre ja die Frage ob man das heutzutage in 1.7 und up nicht gänzlichst lässt oder aber konsequent nutzt?

Öh, gute Frage. Ich meine das war mal gleich, hattest Du oder Mattsches oder YellowLED da nicht schon gepatcht und das an einer Stelle ohne document.write gelöst, aber dann einfach nur nicht für die andere Stelle übertragen?

ansonsten steht document.write dort ja eigentlich nur, dass die Buttons nicht erscheinen, wenn jemand kein javascript hat. D.h. hier würde eigentlich auch einfach ausreichen wenn irgendein jquery code dafür sorgt, ein standmäßig per "display:none" ausgeblendetes set einzublenden, wenn JS zur Verfügung steht.

Grüße und ein frohes neues Jahr,
Garvin

[Timbalu]

Hast Du konkrete Beispiele, was möchtest Du wo erreichen?

Ja - allerdings muss ich das noch etwas genauer untersuchen, bevor ich damit fortfahren kann... (Es geht dabei um ajax requests, die meine funktionierende Umleitung auch in non-reloads des Dashboards durchlaufen werden muss. Ich werde das dann nochmal genauer erklären, wenn ich zweifelsfrei fragen kann.)

Öh, gute Frage. Ich meine das war mal gleich, hattest Du oder Mattsches oder YellowLED da nicht schon gepatcht und das an einer Stelle ohne document.write gelöst, aber dann einfach nur nicht für die andere Stelle übertragen?

Ja, das hatte ich. Aber das waren meist normale document.writes und nicht der speczielle für den BBC. Die entries.tpl von vor 6 Jahren zeigt denselben Unterschied:
https://github.com/s9y/Serendipity/blob ... ntries.tpl

ansonsten steht document.write dort ja eigentlich nur, dass die Buttons nicht erscheinen, wenn jemand kein javascript hat. D.h. hier würde eigentlich auch einfach ausreichen wenn irgendein jquery code dafür sorgt, ein standmäßig per "display:none" ausgeblendetes set einzublenden, wenn JS zur Verfügung steht.

Grüße und ein frohes neues Jahr,

Danke & Dito!
Wenn das so einfach ist, warum wurde das dann nicht auch so gemacht? Es wäre ein Einzeiler gewesen! Siehe mein Beispiel aus staticpages:

Code: Select all

<nobr><noscript><span name="jsOnly" style="display: none;"></noscript>..<input bbc buttons>..<noscript></span></noscript></nobr>

Außerdem erklärt das noch nicht warum wir das im Backend für body, aber nicht für extended body ha(b/tt)en. Wenn das bis heute noch keine negativen Auswirkungen hatte (und ich kann mich an keinen diesbezüglichen Forenbeitrag erinnern), so ist wirklich die Frage ob es überhaupt benötigt wird.

[garvinhicking]

Hi!

Wenn das so einfach ist, warum wurde das dann nicht auch so gemacht? Es wäre ein Einzeiler gewesen! Siehe mein Beispiel aus staticpages:

Code: Select all

<nobr><noscript><span name="jsOnly" style="display: none;"></noscript>..<input bbc buttons>..<noscript></span></noscript></nobr>

Außerdem erklärt das noch nicht warum wir das im Backend für body, aber nicht für extended body ha(b/tt)en. Wenn das bis heute noch keine negativen Auswirkungen hatte (und ich kann mich an keinen diesbezüglichen Forenbeitrag erinnern), so ist wirklich die Frage ob es überhaupt benötigt wird.

Nun, "damals" vor 12 Jahren hat man das nunmal anders gemacht als heute.

Die von Dir genannte Form geht so nicht, das ist ungültig geschachteltes HTML!

Grundsätzlich fände ich es schon gut, dass das s9y backend so gracefully wie möglich degradiert, d.h. Funktionen die nur mit javascript klappen sollten auch nur dann sichtbar sein, wenn javascript ausgeführt wird.

Grüße,
Garvin

[Timbalu]

Wie die Zeit doch vergeht....
Ups, an "valide" hatte ich gar nicht gedacht, als ich diese Konstruktion erfand; sie war aber die einzige javascript-und-css-freie kreative Konstruktion, die gleichzeitig minimalinvasiv als auch funktionierte! Ist das 'unvalid' wirklich so? Ich habe das in Chrome und FF ohne Fehlermeldung (auch im Quelltext) getestet. In den Spezifikationen habe ich auch keinen Zwang gefunden, der einen solch 'kreativen' Umgang mit dem tag untersagte. Wieweit spielt denn ein mögliches 'unvalid' im Backend wirklich eine Rolle? (Das <nobr> war schon vorher dabei - und der span Bruch wird ja mit der Beendigung im zweiten noscript wieder valide gemacht. Im Grunde macht man ja mit JavaScript oft auch ähnliche Sachen, die der Reihe nach abgearbeitet werden, so wie es auch hier der Fall ist.)
. . .
Dann müsste ich es doch mit meiner nativen Lösung oder eben mit dem JS+'display:none' machen. Allerdings, und dann ein letztes Mal nachgefragt (und das war der eigentliche Kern meiner Frage), soll das nun auch für den extended body part in der entries.tpl geschehen oder gibt es da doch Unterschiede, die ein unterschiedliches Vorgehen rechtfertigen (und die ich bisher einfach nicht sehe).

[garvinhicking]

Hi!

Also es ist halt einfach nicht HTML-konform, udn ich fände es keine guten Stil wenn das bei uns Einzug hält - selbst wenn es derzeit funktioniert. Ob das aber in Zukunft Browser verschlucken oder nicht anzeigen kann man ja nicht wissen; wir halten uns dann aber nicht mehr an einen Standard, den es ja auch mit gutem Grund gibt.

Ich denke man kann hier durchaus auf die JS-Lösung zurückgreifen; per HTML/CSS etwas auf display:none setzen dass nur mit JS geht, und dann über einen JS-Event diese Teile wieder aktivieren.

Ich denke es war nur eine Nachlässigkeit dass das eanders gehandhabt wurde für body/extended; ich denke man könnte das hier schon gleichsam lösen müssen können...

Grüße,
Garvin

[Timbalu]

Jupp OK.
Ich komme mit den verschiedenen Backends auch schon langsam etwas durcheinander... denn im (alten) default file ist es ja auch tatsächlich schon so gelöst, dass der extended_body über toggle_extended() per js/css zugeschaltet wird. Ich bau dann mal lieber etwas ähnliches für das body Feld, dann kann man auf das document.write Ersatz-JS-Geraffel fast ganz verzichten.

[Timbalu]

Hi Garvin

Nach langem Suchen habe ich nun die Ursache für eines meiner restlichen Probleme gefunden.
Die Nutzung der Funktion addLoadEvent(...) in Serendipity für das Drag&Drop funktioniert nicht in meinen nachgeladenen modal container. Ich stehe also vor dem Problem, die Nutzung von addLoadEvent - hier am Beispiel von addLoadEvent(pluginMoverInitEvent) - folgendermaßen auszutauschen, damit es beidseitig (mit und ohne Dashboard) funktionieren kann. Dies ist die einzige Variante, mit der ich ein plain master und auch die Dashboard Nutzung zum Laufen brachte:

Code: Select all

if (window.jQuery) { jQuery(function ($) { pluginMoverInitEvent(); }); } else { addLoadEvent(pluginMoverInitEvent); } 

Die Frage ist nun, ob ich das so in für 1.7 und 2.0 einbauen kann, ob das eventuell besser geht (ohne im core zu fummeln), ob man desweiteren in 2.0 die addLoadEvent Funktion sowieso zugunsten von jQuery austauscht, usw.?

[garvinhicking]

Hi!

Eigentlich sollte man gar keinen ELSE-Fall oder so brauchen, man sollte theoretisch ausschließlich mite

Code: Select all

$(document).ready(function() {
  pluginMoverInitEvent();
});

arbeiten können, oder (wie Du auch sagst)? Ich erinnere mich nur gerade nicht an pluginMoverInitEvent, woher kommt das? Aus dem Core? Wenn es aus nem Plugin kommt sollte natürlich das Plugin eher so eine Ausgabe über eventhooks platzieren, dann gehört der Aufruf dafür auch nicht in den Core...


Bitte eher nicht in der 1.7 einbinden, potentiell könnte das zu große Probleme verursachen.

Grüße,
Garvin

[Timbalu]

Ja das stimmt wohl, allerdings nur leicht abgewandelt...

Code: Select all

jQuery(document).ready(function() { templatePluginMoverInit(); }); 

Damit liefe es sehr wohl in 1.7 und up, da dort jQuery automatisch auch im Backend eingebunden ist.
Im Falle einer Deaktivierung, müsste man aber eher zu erst genannter Lösung greifen, weshalb ich sie hier auch gepostet habe.

Das sind Core Sachen aus functions_plugins_admin für die drag&drop Listen, das addLoadEvent() wird aber auch noch an anderen Stellen verwendet.

Wie genau könnte das mit einem Einbau in 1.7 potentielle Probleme auslösen?

Ich habe auch schon hin und her überlegt, wie ich treffsicher mein ajax data für den container cut so regexen könnte, dass addLoadEvent(functionName); sauber zu functionName(); konvertiert wird, aber es gibt zB leider auch dynamisch generierte functionNames, so dass das im load nicht wirklich funktionierte. Die einzig saubere Lösung schien mir daraufhin, die Vorkommen individuell an der Quelle zu ändern.

Hmmm

[Timbalu]

Hi

Ich habe schon eine Weile nicht mehr am Dashboard für 1.7 (ca RC3) (ca seit Mitte Februar) gearbeitet und wollte nun etwas einarbeiten, als ich merkte, dass unter Firefox (19.0.2) meine Template-Umlenkung nicht mehr funktioniert. Vorher ging alles ohne Probleme!
Das index.tpl wird nicht abgerufen und dafür das alte Backend"frame" (HTML Grundgerüst) dargestellt. Ansonsten werden die Dashboard Dateien alle ordnungsgemäß eingebunden.
D.h., dass die css und js Dateien, die benötigt werden, nicht da sind wo sie sein sollten.

Soweit so gut - ein Fehler - dachte ich mir.... allerdings funktionieren IE und Chrome tadelllos! Ebenso das nicht so stark entfernte Dashboard für und im S9y 2.0. Hier macht auch auch der FF was er soll.

Ich habe schon tausend Sachen durchsucht, cache ausgeschlossen, etc, finde allerdings keinen wirklich plausiblen Grund warum dies so sein sollte. Ich bin daher ziemlich ratlos... und muss daher einfach mal so ins Blaue hineinfragen...

Gibt es irgendetwas was sich mit 1.7 RC~3 (klammheimlich) verändert hat, was darauf einen Einfluss haben könnte???
Gibt es ev. Erfahrungen, dass Veränderungen im FF 19.x darauf irgendeinen Einfluss nehmen können???
Hat irgendwer eine (auch wage) Idee in welche Richtung ich suchen muss???


Edit: Issue solved!
Ich habe mir vor 2 Wochen PHP 5.4.13 installiert... Dort muss irgendetwas in Verbindung mit Firefox und den Sitzungscookies verändert worden sein... denn eine neue RC3 mit derselben Dashboard Version und Firefox läuft tadellos.
Ich habe alle Sitzungscookies gelöscht und mich neu eingeloggt. Daraufhin war der Fehler weg!
Das ist gut, aber immer noch ziemlich rätselhaft, warum das in irgendeiner Weise Auswirkungen auf die Abarbeitung der Template Varaiablen haben konnte...
Ich lasse diese konfuse Fehlermeldung und ihre Lösung hier stehen, falls irgend jemand einmal Ähnliches erlebt...