Speichern mit Javascript (auf HD)

Moin.

Ja, ich weiß, bei dem Titel sträuben sich bei vielen gleich die Haare :wink: Ich weiß auch, dass man mit JS prinzipbedingt keine Festplattenzugriffe hinbekommt. Zumindest war das vor 10 Jahren noch so, und warum sollte sich das geändert haben.

Trotzdem:

Ich habe JS-Skripte, mit denen man bestimmte Dinge auf dem Schirm zusammenbasteln kann - im einfachsten Falle z.B. eine Liste mit Checkboxen, die man bedarfsgerecht anklickt. Diese Auswahl würde ich nun gerne abspeichern. Oder ich habe eine Tabelle, in der ich bestimmte Zellen ändere, was Farbe oder Inhalt angeht - drücke ich auf RELOAD, ist alles wieder weg.

Ich könnte jetzt sicher HTML-Code erzeugen und den in ein Textfeld schreiben. Der Nutzer müsste das dann in die Zwischenablage kopieren und als HTML-Datei abspeichern. Völlig unakzeptabel.

Ich kann natürlich auch die Seite per write() komplett aufbauen in einem separaten Fenster. Der Gedanke wäre, die Seite nun als HTML-Dokument abzuspeichern (Speichern unter). Nützt bloß nichts, weil da dann natürlich nichts drin steht - dynamisch erzeugter Quelltext taucht in der Quelltextansicht nicht auf.

Ihr wisst, was ich meine? Gibt es dafür irgendwelche Lösungen, die in einer HTML/JS-Umgebung unabhängig von Browser und Betriebssystem funktionieren? Letzteres z.B. verbieten schonmal den Einsatz von VBS.

Bin gespannt, ob da Anregungen kommen :wink:

Viele Grüße vom Rhein,
Kristian

Moien

Wieso wollen JS-Leute immer auf anderer Leute Platte speichern. Speichert euere Sachen doch da wo das JS herkommt: auf dem Server. Bau ein Cookie oder schick die Daten per POST/GET an den Server. Dort kann man speichern und verwalten wie man lustig ist.

cu

Server fällt aus.
Du hast prinzipiell recht. Hatte aber vergessen zu erwähnen, dass PHP & Co. nicht in Betracht kommen, da es sich um Offline-Anwendungen handelt und man nicht erwarten kann, dass jeder einen WOS oderso lokal installiert hat, also einen Webserver.

Wieso wollen JS-Leute immer auf anderer Leute Platte
speichern. Speichert euere Sachen doch da wo das JS herkommt:
auf dem Server. Bau ein Cookie oder schick die Daten per
POST/GET an den Server. Dort kann man speichern und verwalten
wie man lustig ist.

Cookies

Hallo Kristian,

die Lösung müsste wohl die hier sein: http://de.selfhtml.org/javascript/objekte/document.h…

Wenn der Surfer aber auf die Idee kommt, seinen Cookie-Speicher zu leeren, ist natürlich alles futsch. Aber da die meisten Surfer wahrscheinlich gar nicht wissen, wie das geht, und du vielleicht wirklich nichts wirklich ewig speichern willst, ist das eigentlich ein guter Kompromiss.

Schöne Grüße,

Mohamed.

Moien

Hatte aber vergessen zu erwähnen,
dass PHP & Co. nicht in Betracht kommen, da es sich um
Offline-Anwendungen handelt und man nicht erwarten kann, dass
jeder einen WOS oderso lokal installiert hat, also einen
Webserver.

Dann bleiben dir 3 Möglichkeiten:

  • benutz eine Sprache die für offline Anwendungen gedacht ist. Ich nehm ja auch nicht die Zahnbürste zum Grossreinemachen oder den Sandstrahler zum Brilleputzen.

  • bau ein recht aufwendiges Konstrukt mit anderen Browser-Techniken (java-applet und flash können Daten auf dem Client cachen. Ohne Garantien zum Thema Haltbarkeit der Dateien.) (signierte java-applet können auch auf den normalen Platteninhalt zugreifen)

  • Benutz ein offline AJAX Framework. Die kommen eigentlich alle mit einem Websever.

cu

Hallo,

Du hast prinzipiell recht. Hatte aber vergessen zu erwähnen,
dass PHP & Co. nicht in Betracht kommen, da es sich um
Offline-Anwendungen

Dann ist Javascript vollkommen ungeignet.

Grüße,
Moritz

Dann bleiben dir 3 Möglichkeiten:

  • benutz eine Sprache die für offline Anwendungen gedacht ist.

