Hi,
I'm also still not comfortable on this point, partly because it means one only appcache file per app / package
The appcache manifest, when defined per page as via the html manifest attribute (http://www.w3.org/TR/html5/semantics.html#attr-html-manifest) allows more modular handling of the appcache properties of a web application.
Not all Web applications, even mobile ones, are single page applications. Think a page as an application interface module.
If we might fix the issue by replacing the string format by
1 - an array of objects as
appcache_paths: [
{"page": "/main.html", "manifest": "/main.appcache"},
{"page": "/special.html", "manifest": "/special.appcache"}
]
2 - a object in which the keys are the page paths
appcache_paths: {
"/main.html": "/main.appcache",
"/special.html": "/special.appcache"
}
I still have issues when working on an interface organized as a git submodule:
- any update to this application module will have to be pushed to the manifest of the main application repository;
- such updates will have to take care of the main web app repository merges
- the module is definitely not testable in standalone mode
Worst, if this git submodule is used by different web apps, it becomes hard to push updates to all apps using it.
On 22 avr. 2013, at 14:33, Min, Hongbo wrote:
Marcos,
I noticed that the manifest JSON is also providing an ‘appcache_path’ member. I am wondering its purpose since web app can specify the appcache manifest URL in the web page like:
<html manifest=”example.appcache”>
…
</html>
Why not use the manifest attribute in html tag and re-invent a new one?
Thanks
Hongbo
[cid:eecd0a.png@3434bd54.40ae095a]
Alexandre Morgaut
Wakanda Community Manager
Email : Alexandre.Morgaut@4d.com<mailto:Alexandre.Morgaut@4d.com>
Web : www.4D.com<http://www.4D.com>
4D SAS
60, rue d'Alsace
92110 Clichy - France
Standard : +33 1 40 87 92 00
