Saving dynamically created data on client side?

[HaJo]

JS-rookie here... Apologies first, I guess this must have been asked a
million times. I googled back&forth, but all the answers I saw were
somehow drifting into different directions, not providing a
solution... Here's the problem:

I have a client-side javascript running, the user creates some data.
At a point the data should be saved to his HDD -- I.e. a "Save as...".
Format of the data, btw, is XML. I couldn't find any pointer on how to
do this client-side only, cross-browser/OS. Any idea how this can be
achieved?

If not possible, I'm thinking whether I should submit the data back to
the server into a cgi/php, temporarily storing the file on the server.
I guess the javascript could then pop a new window open, linking to
the server-side script. That one could then serve the file, hopefully
triggering a "Open/Save" dialog box of the browser. But here I'm not
sure how to create, from the JS, a unique ID identifying the correct
handle for the cgi/php. I worry about race-conditions...

I'm currently asking the user to copy&paste the XML data into a new
document and save that. But that's probably the most user-unfriendly
way I could come up with

Hints or thoughts are highly appreciated!

//hajo

 

[SAM]

Le 8/20/09 3:31 AM, HaJo a écrit :

JS-rookie here... Apologies first, I guess this must have been asked a
million times. I googled back&forth, but all the answers I saw were
somehow drifting into different directions, not providing a
solution... Here's the problem:

I have a client-side javascript running, the user creates some data.
At a point the data should be saved to his HDD -- I.e. a "Save as...".

Not possible ! Impossible ! Forbiden ! Formaly not allowed !

JavaScript refuses to interact with user's objects (computer as well)
The most acting in user's files allowed is to upload one(s) of them.

If not possible, I'm thinking whether I should submit the data back to
the server into a cgi/php, temporarily storing the file on the server.
I guess the javascript could then pop a new window open, linking to
the server-side script. That one could then serve the file, hopefully
triggering a "Open/Save" dialog box of the browser. But here I'm not
sure how to create, from the JS, a unique ID identifying the correct
handle for the cgi/php. I worry about race-conditions...

I do not see there where/when the "data" are saved on the user's computer ?

I'm currently asking the user to copy&paste the XML data into a new
document and save that. But that's probably the most user-unfriendly
way I could come up with

Why can't he save directly all the document (and its "new data")

Hints or thoughts are highly appreciated!

Unlovely, I think you can't open a new window, then to append in its
file the new data (the cloneNode), then in last ask to the user to save
this popup.

Maybe if new data are in a form element, you could write its value in a
new popup to save.
demo:
<http://cjoint.com/?iuebHCzAH7>

 

[HaJo]

Thanks for the quick reply, sam!

I do not see there where/when the "data" are saved on the user's computer?

The popup would load the server-side script. That one could then, as
its output, serve the data as an octet-stream, no?

Why can't he save directly all the document (and its "new data")

Because he would not only save the data, but the source of the page
incl the HTML, JS, etc. No?

Maybe if new data are in a form element, you could write its value in a
new popup to save.
demo:
<http://cjoint.com/?iuebHCzAH7>

Tnx sam! I played into this direction before. While this appears to
work properly for plain text et al, I seem to have major problems
handling XML here. Try, in the form, to enter something like <?xml
version="1.0?><data>foo</data>. I only seem to get a "foo", but not
the markup. But the file the user expects on his computer would have
to include the XML-markup...

 

[RobG]

Le 8/20/09 3:31 AM, HaJo a écrit :



Not possible ! Impossible ! Forbiden ! Formaly not allowed !

Yes, you can. It just requires security settings to be set to
appropriate values. Here's an example:

<URL: http://tiddlywiki.org/wiki/Main_Page >

HTML 5 also provides for limited client-side storage of data using a
client database API:

<URL: http://www.weboshelp.net/webos-tutorials/156-palm-webos-html5-database-storage-tutorial
It seems mobile browsers are pushing the boundaries here faster than
desktop browsers, but the future is clear: the use of client-side data
storage will grow.

 

[HaJo]

Yes, you can. It just requires security settings to be set to
appropriate values. Here's an example:

<URL:http://tiddlywiki.org/wiki/Main_Page>

That one seems to save to itself only, not an option in my case since
the JS gets served from http, the save occurs to the client HDD.

<URL:http://www.weboshelp.net/webos-tutorials/156-palm-webos-html5-databas...

Not exactly cross-platform, cross-browser, I suppose...

 

[SAM]

Le 8/20/09 4:44 AM, RobG a écrit :