Die da wären?

  • bau ein recht aufwendiges Konstrukt mit anderen
    Browser-Techniken (java-applet und flash können Daten auf dem
    Client cachen. Ohne Garantien zum Thema Haltbarkeit der
    Dateien.) (signierte java-applet können auch auf den normalen
    Platteninhalt zugreifen)

Hatte über Java auch schon nachgedacht, aber das kenne ich noch nicht im Detail. Und dem Vernehmen nach ist es ja auch nicht so ganz „easy“ :wink:

  • Benutz ein offline AJAX Framework. Die kommen eigentlich
    alle mit einem Websever.

AJAX habe ich bisher nur im Zusammenhang mit PHP benutzt. Von dem Offline-Framework habe ich noch nichts gehört. Muss da mal nach googeln.

Danke soweit!

Dann ist Javascript vollkommen ungeignet.

War meine Befürchtung, aber die Uhr bleibt ja nicht stehen, und manchmal tun sich neue Wege auf :wink:

Auf die Idee war ich noch nicht gekommen. Das könnte im Einzelfall vielleicht wirklich ein gangbarer Kompromiss sein, wenn das auch mit lokalen Seiten funktioniert. Letzteres ist nicht sicher, denn z.B. der Firefox behandelt lokale Dokumente teilweise anders als serverbasierte.

Danke, das gucke ich mir mal an.
Kristian

Hallo Moritz,

Du hast prinzipiell recht. Hatte aber vergessen zu erwähnen,
dass PHP & Co. nicht in Betracht kommen, da es sich um
Offline-Anwendungen

Dann ist Javascript vollkommen ungeignet.

Wie kommst du denn darauf?

Oder meinst du nur, JS sei ungeeignet, weil der IE dann im Offline-Betrieb jedesmal bestätigt haben möchte, dass man die Ausführung des Skripts wirklich zulassen will? Es gibt ja auch noch andere Browser und selbst den IE kann man konfigurieren.

http://aktuell.de.selfhtml.org/artikel/sonstiges/mar…

Gruß Gernot

Moien

  • benutz eine Sprache die für offline Anwendungen gedacht ist.

Die da wären?

C, C++, C++.NET, C#, J#, VB, VB.NET, Java-Applications, Perl, PHP, Python, … halt alle grossen ausser Javascript. Für javascript-Leute dürften VB.NET oder Java die besten Alternativen sein.

Hatte über Java auch schon nachgedacht, aber das kenne ich
noch nicht im Detail. Und dem Vernehmen nach ist es ja auch
nicht so ganz „easy“ :wink:

All die anderen Sprachen haben einen grossen Vorteil: das Verhalten der Befehle hängt nicht oder nur sehr wenig von der Umgebung ab. Bei Javascript und JS kann jeder Browser reagieren wie er will (auf das skript und aufs HTML), bei den ist kein Browser im Spiel.

cu

Hallo Pumkin!

  • benutz eine Sprache die für offline Anwendungen gedacht ist.

Die da wären?

C, C++, C++.NET, C#, J#, VB, VB.NET, Java-Applications, Perl,
PHP, Python, … halt alle grossen ausser Javascript. Für
javascript-Leute dürften VB.NET oder Java die besten
Alternativen sein.

Warum denn mit Kanonen auf Spatzen schießen?

All die anderen Sprachen haben einen grossen Vorteil: das
Verhalten der Befehle hängt nicht oder nur sehr wenig von der
Umgebung ab. Bei Javascript und JS kann jeder Browser
reagieren wie er will (auf das skript und aufs HTML), bei den
ist kein Browser im Spiel.

Auf meine Javascript-Cookie -Spielerei, die ich vor einigen Jahren mal sogar noch lauffähig auch für Netscape4 geschrieben habe, reagieren immer noch alle mir bekannten Browser gleich: Sie funktioniert, auch wenn ich heute zwar immer noch mit JavaScript und Cookies, aber dennoch sonst fast alles anders programmieren würde:

http://www.sprachlernspiele.de/match/irrverbchoice.html

Über Cookie merkt sich der Browser, welche unregelmäßigen Verben des Englischen man bei früheren Besuchen bereits trainiert hat und stellt sie beim nächsten Besuch auf der Auswahlseite andersfarbig dar. Das funktioniert auch lokal.

Gruß Gernot

C, C++, C++.NET, C#, J#, VB, VB.NET, Java-Applications, Perl,
PHP, Python, … halt alle grossen ausser Javascript.

Achso. Na gut. Problem dabei ist vor allem die zumindest gewisse Betriebssystemabhängigkeit. Und da heutzutage ohnehin vieles im Browser läuft, der einem diese Abhängigkeit in weiten Teilen abnimmt, wäre das die beste Lösung gewesen.

