nicht angemeldet
Gunnar Bittersmann
Matthias Apsel
Felix Riesterer
Felix Riesterer
Matthias Apsel
Gunnar Bittersmann
Matthias Apsel
Siehe Screenschutt. Der Text für die Beschreibung liegt vertikal mittig, aber da wo noch Text eingegeben werden soll, ist der Cursor links oben (RefUrl). Wie kriege ich den Cursor vertikal zentriert? CSS Style vertical-align:middle hat keinen Effekt auf den Cursor.
Bitte mal um Hinweise, Danke im Vorab.
@@pl
Bist du nicht schon viel zu lange hier um nicht zu wissen, dass ein Online-Beispiel/Quelltext mehr sagt als tausend Bilder?
LLAP 🖖
Conenteditable ist in vieler Hinsicht so ein Ding für sich... Füg mal Inhalt ein und lösche ihn danach wieder, dann passt es. Wenn Du das danach mittels Dom-Inpektor betrachtest, siehst Du, dann ein "<br>" entstanden ist. Das solltest Du forcieren können, indem Du das <br> für leere Felder vorfüllst.
Das ist nur ein Beispiel für das Eigenleben von Conenteditable... würde ich nicht ohne dringende Notwendigkeit mit anfangen...
Füg mal Inhalt ein und lösche ihn danach wieder, dann passt es. Wenn Du das danach mittels Dom-Inpektor betrachtest, siehst Du, dann ein "<br>" entstanden ist.
Wow, den ersten Schritt tat ich gerade 😉
Gute Idee, mach ich, danke!! @Matthias Apsel auch danke.
Gute Idee, mach ich, danke!!
Gern... um Dir einen weiteren Vorgeschmack des Dir bevorstehenden "Leids" zu geben: füg mal was aus der Zwischenablage ein, was Du Dir von einer anderen Webseite oder z.B. einem Worddokument geholt hast...
Die Seite ist ein Backend, nur für mich. Daher habe ich auch den Passwortschutz wieder aktiviert. Contenteditable ist tatsächlich "ein Thema für sich", aber für dieses Backend bietet es sich an, auch weil die Inhalte tabellarisch darstellbar sind -- so wird direkt in der Zelle editiert. Zum Speichern werden die Text-Inhalte der entsprechenden Zellen direkt aus dem DOM eingesammelt, zu Objekten gebündelt, die Objekte serialisiert und per AJAX gesendet ohne danach die Seite neu zu laden.
MfG
Hallo pl,
Schreib ein Leerzeichen in die td-Elemente.
Besser noch: Platzhaltertexte, dass deine Nutzer auch sehen, dass da was bearbeitet werden kann.
Bis demnächst
Matthias
Lieber pl,
selbst mit contentEditbale zu hantieren ist wirklich eine sehr leidvolle Sache. Daher hat es einen Sinn, auf eine fertige Lösung wie z.B. den TinyMCE zu setzen. Solche WYSIWYG-Editoren kann man nach Herzenslust konfigurieren und ist das Leid mit dem erzeugten HTML-Code los.
Liebe Grüße,
Felix Riesterer.
Wie würdest Du denn dieses Backend machen? Gucks Dir bitte mal an, Vorschläge willkommen 😉
Lieber pl,
Wie würdest Du denn dieses Backend machen?
keine Ahnung! ;-)
Meines Wissens haben Browser eine Obergrenze an Datenfeldern, die sie übertragen (irgendwas um die 1000 name-value-Paare). Daher kann ich jetzt nicht abschätzen, ob Deine Riesentabelle eine sinnvolle Lösung ist. Ich habe auch nicht hinter die Kulissen geschaut, ob da nur die jeweilige Zeile via AJAX im Hintergrund übertragen wird...
Was die jeweiligen Felder angeht, so bietet sich dafür der inline Mode des TinyMCE an.
BTW: Ich mag Deinen Menüpunkt "Demo's" nicht, weil Deppenapostroph.
Liebe Grüße,
Felix Riesterer.
Hallo Felix Riesterer,
Meines Wissens haben Browser eine Obergrenze an Datenfeldern, die sie übertragen (irgendwas um die 1000 name-value-Paare).
Ja, haben sie. Deshalb musste ich in einer umfangreichen Anwendung per JS name-Attribute entfernen.
Bis demnächst
Matthias
@@Felix Riesterer
BTW: Ich mag Deinen Menüpunkt "Demo's" nicht, weil Deppenapostroph.
Wenn’s denn ein Apostroph wäre. 😉
LLAP 🖖
Ich habe auch nicht hinter die Kulissen geschaut, ob da nur die jeweilige Zeile via AJAX im Hintergrund übertragen wird…
Über das Array mit den Namen der Bilder werden die Zellen ausgelesen:
Auge var eav = {};
for(var i = 0; i < IMGNAMES.length; i++){
eav[IMGNAMES[i]] = {};
eav[IMGNAMES[i]]['img_title'] = $(document.getElementById(IMGNAMES[i]+'img_title')).text();
eav[IMGNAMES[i]]['img_alt'] = $(document.getElementById(IMGNAMES[i]+'img_alt')).text();
eav[IMGNAMES[i]]['img_descr'] = $(document.getElementById(IMGNAMES[i]+'img_descr')).text();
eav[IMGNAMES[i]]['ref_url'] = $(document.getElementById(IMGNAMES[i]+'ref_url')).text();
eav[IMGNAMES[i]]['mark4del'] = document.getElementById(IMGNAMES[i]+'mark4del').checked == true ? 1 : 0;
}
// Schlüsselparameter hinzu
eav.param = {speichern:1};
Das Ergebnis ist eine Datenstruktur nach dem Muster Entity-Attribute-Value, das wird serialisiert und per POST/Ajax gesendet. Damit gehen bei jedem Speicher-Request alle Daten ab zum Server, also nicht nur ein einzelner Eintrag. Serverseitig gibts im entsprechenden Bilderverzeichnis eine Index-Datei mit diesen Daten. Bestimmte Anwendungen greifen auf diese Datei zu, ansonsten ist dieses Backend recht nützlich fürs Management von Bildern.
Meines Wissens haben Browser eine Obergrenze an Datenfeldern, die sie übertragen (irgendwas um die 1000 name-value-Paare).
Wusste ich noch nicht, danke für den Hinweis. Aber mal ehrlich, wer solche Formulare baut, macht irgendwas falsch, insbesondere hinsichtlich UX 😉
Daher kann ich jetzt nicht abschätzen, ob Deine Riesentabelle eine sinnvolle Lösung ist.
Ich habe mehrere Verzeichnisse wo Bilder zu indizieren sind. Da die Anzahl der Bilder unterschiedlich sind, haben natürlich auch die Tabellen der Backends unterschliedliche Größen. Jedoch ist nicht die Größe der Tabelle ausschlaggebend fürs Design dieser speziellen Anwendung. Auf jeden Fall ergibt sich beim Editieren ein zügiges Arbeiten, wenn die Daten per Ajax gesendet werden und dafür brauchts kein Formular -- wo ich nach jedem Speichervorgang auf ein Reload warten müsste.
MfG
Hallo pl,
Wusste ich noch nicht, danke für den Hinweis. Aber mal ehrlich, wer solche Formulare baut, macht irgendwas falsch, insbesondere hinsichtlich UX 😉
Nicht zwagsläufig. Bei mir handelt es sich um eine Tabelle, die abbildet, welche Schüler einer Klasse, welche Aufgaben wie bewältigt haben.
Macht bei 20 Schülern und 40 Aufgaben (1 Lerneinheit über ca. 4 Wochen) 800 Felder. Für jedes Feld gibt es 2 Checkboxen, 3 hidden-inputs, 1 Radiogruppe sowie eine textarea. In einem der hidden-inputs steht, ob dieses Feld verändert wurde.
Es ist klug, nur die veränderten zu übertragen.
Bis demnächst
Matthias
Es ist klug, nur die veränderten zu übertragen.
Im ersten Gedankengang: ja. In Wirklichkeit jedoch ist das ein Trugschluss, weil hierzu ohnehin JavaScript eingesetzt werden muss was auch einen gewissen Aufwand bedeutet. Mit demselben oder gar geringeren Aufwand kannste da auch alles zusammen zum Server schicken und serverseitig einfach ein bedingungsloses Update machen. Bedingungslos heißt, dass nichts geprüft wird, außer dass ggf. bestimmte Bytesequenzen freilich rausgefiltert oder maskiert werden müssen damit sie keinen Schaden anrichten.
Und wenn ohnehin JavaScript zum Einsatz kommt, kann über "application/x-www-form-urlencoded" hinausgehend auch ein anderer Enctype (Content-Type) frei gewählt werden, ein solcher nämlich bei dem es hinsichtlich der Daten und -Struktur keinerlei Einschränkungen und auch keinen Performanceeinbruch gibt.
MfG
Hallo pl,
Es ist klug, nur die veränderten zu übertragen.
Im ersten Gedankengang: ja. In Wirklichkeit jedoch ist das ein Trugschluss, weil hierzu ohnehin JavaScript eingesetzt werden muss was auch einen gewissen Aufwand bedeutet. Mit demselben oder gar geringeren Aufwand kannste da auch alles zusammen zum Server schicken
Leider nein, weil eben nicht alle name-value-Paare übermittelt werden. Und wenn man zudem noch in weißen Flecken wohnt (nicht schläft 😂) geht das erst recht nicht.
Bis demnächst
Matthias
Mit demselben oder gar geringeren Aufwand kannste da auch alles zusammen zum Server schicken
Leider nein, weil eben nicht alle name-value-Paare übermittelt werden.
Leider hast Du überhaupt nicht verstanden was ich schrieb. Also Beispiel, mein Code:
// EAV zusammenbauen und senden per AJAX
function speichern(){
throbber(true);
var eav = {};
for(var i = 0; i < IMGNAMES.length; i++){
eav[IMGNAMES[i]] = {
img_title : $(document.getElementById(IMGNAMES[i]+'img_title')).text(),
img_alt : $(document.getElementById(IMGNAMES[i]+'img_alt')).text(),
img_descr : $(document.getElementById(IMGNAMES[i]+'img_descr')).html(),
ref_url : $(document.getElementById(IMGNAMES[i]+'ref_url')).text(),
mark4del : document.getElementById(IMGNAMES[i]+'mark4del').checked == true ? 1 : 0
};
}
// Schlüsselparameter hinzufügen
eav.param = {speichern:1};
var xhr = new XMLHttpRequest();
xhr.open('PUT','%url%');
xhr.setRequestHeader('Content-Type', 'multipart/c-eav');
xhr.onload = function(){
throbber(false);
if(xhr.status != 200) return pretext(xhr.response);
//location.reload();
}
xhr.send( cEAV.encode_eav(eav) );
}
Sendet alles zusammen wobei es egal ist, wieviele Einträge das Array mit den Bildernamen hat und wieviele Attribute je Bild vergeben werden. Bei 150 Bildern ergeben sich etwa 15 kbyte (Content-Length) an Daten je Speichern-Request und selbst bei einer zigfachen Datenmenge würde ich mich darauf verlassen können, dass stets alles am Server ankommt, wann immer ich auf den Knopf 'Speichern' drücke.
Ich habe zwar hier einen proprietären Serializer/Enctype aber dass das auch mit JSON (wenn auch langsamer) funktioniert davon bin ich überzeugt.
MfG
Ich habe zwar hier einen proprietären Serializer/Enctype aber dass das auch mit JSON (wenn auch langsamer) funktioniert davon bin ich überzeugt.
Ein Beweis der These "JSON wäre langsamer" würde mich sehr interessieren, immerhin versuchst Du, gegen eine native Browserimplementation anzustinken! Selbst wenn dem wirklich so sein sollte: welche immense Datenmengen musst Du generieren, um einen messbaren(!) Unterschied zu erhalten?
Ich habe zwar hier einen proprietären Serializer/Enctype aber dass das auch mit JSON (wenn auch langsamer) funktioniert davon bin ich überzeugt. Ein Beweis der These "JSON wäre langsamer" würde mich sehr interessieren[...]
Wenn ich mir folgendes auf Deiner Seite anschaue:
encode_eav: function(eav){
var s = new String();
var trip = new Array();
for(var ent in eav){
for(var att in eav[ent]){
var val = eav[ent][att] ? new String(eav[ent][att]) : new String('');
val = val.replace(/%/g, '%25');
val = val.replace(/;/g, '%3B');
val = val.replace(/\=/g, '%3D');
trip.push(ent+'='+att+'='+val);
}
}
return trip.join(";");
},
möchte ich bereits ohne Messung gegen Deine These wetten, das kann keine Chance gegen ein nativ im Browser implementiertes "JSON.stringify" haben.
möchte ich bereits ohne Messung gegen Deine These wetten, das kann keine Chance gegen ein nativ im Browser implementiertes "JSON.stringify" haben.
Bestätigt, folgendes auf Deiner Startseite gerade im Firefox ausgeführt:
var testData = {};
for (var i=0; i <= 50000; i++) {
testData[i] = i + 'xyz';
}
console.log(testData.length);
console.time('timer');
var none = JSON.stringify(testData)
console.timeEnd('timer');
console.time('timer');
var none = cEAV.encode_eav(testData)
console.timeEnd('timer');
Ergebnis bei mir:
"JSON.stringify(testData)" schwankt so zwischen 10 und 20 Millisekunden
"cEAV.encode_eav(testData)" schwankt so zwischen 3000 und 3200 Millisekunden
Werte im Chrome:
"JSON.stringify(testData)": 30 - 40 Millisekunden
"cEAV.encode_eav(testData)" 740 - 780 Millisekunden
Das mag schon sein. Aber wie bereits festgestellt, betrachte bitteschön den gesamten Vorgang, also serialize und deserialize zusammen. Genauso wird nämlich ein Benchmark gemacht und wenn ich mit einem Benchmark einmal festgestellt habe, dass es Performanceunterschiede gibt, dann darf ich mich auch auf solch ein Ergebnis verlassen.
Selbstverständlich darfst Du mein Ergebnis anzweifeln, dann aber bitte begründe das so wie es eines Entwicklers würdig ist!
gegen eine native Browserimplementation anzustinken Nein Herr Kollege, damit bist Du total daneben. So kommuniziert man nur hier in diesem Forum.
Schönen Tag auch.
Hallo pl,
Selbstverständlich darfst Du mein Ergebnis anzweifeln, dann aber bitte begründe das so wie es eines Entwicklers würdig ist!
Das hat er. Der einzige, der sich hier herauslawienert, bist du, anstatt mal einen Benchmark inklusive Sourcecode zu liefern. Du wurdest ganz konkret um Informationen gebeten und zumindest teilweise widerlegt. It's your turn. Liefere Benchmarks mit entsprechendem Sourcecode.
LG,
CK
Hallo
Das mag schon sein. Aber wie bereits festgestellt, betrachte bitteschön den gesamten Vorgang, also serialize und deserialize zusammen.
Der „gesamte Vorgang“ kann hier nicht betrachtet werden, weil du wie üblich den Code, der dazu notwendig wäre, nicht bereitstellst.
Genauso wird nämlich ein Benchmark gemacht und wenn ich mit einem Benchmark einmal festgestellt habe, dass es Performanceunterschiede gibt, dann darf ich mich auch auf solch ein Ergebnis verlassen.
Wie üblich, stellst du bloße Behauptungen auf und lieferst wie üblich keinen Beweis.
Selbstverständlich darfst Du mein Ergebnis anzweifeln, dann aber bitte begründe das so wie es eines Entwicklers würdig ist!
Deine unbewiesenen Behauptungen sind es, die eines Entwicklers unwürdig sind.
Tschö, Auge
Das mag schon sein. Aber wie bereits festgestellt, betrachte bitteschön den gesamten Vorgang, also serialize und deserialize zusammen.
Selbst wenn man JSON.parse noch in den Benchmark aufnimmt, ist das noch ca. 34 mal schneller als dein Serializer alleine. Schlimm daran ist einzig und alleine, dass du immer noch am Gegenteil festhälst.
Selbst wenn man
JSON.parsenoch in den Benchmark aufnimmt, ist das noch ca. 34 mal schneller als dein Serializer alleine. Schlimm daran ist einzig und alleine, dass du immer noch am Gegenteil festhälst.
Da möchte ich pl jetzt mal in Schutz nehmen. Seine Aussage "Das mag schon sein" kann man durchaus als (verhaltene) Bestätigung ansehen, dass seine Lösung im Client unterlegen ist. Letzter Stand ist, dass er sich auf einen Performancevorteil seiner serverseitigen Deserialisierung bezieht. Das können wir nur leider nicht nachprüfen, solange er den Code dazu nicht liefert. Zweifel an der These sind aber angebracht.
Letzter Stand ist, dass er sich auf einen Performancevorteil seiner serverseitigen Deserialisierung bezieht.
Das hab ich schon mitbekommen, aber für den Endnutzer bedeutet das doch trotzdem längere Wartezeit und mehr Akkubedarf. Im Übrigen ist Pls Format auf den Testdaten deines Benchmarks noch drei bis vier mal so speicherintensiv wie JSON. Also leidet auch das Datenvolumen noch.
var testData = {};
for (var i=0; i <= 50000; i++) {
testData[i] = i + 'xyz';
}
var encoder = new TextEncoder('utf-8')
var none = JSON.stringify(testData)
console.log(encoder.encode(none).length / (1024 * 1024))
var none = cEAV.encode_eav(testData)
console.log(encoder.encode(none).length / (1024 * 1024))
0.8848190307617188
3.636998176574707
Ein Beweis der These "JSON wäre langsamer" würde mich sehr interessieren, immerhin versuchst Du, gegen eine native Browserimplementation anzustinken!
Du stänkerst. Betrachte bitteschön auch die De-Serialisierung serverseitig, genau da liegt nämlich der Performanceunterschied.
Tach!
Ein Beweis der These "JSON wäre langsamer" würde mich sehr interessieren, immerhin versuchst Du, gegen eine native Browserimplementation anzustinken!
Du stänkerst. Betrachte bitteschön auch die De-Serialisierung serverseitig, genau da liegt nämlich der Performanceunterschied.
Und du drückst dich mal wieder um die Beantwortung der gestellten Fragen. Diese Antwort ist immer noch eine Behauptung ohne Beweis. Aber:
Selbst wenn dem wirklich so sein sollte: welche immense Datenmengen musst Du generieren, um einen messbaren(!) Unterschied zu erhalten?
dedlfix.
Ein Beweis der These "JSON wäre langsamer" würde mich sehr interessieren, immerhin versuchst Du, gegen eine native Browserimplementation anzustinken! Du stänkerst.
Moment! Immerhin habe ich zunächst einmal bewiesen, dass JSON im Client dramatisch schneller ist, als Deine Implementation. Es gibt noch weitere Gründe, JSON den Vorzug zu geben, aber die lassen wir an der Stelle mal beseite. Wir bleiben rein bei der Performance...
Betrachte bitteschön auch die De-Serialisierung serverseitig, genau da liegt nämlich der Performanceunterschied.
OK! Im Gegensatz zum JavaScript kann ich hier leider keine Messung vornehmen, außer Du stellst den fraglichen Code zur Verfügung?!
Unterstellen wir mal, Du hast Recht und Deine Implementatin ist schneller: auch dann gilt die Eingangsfrage, welch immense Daten Du deserialiseren musst, um einen messbaren Unterschied zu erhalten.
Ohne Deinen Code zu kennen, habe ich aber auch serverseitig so meine Zweifel, ob Deine Implementation wirklich schneller sein soll, als JSON. Wenn wir von einer gewöhnlichen Perl-Installation ausgehen, dann wird intern ein C-Kompilat(JSON::XS) verwendet. Es fällt mir schwer zu glauben, dass Dein Perl-Code dagegen anstinken kann.
Wenn ich damit falsch liegen sollte, freue ich mich auf Deine nachvollziehbare Beweisführung.
OK! Im Gegensatz zum JavaScript kann ich hier leider keine Messung vornehmen, außer Du stellst den fraglichen Code zur Verfügung?!
Pump
Gib mir doch einfach nur Deinen serverseitigen Part von "decode_eav", das werden vermutlich nur wenige Zeilen Perl sein, oder?
Den Benchmark übernehme ich dann! Deal?