Yes, you can. It just requires security settings to be set to
appropriate values. Here's an example:

<URL: http://tiddlywiki.org/wiki/Main_Page >

Where is the demo ?
(where can I write something and save it on my own HD ?)

HTML 5 also provides for limited client-side storage of data using a
client database API:

<URL: http://www.weboshelp.net/webos-tutorials/156-palm-webos-html5-database-storage-tutorial

Funny
<http://webkit.org/demos/sticky-notes/index.html>
seems to work directly with my Safari.3
and probably after permission with my Fx.3

It seems mobile browsers are pushing the boundaries here faster than
desktop browsers, but the future is clear: the use of client-side data
storage will grow.

rest for me to see/find where the "data base" is hidden in my DD ... !
(to delete it)

 

[SAM]

Le 8/20/09 4:40 AM, HaJo a écrit :

Tnx sam! I played into this direction before. While this appears to
work properly for plain text et al, I seem to have major problems

It was a simple example without no RegExp to htmlize '<' or return
carriages and so ...

handling XML here. Try, in the form, to enter something like <?xml
version="1.0?><data>foo</data>. I only seem to get a "foo", but not
the markup.

With my Firefox I obtain exacktelly in popup's source :

<?xml
version="1.0?><data>foo</data>

when the textarea contained :

<?xml
version="1.0?><data>foo</data>

before "to save"

or :
<?xml version="1.0"?>
<data>
foo
</data>
when textarea value was the same

Not tested with IE that I don't know

 

[Thomas 'PointedEars' Lahn]

JS-rookie here... Apologies first, I guess this must have been asked a
million times. I googled back&forth, but all the answers I saw were
somehow drifting into different directions, not providing a
solution... Here's the problem:

You have not searched for "save as", have you?

I have a client-side javascript running, the user creates some data.
At a point the data should be saved to his HDD -- I.e. a "Save as...".
Format of the data, btw, is XML. I couldn't find any pointer on how to
do this client-side only, cross-browser/OS. Any idea how this can be
achieved?

It cannot be done in the desired way with client-side scripting as that
depends on the runtime environment for providing that feature.

If not possible, I'm thinking whether I should submit the data back to
the server into a cgi/php, temporarily storing the file on the server.
I guess the javascript could then pop a new window open, linking to
the server-side script.

It could even be done, and should be made possible too, without client-side
scripting at all.

That one could then serve the file, hopefully
triggering a "Open/Save" dialog box of the browser. But here I'm not
sure how to create, from the JS, a unique ID identifying the correct
handle for the cgi/php. I worry about race-conditions...

I do not see a race condition as your server would generate the file on the
fly, printing it to the standard output, upon request of a specific client
as response message to that client. You can make use of session IDs, though.

I'm currently asking the user to copy&paste the XML data into a new
document and save that. But that's probably the most user-unfriendly
way I could come up with
Yes.

Hints or thoughts are highly appreciated!

You are welcome.


PointedEars

 

[HaJo]

Le 8/20/09 4:40 AM, HaJo a écrit :

With my Firefox I obtain exacktelly in popup's source :

<?xml
version="1.0?><data>foo</data>

when the textarea contained :

<?xml
version="1.0?><data>foo</data>

before "to save"

Yes sam, same here, also with IE. The source is correct. But, at least
in IE, try to save the popup to disk. If you choose "text file", you
only get the "foo". If you choose "html file", you get html-markup and
inside the <body>foo</body>. Not the XML. Escaping doesn't do it
either, same result... I also tried to change the content-type to /xml
-- same results

The webkit.org demo doesn't do it either with IE... This indeed seems
a major hurdle with yet another discussion drifting off without a
solution

As soon as I have some spare time, I'll try the folling approach, that
may solve my problem if my thinking is correct:

- Serve the "editor page" with the JS from a cgi. The CGI can provide
a sessionID
- When the user clicks "Save", a form-field submits the data back to
the server, to this cgi with the seesionID
- The server-side stores the data in a file and re-serves the original
"editor page" with a dynamically modified JS which will then:
- Open a pop-up, pointing to the server-side CGI with the same
SessionID.
- Now, the server-side CGI inside the pop-up can serve the data file
which it has on storage.

Not sure whether that really works, but at least in theory it sounds
to me like a universal, albeit ugly, solution...

 

[HaJo]

Le 8/20/09 4:44 AM, RobG a écrit :

You download the wiki to your HDD. You open it in your browser from
there. Then you can click on "Save" and it saves some data into
itself, I.e. into the file on HDD. Doesn't look like it can create
other files.

 

