.txt import / export in JavaScript

[Dominique]

Hallo zusammen,

ich habe eine JavaScript / JQuery basierte Application, bei der ich einen Import/Export Dialog anbiete, um die erstellte Konfiguration zu speichern / wieder einzulesen.

Die gesamte Konfiguration liegt zur Laufzeit in JavaScript Variablen vor, ein Speichern als JSON String ist also naheliegend.

Option eins waere, den JSON String in eine textarea zu schreiben, und den User zu copy & paste aufzufordern, beim Import dann umgekehrt. In JS sehr einfach, aber ich finde es persoenlich nicht benutzerfreundlich.

Option zwei ist den JSON String an den Server zu schicken und schlicht per PHP zu 'bouncen', um den Browser das 'Save As' Popup oeffnen zu lassen. Userfreundlich, aber unnoetig langsam und verursacht Netzwerk Traffic.

Option drei waere Hintergrund meiner Frage: Per JavaScript direkt das 'Save As' Popup zu oeffnen. Ich will nicht das File direkt Speichern, sondern dem Browser quasi Option zwei vorgaukeln, ohne den Umweg ueber http zu gehen.

Es reicht uebrigens, wenn die Loesung in Firefox 3+ funktioniert, da die Applikation nicht oeffentlich ist.

Mit altbackenem JavaScript geht Option drei ganz sicher nicht, dessen bin ich mir bewusst. Ich bin in Sachen dataURIs und Alternativen allerdings nicht so fit um sagen zu koennen ob dort eventuell eine Moeglichkeit besteht, deswegen diese Frage.

Danke fuer Eure Hinweise,
Dominique

[LX]

Ich weiß ja nicht, was genau Du vor hast, aber reicht möglicherweise ein Cookie oder, wenn Du FF3+ voraussetzt, die sqlite-Datenbank, die Du über window.globalStorage verwenden kannst?

Gruß, LX

[Dominique]

Hallo zusammen,

Cookies reichen leider nicht, dafuer ist die Datenmenge zu gross.

Zur eigentlichen Frage, was will ich tun: Ich will dem User einen in JS vorhandenen String als Download zur Verfuegung stellen ("Save as" Dialog), ohne das ich ihn vorher an den Server schicke.

Mit Server ist es wie gesagt einfach, siehe Option 2 weiter oben.

Gruss,
Dominique

[Struppi]

Zur eigentlichen Frage, was will ich tun: Ich will dem User einen in JS vorhandenen String als Download zur Verfuegung stellen ("Save as" Dialog), ohne das ich ihn vorher an den Server schicke.

Das geht nicht.

Struppi.

[Struppi]

Mit altbackenem JavaScript geht Option drei ganz sicher nicht, dessen bin ich mir bewusst. Ich bin in Sachen dataURIs und Alternativen allerdings nicht so fit um sagen zu koennen ob dort eventuell eine Moeglichkeit besteht, deswegen diese Frage.

Mir ist nicht klar was die Frage überhaupt ist. Du kannst mit JS nicht auf den Client zugreifen. Dazu benötigt dein Skript erweiterte Rechte und entweder ActiveX oder XCOM, aber so wie du es schilderst geht es nicht.

Struppi.

[Don P]

Hallo,

Es reicht uebrigens, wenn die Loesung in Firefox 3+ funktioniert, da die Applikation nicht oeffentlich ist.

Mit altbackenem JavaScript geht Option drei ganz sicher nicht, dessen bin ich mir bewusst.

Doch, den "Save As"-Dialog kannst du im FF per JS aufrufen, nachdem der Benutzer zugestimmt hat (er bekommt vorher eine Sicherheits-Warnung und muss explizit zustimmen). Damit lässt sich aber meines Wissens nur das aktuelle Dokument speichern, nicht beliebige Daten.

Eine Ansatz wäre vieleicht: Eine spezielles Dokument erzeugen, das hauptsächlich die zu speichernden Daten enthält, und dieses dann per Save As vom Benutzer abspeichern zu lassen.

Habe selber gerade ein Projekt, wo ich so etwas umsetzen will, bin aber noch nicht soweit. Im Moment gibt's noch andere Prioritäten.
Wenn du eine Lösung hast, lass' es bitte wissen.

