Zunächst müssen wir mal nachfragen damit das Anliegen spezifiziert werden kann: Geht es darum, dass man zB mit dem Snippingtool etwas ausschneidet und dieses Bild dann nicht abspeichern will sondern kopieren und einfügen? Oder ist was anderes gemeint?
Ja schon, die Darstellung im Editor ist einfach, aber in der weiteren Abfolge wird es dann aufwändig. Wir müssen nämlich dann das erzeugte Blob-Element extrahieren (also wieder zu einem Bild machen) und das Grafik-File im Verzeichnis ablegen. Die Blobs wollen wir nicht in der Datenbank haben, sind einfach zu groß für die Menge an Bildern, die zusammenkommt. Muss man sich anschauen wie das umsetzbar ist.
Noch eine Problematik ist zu lösen: Große Screenshots mit einigen MB machen sehr lange Blobs, diese passen gar nicht in das Datenbankfeld für die Einträge. Die Konvertierung auf kleinere Größe geht aber nur mit der Bilddatei, nicht mit dem Blob. Da ist noch viel zu überlegen...
Also ihr habt alles richtig verstanden, will aber keinen Stress machen, würde aber, denke ich, das Leben von uns usern einfacher machen (eures zuerst ja mal nicht). Ganz verstehe ich den Unterschied nicht. tinyMCE macht doch für den blob auch nur einen HTTP-Post, warum kann der server den nicht in ein temporäres file schreiben und dann so weitermachen wie beim upload über den Bild upload jetzt? Bin aber zuwenig 'web-fuzzy' als dass ich da wirklich mitreden könnte.
Eventuell wäre als Zwischenschritt eine Begrenzung der Datengröße akzeptabel, d.h. keine Riesenbilder per clipboard.
Ist schon etwas anders. Upload ist getrennt vom Post fast komplett mit Standardfunktionen gelöst, Upload + Komprimierung + Speichern als Bild auf einem Verzeichnis am Server. Beim Hineinkopieren von einem Bild als Blob sind wir locker auf 15.000 Zeichen pro Bild, wenn jetzt jemand 2 oder 3 Bilder hineinkopiert bringen wir den Post gar nicht im SQL-Datenfeld unter, sodass wir keine Chance haben die Blobs herauszulösen, in Bilder umzuwandeln, diese zu komprimieren und dann in einem Verzeichnis zu speichern.
Es fehlt uns leider derzeit noch ein wenig die Idee zur technischen Umsetzung, da müssen wir noch nachdenken.
Bin ich sicher zu wenig Entwickler und kann mich irren, aber ich hätte es so verstanden, dass beim upload (also wenn das bild per copy / paste) in den editor kopiert wird, dieses mittels seperatem call an den server geschickt wird. Nach dem erfolgreichen speichern hat der editor dann nur noch den link zum bild drinnen. Es kommt also garnicht zu einem riesigen blob. Wahrscheinlich muss dafür aber die upload Funktion vom Forum angepasst werden. Euch wird schon was einfallen :)
Probleme von riesigen Daten verstehe ich nicht... Heute macht man das ja wie folgt a) Das Bild wie groß auch immer am Client bereits runterskalieren und somit die Größe reduzieren. b) das reduzierte Bild hochladen und den Beitrag erstellen.
Ich kann hier kein Problem erkennen was die technische Umsetzung betrifft? Das Bilder nicht in die Datenbank gehören ist e klar.
Runter vom Gas ..., das Ganze muss ja in erster Linie in den tinyMCE passen. Dass man das alles programmieren kann ist schon klar, aber das dann über 17 Versionen vom gesamten framework zu pflegen ist eine völlig andere Geschichte. Seid mir lieb zum energiesparhaus, sie hat die ganze Arbeit
Soda, wir haben die Regenphasen zu Pfingsten genutzt undein bisschen Code geschrieben. Weil es so schön war kommt hier eine Rückmeldung zu den ernsthaften Ideen die wir in diesem Thread erhalten haben und im nächsten Post die aktuelle Umsetzung. Im Livesystem ist es noch nicht aktiv, derzeit haben wir es im Testsystem laufen. Wenn es Live geht dann kommt ein neuer Thread mit der Info von uns.
@taliesin : Wir wollten die TinyMCE-Funktionen lieber nicht nutzen. Hätte wahrscheinlich ein Upgrade auf v5 benötigt (mit entsprechenden Tests), dann ist das ganze mit mit der Schnittstelle zwischen TinyMCE und dem Server (der das ganze weiterverarbeiten soll) auch nicht ohne und schien uns zu aufwändig.
@bloom : Der riesige Blob wird von TinyMCE in eine kurze Adresse übersetzt (diese sieht man wenn man den Code anzeigt), bei der Verarbeitungin Richtung Server muss das ganze natürlich in den Blob umgewandelt werden, siehe oben, uns scheinen die TinyMCE-Funktionen zu riskant und aufwändig.
@Cleudi : Die genannten "x freie Bibliotheken" und "gleich am Client skalieren" gefällt uns gar nicht. Wieder ein Fremdskript einbinden, mit den ganzen Unsicherheiten bezüglich Browserunterstützung (auch in der Zukunft), testen des Ganzen neuen clientseitigen Codes, Ladezeitenerhöhung usw., war für uns so nicht so interessant.
Nächster Post: Wie es gelöst wurde (vielleicht hat ja irgendwer mal eine ähnliche Problemstellung)
@energiesparhaus "gleich am Client skalieren" ist nicht böse, es geht sehr einfach mit der Canvas API (+ File API), auch ohne externe libs und ist stabil...
Lösung (very Oldschool, die Ajax- und JS-Framework-Fans und auch die Profiprogrammierer mögen uns verzeihen):
Im Hauptdokument (zB. diese Seite) binden wir über ein iframe eine "paste-Seite" ein, die gesamte Codeveränderung der ausgelieferten Seite betrifft also genau 1 einzige Zeile. Uns schien das am Sichersten um die aktuelle stabile Version möglichst wenig zu gefährden. Und weiters 1 Zeile im TinyMCE-Code mit der eine Funktion aufgerufen wird, wenn das "paste"-Event anschlägt.
Diese Funktion (sehr einfaches JS-Skript mit nur 4 Zeilen) schaut nach ob ein Blob gepastet wurde, falls ja übergibt sie den Inhalt des Editors an die "paste"-Seite im iframe (eine .net-Seite am Server). Diese ist etwas aufwändiger und macht aus dem Blob ein Bild, lädt es hoch, skaliert es, speichert es im Verzeichnis, erstellt aus dem Bild das Thumbnail das wir für die Übersichten brauchen usw., am Ende ersetzt es mit einem kurzen JS den Blob im TinyMCE durch das soeben hochgeladene Bild. Die ganze Funktionalität bleibt also serverseitig und nutzt bestehende Funktionen, was uns Prozesssicherheit gibt und Testaufwand spart.
Am Testsystem geht das Ganze vom Einfügen bis zum Ersetzen nach dem Hochladen so schnell, dass wir sogar auf eine Ladeanzeige verzichtet haben. Mal sehen wie das dann im Produktivsystem ausschaut. Jetzt fehlt halt noch ein bisschen Testen und ein paar kleine Feinheiten, aber wir sind zuversichtlich dass wir die Funktion bald bereitstellen können.
@Cleudi : Ja danke, schien uns aber zu aufwändig. Man pastet das Blob ja in den TinyMCE, der müsste das irgendwie an die Canvas API übergeben, dann brauchen wir ja auch ein Thumbnail heruntergerechnet, dann beides hochladen usw, das alles als Skript in der Hauptseite. Noch dazu mit der Unsicherheit ob das in allen Browsern geht (inkl. Mobilgeräte), schaut nach vielen Tests und Varianten aus. Da haben wir uns nicht drübergetraut bzw. schien uns das doch erheblich aufwändiger als die umgesetzte Lösung (uns ist .net und C# einfach näher/lieber als JS).
Bei dem bisserl was ich je mit javascript frontend gemacht habe, ist mir auch aufgefallen, dass das Hauptproblem immer die unendliche Vielfalt von Endgeräten (mit ihren browsern) ist. Dazu dann noch der 'continous delivery' von 3 verschiedenen frameworks, die man nutzt, da wirst echt blöd mit Testen. Wenn die API dann noch nicht 100% stabil ist (gibt es den Zustand bei web-SW überhaupt?), dann bist ständig am Nachrödeln ... Einer der Gründe warum mir das Genre reichlich unsympatisch ist und ich bei hardwarenaher SW gelandet bin.
Freu mich schon auf das release ..., schön dass Pfingsten verregnet war