[HaJo]

HaJo wrote:

You have not searched for "save as", have you?

I have, but all I came up with were answers similar to what's
happening now -- not really a solution but quirks which only seem to
work on very restricted nmbr of environments. I do have requirements
of IE6/W2K, FF/Linux, so cutting-edge may not be the right sol'n.

I do not see a race condition as your server would generate the file on the
fly, printing it to the standard output, upon request of a specific client
as response message to that client.  You can make use of session IDs, though.

That may actually be a solution, coming to think about it -- open a
pop-up with another JS which pushes the data into the server and, in
reply, getting the file. Will try that as well, tnx!

 

[SAM]

Le 8/20/09 9:27 AM, HaJo a écrit :

Yes sam, same here, also with IE. The source is correct. But, at least
in IE, try to save the popup to disk. If you choose "text file", you

Ho! Sorry I'vnt been so far.
indeed : no acceptable save, even with Fx :-(

The webkit.org demo doesn't do it either with IE... This indeed seems
a major hurdle with yet another discussion drifting off without a
solution

Found the "data base" created by this thing, where "data" saw previously
in 2nd edition becomes :

<

 

[SAM]

Le 8/20/09 9:29 AM, HaJo a écrit :

You download the wiki to your HDD. You open it in your browser from

No ! Thanks !
I don't need/like to download what I don't know what it is.

Found a kind of demo :

there. Then you can click on "Save" and it saves some data into
itself, I.e. into the file on HDD. Doesn't look like it can create
other files.

Looks like the webkit extension-tool-bazar-truc
<http://webkit.org/demos/sticky-notes/index.html>
and its Safari's Sqlite database
(interesting if we could have time to understand how that works to
modify it as we want it)
The Sqlite file is created in the own preferences folder of Safari, it
is a little different than to create a file in one (which one?) of
user's folders (security consideration).

Fx stored something in the profile folder in file : sessionstore.js

 

[SAM]

Le 8/20/09 10:12 AM, SAM a écrit :

Le 8/20/09 9:27 AM, HaJo a écrit :


Found the "data base" created by this thing, where "data" saw previously
in 2nd edition becomes :

<

??? where went the following ?

<

 

[Thomas 'PointedEars' Lahn]

Yes sam, same here, also with IE. The source is correct. But, at least
in IE, try to save the popup to disk. If you choose "text file", you
only get the "foo". If you choose "html file", you get html-markup and
inside the <body>foo</body>. Not the XML. Escaping doesn't do it
either, same result... I also tried to change the content-type to /xml
-- same results

So serve it with `Content-Type: text/xml' (or whatever media type it is) and
`Content-Disposition: attachment' or with `Content-Type:
application/octet-stream'; the download dialog would appear automatically,
and no transformation should take place.

How to serve a file for download is completely off-topic here.

<http://jibbering.com/faq/#appropriateQuestions>


PointedEars

 

[SAM]

Le 8/20/09 10:42 AM, SAM a écrit :

Le 8/20/09 10:12 AM, SAM a écrit :

Le 8/20/09 9:27 AM, HaJo a écrit :


Found the "data base" created by this thing, where "data" saw
previously in 2nd edition becomes :

<

??? where went the following ?

<[/QUOTE]


this copy of code definitively will not pass :-(
sorry.
I don't know how to write it (without to destroy it)

Last try:

<

 

[HaJo]

I have a client-side javascript running, the user creates some data.
At a point the data should be saved to his HDD -- I.e. a "Save as...".

Tnx guys for your help here, I did indeed find a satisfactory solution
now. The main pointer came from Thomas:
I assemble the data in JS in a form field. I then submit this to a
server CGI which immediately returns it with Content-type & Content-
disposition correctly set. No need to pop up a window or similar
workarounds, the browser accepts it and keeps the original page
untouched. Beautiful!

 

[Thomas 'PointedEars' Lahn]

Tnx guys for your help here, I did indeed find a satisfactory solution
now. The main pointer came from Thomas:
I assemble the data in JS in a form field. I then submit this to a
server CGI which immediately returns it with Content-type & Content-
disposition correctly set. No need to pop up a window or similar
workarounds, the browser accepts it and keeps the original page
untouched. Beautiful!

You are welcome But AISB, as you have server-side scripting to do it,
you should consider making an effort to have that working without
client-side script support at all, so that your application does not break
if for some (probable) reason client-side scripting is unavailable. That
could be as simple as having the server generate, in that event, the form
with the appropriate `input' elements filled in.


PointedEars