Gruß, Don P

[Struppi]

Doch, den "Save As"-Dialog kannst du im FF per JS aufrufen,

Wie das?

Struppi.

[Don P]

Hallo,

Doch, den "Save As"-Dialog kannst du im FF per JS aufrufen,

Wie das?

Unter Windows geht es so:

<script type="application/x-javascript" src="chrome://global/content/contentAreaUtils.js"></script>  
<script type="application/x-javascript">  
[code lang=javascript]    netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");  
    saveDocument(document);  

~~~</script>  
[/code]  
  
Gruß, Don P

[Dominique]

Hi Don,

korrigiere mich, aber die chrome URLs (und damit auch chrome://global/content/contentAreaUtils.js) kann ich als Webseite nicht aufrufen, lediglich als lokales File (oder FF extension)?

Danke!
Dominique

Hallo,

Doch, den "Save As"-Dialog kannst du im FF per JS aufrufen,

Wie das?

Unter Windows geht es so:

<script type="application/x-javascript" src="chrome://global/content/contentAreaUtils.js"></script>

<script type="application/x-javascript">
[code lang=javascript]    netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
    saveDocument(document);

> [/code]  
>   
> Gruß, Don P

[Don P]

Hallo,

korrigiere mich, aber die chrome URLs (und damit auch chrome://global/content/contentAreaUtils.js) kann ich als Webseite nicht aufrufen, lediglich als lokales File (oder FF extension)?

Wie meinst du das "als Webseite"? Gib den URL doch mal im Browser ein: Es erscheint das Script. Natürlich kannst du es auch abspeichern und dann lokal einbinden, wenn deine User keine Verbindung zum Internet haben.

Es ist genau die Technik, die Struppi oben als XCOM verlinkt hat.

Gruß, Don P

[Dominique]

Ok jetzt bin ich verwirrt... ich teste das mal in Ruhe durch und melde mich dann ggf. noch mal.

Danke Don!
Dominique

[Struppi]

Ok jetzt bin ich verwirrt... ich teste das mal in Ruhe durch und melde mich dann ggf. noch mal.

Wie schon gesagt, das was du willst geht mit JS nicht und es darf auch nicht gehen. Du kannst dir aber natürlich eine lokale Anwendung schreiben, die das schon erwähnte XPCOM (oder ActiveX) verwendet - hier liegt aber die Betonung auf lokal. Wenn es nicht so wäre, müßte man morgen das Internet schliessen.

Struppi.

[Struppi]

Unter Windows geht es so:

hmm, da muss man wohl noch mehr machen:

Fehler: Einem Skript von "http://localhost" wurden UniversalXPConnect Berechtigungen verweigert.
Quelldatei: http://localhost/htdocs/javascript/test.html
Zeile: 31

Struppi.

[Don P]

Hallo,

hmm, da muss man wohl noch mehr machen:

Fehler: Einem Skript von "http://localhost" wurden UniversalXPConnect Berechtigungen verweigert.
Quelldatei: http://localhost/htdocs/javascript/test.html
Zeile: 31

Hatte das früher mal unter Win2000 probiert und es lief einwandfrei.
Jetzt, unter XP SP3 in FF 3.5.3 bleibt der DownloadManager zunächst hängen, aber wenn man dort den Abbrechen-Button klickt und dann auf "nochmal versuchen", dann geht's endlich.

Vielleicht muss man im Browser noch etwas mit den Einstellungen spielen. Wenn die Sicherheitseinstellungen zu restriktiv sind, geht's vielleicht gar nicht.

Gruß, Don P

[Struppi]

Hatte das früher mal unter Win2000 probiert und es lief einwandfrei.
Jetzt, unter XP SP3 in FF 3.5.3 bleibt der DownloadManager zunächst hängen, aber wenn man dort den Abbrechen-Button klickt und dann auf "nochmal versuchen", dann geht's endlich.

Nicht mit http
Wenn ich das als Datei mit dem file:// Protokoll aufrufe, dann geht es. Ansonsten geht es gar nicht - bzw. nur mit der obigen Fehlermeldungen, ansonsten passiert nichts weiter.

Vielleicht muss man im Browser noch etwas mit den Einstellungen spielen. Wenn die Sicherheitseinstellungen zu restriktiv sind, geht's vielleicht gar nicht.

Die dürften dann aber irgendwo in about:config versteckt sein. Ich finde diese aber nicht auf die Schnelle.

Struppi.

[Don P]

Hallo,

XUL, was immer das genau sein mag, kann es.
Zwar nur lokal, aber immerhin. Für manche so Anwendung reicht das auch.

Gruß, Don P

[Struppi]

XUL, was immer das genau sein mag, kann es.
Zwar nur lokal, aber immerhin. Für manche so Anwendung reicht das auch.

Das war ja die ganze Zeit der Punkt, für Lokale Anwendungen geht es, hat niemand bestritten, aber ich glaube Dominique reicht das nicht.

Struppi.

[Don P]

Hallo,

Das war ja die ganze Zeit der Punkt, für Lokale Anwendungen geht es, hat niemand bestritten, aber ich glaube Dominique reicht das nicht.

Er schrieb doch:

Es reicht uebrigens, wenn die Loesung in Firefox 3+ funktioniert, da die Applikation nicht oeffentlich ist.

Bei "nicht öffentlich" nehme ich an, dass das ganze vielleicht in einem lokalen Netz läuft, bzw. man zumindest ein paar Files jeweils lokal halten kann. Es reicht, wenn die .htm oder .xul-Datei, die die höheren Rechte braucht, lokal aufgerufen wird. JS z.B. kann man dann trotzdem über HHTP laden.

Gruß, Don P

[Struppi]

Bei "nicht öffentlich" nehme ich an, dass das ganze vielleicht in einem lokalen Netz läuft, bzw. man zumindest ein paar Files jeweils lokal halten kann. Es reicht, wenn die .htm oder .xul-Datei, die die höheren Rechte braucht, lokal aufgerufen wird. JS z.B. kann man dann trotzdem über HHTP laden.

Und lokal heißt? Der Code lief ja nicht über localhost, tut es der andere?

Soweit och das verstehe, musst du so oder so, etwas auf dem Rechner installieren auf dem das Skript laufen soll, oder nicht?

Struppi.

[Don P]

Hallo,

Und lokal heißt?

Unter lokal verstehe ich über das file://-Protokoll, nicht über http://localhost oder http://www.

Der Code lief ja nicht über localhost, tut es der andere? Soweit och das verstehe, musst du so oder so, etwas auf dem Rechner installieren auf dem das Skript laufen soll, oder nicht?

Ja, und zwar die html. oder xul-Datei, die die eigentliche Anwendung startet (sonst ist es eben nicht lokal). Man kann dann problemlos Dateien aus vom lokalen System einlesen und in irgend einem DOM-Element anzeigen (z.B. TextDateien mit beliebigen Daten) und solche auch speichern. Ok, das ist nicht wirklich neu.

tut es der andere?

Zugriffe über http:// sind dann zwar vom lokalen Fenster sehr eingeschränkt, aber möglich. JS-Scripte z.B. kann man über http://www trotzdem einbinden (höchstwahrscheinlich auch CSS und vielleicht sogar AJAX, diese hab ich bis jetzt noch nicht getestet). Wenn so gut wie alles über JS und CSS läuft, wie das bei mir zur Zeit der Fall ist, dann reicht das völlig. Habe da ein recht umfangreiches Script, das ich über www laden lassen will, wenn andere als ich es benutzen, und das scheint zu klappen.
Das bisschen HTML, was lokal geladen werden muss, ist kaum der Rede wert.

Gruß, Don P

[Struppi]

Und lokal heißt?

Unter lokal verstehe ich über das file://-Protokoll, nicht über http://localhost oder http://www.

Deshalb hatte ich ja auch gefragt. Für mich ist lokal mein localhost und ich weiß nicht wie Dominique das sieht.

Das bisschen HTML, was lokal geladen werden muss, ist kaum der Rede wert.

Naja, darum geht es ja nicht, es ist halt die Frage, wie weit man eine systemnahe Anwendung über's Internet installieren bzw. starten kann.

Soweit ich das bisherige nachvollziehen kann, ist es also nur möglich, wenn der Ablauf ähnlich wie bei einem AddOn ist. Lokale Installation einer XUL Datei, dann kann ein über http:// aufgerufenes JS darauf zugreifen, aber dann muss doch dem Skript irgendwo mitgeteilt werden, dass es mehr privilegien hat als andere?

Struppi.

[Don P]

Hallo,

Das bisschen HTML, was lokal geladen werden muss, ist kaum der Rede wert.

Naja, darum geht es ja nicht, es ist halt die Frage, wie weit man eine systemnahe Anwendung über's Internet installieren bzw. starten kann.

Soweit ich das bisherige nachvollziehen kann, ist es also nur möglich, wenn der Ablauf ähnlich wie bei einem AddOn ist. Lokale Installation einer XUL Datei, dann kann ein über http:// aufgerufenes JS darauf zugreifen,

Ja genau.

aber dann muss doch dem Skript irgendwo mitgeteilt werden, dass es mehr privilegien hat als andere?

Der Umfang der Privilegien hängt allein vom Protokoll ab, über das das Script mit den systemnahen Funktionen geladen wurde. Alles, was systemnah passieren soll, mus über das file://-Protokoll geladen werden, d.h. wenn lokale IO-Funktionen per JS auszuführen sind, dann müssen diese Funktionen auch über eine lokale js-Datei geladen sein. Aber nur diese speziellen Funktionen. Nachdem sie einmal geladen sind, kann auch ein remotes Script sie benutzen, d.h. z.B. Datein vom lokalen System lesen und dort speichern. Natürlich erst nach Zustimmung des Benutzers, versteht sich, der ja auch ein bisschen etwas lokal installieren muss (die HTML-Datei und die JS-Datei mit den IO-Funktionen nämlich).

Ich will das jetzt hier nicht weiter ausführen, ist ja immerhin sicherheitsrelevant, aber ich habe es aber soeben getestet und es klappt prima. Für meine Zwecke reicht das auch völlig :), für den OP vielleicht auch. Werde meinen Benutzern dieses Feature einfach anbieten, falls sie es wünschen, sonst können sie sich die eigenen Daten halt nur rein- und rauskopieren und "zu Fuß" abspeichern.

Gruß, Don P

[Don P]

Hallo,

Unter lokal verstehe ich über das file://-Protokoll, nicht über http://localhost oder http://www.

Deshalb hatte ich ja auch gefragt. Für mich ist lokal mein localhost und ich weiß nicht wie Dominique das sieht.

Der localhost ist aus Browsersicht nicht lokaler als irgend ein remote Server. Dass der pysisch im selben Raum steht, ist dabei nicht relevant.

Man kann sich höchstens darüber streiten, ob z.B. eine Netzwerkressource im LAN noch als lokal gelten kann oder nicht, ein gemountetes Netzlaufwerk z.B.

Gruß, Don P

[Struppi]

Der localhost ist aus Browsersicht nicht lokaler als irgend ein remote Server. Dass der pysisch im selben Raum steht, ist dabei nicht relevant.

Exakt.
Deshalb fragte ich ja, um eventuelle Mißverstädnisse zu vermeiden, da du nur von lokal sprachst, aber nicht davon, welches Protokoll du verwendest. Und wie du schon sagtest:

Bei "nicht öffentlich" nehme ich an, dass das ganze vielleicht in einem lokalen Netz läuft, bzw. man zumindest ein paar Files jeweils lokal halten kann.

Was ja auch eine Interpretation deinerseits ist. Dabei geht es letztlich nur darum welches Protokoll verwendet wird und ob er die Möglichkeit hat lokal, also auf dem Rechner, Dateien zu installieren.

Nicht öffentlich heißt für mich erstmal gar nichts.
Das können mit HTTP-Authentifizierung oder anderen Mechanismen geschützte Webseiten sein, das kann ein lokales Netzwerk sein, dessen Protokoll wir nicht kennen, das kann aber auch einfach eine Internetseite sein, die nicht gespidert wird usw.

Struppi.