Für javascript-Leute dürften VB.NET oder Java die besten
Alternativen sein.

Ersters werde ich mir ohnehin mal angucken. Ist dann aber nur für Windows, und selbst da hat noch lange nicht jeder das .NET-Framework drauf.

All die anderen Sprachen haben einen grossen Vorteil: das
Verhalten der Befehle hängt nicht oder nur sehr wenig von der
Umgebung ab.

Was zu beweisen wäre :wink: Bei Ausrichtung auf ein bestimmtes BS und eine bestimmte Version davon mag das stimmen, aber sonst ist es wie mit den Browsern: Die vielbeschworene Unabhängigkeit hat teilweise enge Grenzen :wink:

Bei Javascript und JS kann jeder Browser reagieren wie er will
(auf das skript und aufs HTML), bei den ist kein Browser im Spiel.

Das alte Spiel, ja :wink: Aber ich habe das bisher noch immer halbwegs in den Griff bekommen.

Wie auch immer, danke für die Anregungen. Ein Schuss in den Wind waren sie auf jeden Fall nicht.

Bookmark als Einstellungen-‚Speicher‘
Hallo,

ich habe neben den Cookies noch eine andere Idee, die ich mal probieren werde:

Ich generiere einen Link auf die Seite, der Parameter enthält. Diese kann man beim Aufruf der Seite ja auslesen und auswerten. Handelt es sich also z.B. um ein Formular, schreibe ich einfach alle Formulardaten da rein (als würde ich sie an einen Server schicken wollen). Diesen Link muss man dann als Bookmark abspeichern.

Nachteil ist, dass diese Links übelst lang werden können. Weiß jemand, ob es da eine Längenbeschränkung gibt? Nachteil 2 ist, dass ich die Daten dann per Skript wieder einlesen und verarbeiten muss, also z.B. die Formularelemente wieder entsprechend setzen bzw. befüllen oder HTML-Elemente formatieren muss. Aber das geht schon bei kleineren Sachen.

Kristian

Du hast prinzipiell recht. Hatte aber vergessen zu erwähnen,
dass PHP & Co. nicht in Betracht kommen, da es sich um
Offline-Anwendungen handelt und man nicht erwarten kann, dass
jeder einen WOS oderso lokal installiert hat, also einen
Webserver.

Ich weiß ja nicht, was das werden soll, aber wenn das eine Art „Software“ sein soll, die ein Anwender bei sich „installieren“ kann, um sie dann zu nutzen, warum dann nicht auch einen Webserver installieren?

Mir fällt dazu z.B. Server2Go ein, was sich wohl[1] auch wunderbar auf CDROM oder USB-Stick installieren lässt.
http://www.server2go-web.de/

Gruß,
-Efchen

[1] „wohl“, weil ich es bislang noch nicht ausprobiert habe.

Naja, das sollte eben gerade OHNE alle Installationen auskommen :wink: Der Browser allein muss reichen. Sonst könnte ich z.B. in einem Falle auch bei Excel bleiben, das aber nicht jeder hat.

Ich werde mal die beschriebene Link-Methode ausprobieren. Die ist nicht ganz so elegant wie die mit den Cookies, aber transparenter.

Einen „Export“ erlauben beide nicht (z.B. die Liste der ausgewählten Bilder). Da muss dann eben doch das Textfeld herhalten zum Rauskopieren. … ehm … da fällt mir siedend heiß das Posting ein, das ich eben gerade ganz oben eingefügt habe … ach Du Sch… Zeilenumbrüche …

Kristian

Hallo,

Du hast prinzipiell recht. Hatte aber vergessen zu erwähnen,
dass PHP & Co. nicht in Betracht kommen, da es sich um
Offline-Anwendungen

Dann ist Javascript vollkommen ungeignet.

Wie kommst du denn darauf?

  • HTML ist nicht für UI-Design ausgelegt

  • Javascript unterstützt keine Variablenchecks zur Compilezeit

  • Das DOM ist in unterschiedlichen Browsern unterschiedlich implementiert => eklig portabel zu programmieren

  • Javscript unterstütz i.A. keine Zugriffe auf die Festplatte (nur Cookies)

  • Es gibt kein einfaches Verfahren, Informationen von Seite zu Seite weiterzugeben

Das sind alles Dinge, die es erschweren, Richtige Programme mit HTML+JS zu bauen, und wenn man nicht mal Zugriff auf serverseite Scripte hat, wird das ganze richtig eklig.

Wenn man stattdessen eine „richtige“ Programmierpsrache nehmen könnte, sehe ich keinen Grund, Javascript zu verwenden.

Grüße,
Moritz