在 2017年04月18日 16:09, Roger Hågensen 写道:
On 2017-04-17 15:22, duanyao wrote:
This can handle multipage fine as well.
Anything in the folder test.html_files is considered sandboxed under
test.html
The problem is, what if users open `test_files\page2.html`or
`test_files\page3.html`directly? Can they access
`test_files\config.json`?
This is to be solve by the "muli-page application" convention. By the
way, the name of the directory is usually `foo_files`, not
`foo.html_files`.
Good point. But why would a user do that when the entry point is the
test.html?
The user may bookmark it and access it later on; the tab maybe restored
from a previous browser session;
the user may open it from the histroy list, and so on.
In this case the browser could just fallback to default behavior for
local html files.
Agree.
Alternatively the browser could have some logic that knows that this
is a page under the test folder which is the sandbox for test.html
Also your example of "test_files\page3.html" and
"test_files\config.json" ofcourse page3.html could access it, just
like it could access config.js if not for CORS on XHR and local files.
Maybe no. "files" is a generic word, so if you make every "xxx_files/"
folders magical, it's quite possible that there are folders happen to
ends with "_files" but are not intented to be local web apps. If you
require a `xxx.html` to make "xxx_files/" magical, it is a little
awkward and confusing for muli-page app.
This is why I propose a new (and unlikely already used) pattern
`xxx_webrun/` for more powerful muli-page app, and limit `xxx_files/` to
single page app.
In single page app case, it would be more common that `test.html` gets
`test_files\page{2|3}.html` via XHR and renders the latter in place,
instead of navigating to it.
So the latter don't need to access `test_files\config.json` themselves.
Actually a lot of the issue here is XHR (and fetch) not being possible
for local web pages.
The only reason I suggested using the same naming convention for the
sandbox folder is that (at least on Windows) Explorer deletes both the
html and folder something users are familiar with. Though I'm sure
Microsoft could add support for the same to another folder naming
convention, I can't see that being backported to Windows 8.1/8/7.
`xxx_webrun/` convention doesn't need OSes' support, just browsers'; and
you just delete that folder to delete the app completely.
I just checked what naming Chrome does and it uses the page title. I
can't recall what the other browsers do. And adds _files to it.
Chrome can be configured to ask for location when saving a page, then
you can name it as you will.
The "xxx_files" convention was introduced by IE or Netscape long ago,
and other browsers just follow it.
...
I have not tested how editing/adding to this folder affect things,
deleting the html file also deletes the folder (at least on Windows
10, and I seem to recall on Windows 7 as well).
There is no magic link between `foo.html` and `foo_files/`, this is just
a trick of Windows Explorer. You can change things by hand in that
directory as you will.
I just confirmed that. just creating a empty .html file and a same
named folder with _Files at the end does "link" them in Explorer.
Is this unique to Windows or does other platforms do the
same/something similar?
Probably just Windows Explorer. At least Nautilus file manager on linux
doesn't do the trick.
