Prev: opacity and MS (one more time)
Next: What's a good license for My Library?
From: Paul Hovnanian P.E. on 4 Jan 2010 15:21
I'm porting an application to Javascript (from Java) and I'd like to do a
couple of things.

The user will load a 'form' from my website, which will load the required
Javascript libraries using the src='....' attribute of various script tags.
I use the term 'form' loosely, as the app will use a rather involved object
model which may not be easily represented by the typical form contents.
After the user works with this app for a while, they will save the page to
their desktop rather than submitting it to my site for storage. At some
point in the future, they can reload the file they have saved locally and
resume work. But this presents a couple of problems:

1) As long as the original page was loaded from my web site, the scripts
will execute and subsequent XMLHttpRequests will work without any domain
violations. But once the user has reloaded the page in work from their
local file system, these operation result in security violations. Is there
any way to bypass this?

2) Saving the page (with modifications made to the object model by the user)
doesn't result in those modifications to be saved. Only a copy of the
original (unedited) page text gets saved to disk. What would work is some
way to install a new handler for a browser's 'File|Save' event which could
convert the edited data in memory back to text (XML, etc) and save that. s
this possible?

Basically, what I'm trying to do is too get out of the document storage
business for my customers. While they are using this app, the data
transferred to/from my back end application should only persist on the
server for the duration of that transaction. Is Javascript even the right
way to go for such an app?

--
Paul Hovnanian paul(a)hovnanian.com
----------------------------------------------------------------------
Have gnu, will travel.
From: Scott Sauyet on 4 Jan 2010 16:13
On Jan 4, 3:21 pm, "Paul Hovnanian P.E." <p...(a)hovnanian.com> wrote:
> [ ... ]
> Basically, what I'm trying to do is too get out of the document storage
> business for my customers. While they are using this app, the data
> transferred to/from my back end application should only persist on the
> server for the duration of that transaction. Is Javascript even the right
> way to go for  such an app?

I've been considering a very similar problem for few weeks now, and
can't say for certain if what I want to attempt will work at all, as I
have yet to start coding. But I think it will.

This solutions does not remove server-side coding, but it will (if it
works :-) !) remove the server-side storage. My technique is to store
the user information in JSON and HTML, and generate the editing
interface with JS, served always from my server. When the user clicks
"Save", the JS collects the data it needs, and POSTs it to the server,
which verifies the data and then serves up a new version of the page
with

Content-Disposition: attachment; filename="[name derived from
data].html"

Then with the browser file save dialog, the user can save this file
locally.

The file itself looks like this:

<html>
<head>
<!-- ... -->
<script type="text/javascript">
var model = // data as JSON
</script>
<script src="http://example.com/path/to/my/script" type="text/
javascript"></script>
</head>
<body>
<!-- ... -->
<!-- HTML version of model -->
<!-- ... -->
</body>
</html>

The script referenced will use "model" to populate the editing
interface. Users viewing the resulting HTML without JS will see a
rendered version of the data without being able to perform any
editing. Users with JS will have the full edit interface available.
People going directly to my site will see the editing interface with a
blank or a default model, and will have to create a new instance
before there's anything to save.

I don't think there is anything about this model that won't work, but
I've never seen an interface like this, which makes me worry a bit.
If there are problems with access, it should be easy enough to change
the server side to use JSONP, which might help. This is only a spare-
time project, and I haven't even started, so maybe there's something
fundamentally wrong with the concept, but I'm not seeing any obvious
issues with the technique.

Good luck,

-- Scott
From: Thomas 'PointedEars' Lahn on 5 Jan 2010 00:55
Paul Hovnanian P.E. wrote:
^^^^
Hmmm ;-)

> The user will load a 'form' from my website, which will load the required
> Javascript libraries using the src='....' attribute of various script
> tags.

Bad idea. Better "load" the "libraries" before. There are also no "script
tags", there are `SCRIPT' (HTML) or `script' (XHTML) elements, consisting
of start tag (e.g. `<script ...>'), end tag (e.g. `</script>'), and
optional content in-between.

<http://www.w3.org/TR/html401/intro/sgmltut.html#h-3.2.1>

> [...] After the user works with this app for a while, they will save
> the page to their desktop rather than submitting it to my site for
> storage. At some point in the future, they can reload the file they have
> saved locally and resume work. But this presents a couple of problems:
>
> 1) As long as the original page was loaded from my web site, the scripts
> will execute and subsequent XMLHttpRequests will work without any domain
> violations. But once the user has reloaded the page in work from their
> local file system, these operation result in security violations. Is
> there any way to bypass this?

Depends on what you mean by "bypass".

> 2) Saving the page (with modifications made to the object model by the
> user) doesn't result in those modifications to be saved. Only a copy of
> the original (unedited) page text gets saved to disk.

Depends, but usually that applies.

> What would work is some way to install a new handler for a browser's
> 'File|Save' event which could convert the edited data in memory back
> to text (XML, etc) and save that. s this possible?

Usually it is not.

> Basically, what I'm trying to do is too get out of the document storage
> business for my customers. While they are using this app, the data
> transferred to/from my back end application should only persist on the
> server for the duration of that transaction. Is Javascript even the right
> way to go for such an app?

Yes, server-side sessions allow this.

<http://www.catb.org/~esr/faqs/smart-questions.html>


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
From: Thomas 'PointedEars' Lahn on 5 Jan 2010 00:59
Scott Sauyet wrote:

> This solutions does not remove server-side coding, but it will (if it
> works :-) !) remove the server-side storage. My technique is to store
> the user information in JSON and HTML, and generate the editing
> interface with JS, served always from my server. When the user clicks
> "Save", the JS collects the data it needs, and POSTs it to the server,
> which verifies the data and then serves up a new version of the page
> with
>
> Content-Disposition: attachment; filename="[name derived from
> data].html"
>
> Then with the browser file save dialog, the user can save this file
> locally.

You could save the roundtrip if you rewrote the document based on its
serialization. But the user might need to trigger the "Save As" dialog
manually, depending on the runtime environment.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
From: Scott Sauyet on 5 Jan 2010 09:01
On Jan 5, 12:59 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> Scott Sauyet wrote:
>> When the user clicks
>> "Save", the JS collects the data it needs, and POSTs it to the server,
>> which verifies the data and then serves up a new version of the page
>> with
>
>>     Content-Disposition: attachment; filename="[name derived from
>> data].html"
>
>> Then with the browser file save dialog, the user can save this file
>> locally.
>
> You could save the roundtrip if you rewrote the document based on its
> serialization.

I've never tested to see whether "File > Save Page As" or its
equivalents save some version of the dynamically altered page or the
page as originally sent by the server. Even if the current crop of
browsers all save the dynamic page (and I'd be surprised, honestly), I
don't see that I could count on that behavior.


> But the user might need to trigger the "Save As" dialog
> manually, depending on the runtime environment.

And that's the real problem for me. I want the "save" action to be
part of the page UI and not depend upon the browser's chrome.
Although I've seen TiddlyWiki's [1] ability to save a file, I don't
want to get into the complexities of elevating the permissions that
they have to deal with.

Still, your suggestions might be just what the OP is looking for, if
the dynamic page is what's saved.

-- Scott
____________________
[1] http://tiddlywiki.com/
 |  Next  |  Last
Pages: 1 2 3
Prev: opacity and MS (one more time)
Next: What's a good license for My Library?