This gist will become a bloop in https://github.com/thomsonreuters/CM-Well/tree/master/blps once we have conclusions. For now this is only thoughts...
Dan pointed out (CM-Well/CM-Well#97) we have an inconsistency when navigating using a webapp to a FileInfoton and then refresh the page. First, let's agree on four axioms:
- SPA navigation should be aligned with browser history.
- An ObjectInfoton, when requested without
formatquery parameter, is wrapped with the default webapp. - A FileInfoton, when requested without
formatquery parameter, is returned according to its mime-type ("as is"). This imatate the behavior of a "regular" webserver providing static content as files. - CM-Well has two built-in webapps, one is default, but they are only FileInfotons ingested upon an install/upgrade. Anyone can upload their own webapp. In other words, the UI is pluggable.
The inconsistency was inevitable when implemeting (1) and (3) straightforward...
Assuming we love those featrues in CM-Well and not willing to modify them whatsoever, we are going to need to add a trick. Here is our suggestion (after a short discussion with @hochgi):
A CM-Well webapp will artificially add a query parameter to the URL when navigating to a FileInfoton, such that when refreshing the page (or sending that URL to a peer), CM-Well will wrap that FileInfoton with that webapp, as if it was an ObjectInfoton.
Suggested API: ?format=webapp(<WEBAPP_PATH>) e.g. /example.org/subfolder/file.zip?format=webapp(/meta/app/main).
A syntactic suger might be to omit the paranthesis when asking for the default webapp (i.e. ?format=webapp).
Sounds great, no? Let's talk about a potential implementation problem. A nice thing CM-Well does when wrapping a requested Infoton with a webapp is to return its data along with the markup of that webapp's entry point. This works becuase WS component and built-in SPAs have an API between them. It is called an "Infoton Island" and it looks like this within the HTML: <inject>(JSONL formatted Infoton)</inject>. So it saves an ajax to the webapp.
The important thing to notice here, is not the ajax that is saved, but the knowledged transferred into the client side regarding the requested (wrapped-in-a-webapp) Infoton. At least its path.
Once we add this format=webapp(...), some custom webapps might not play along with our <inject> API. In other words, we need a well-known API to transfer the knowledge of the requested Infoton, if not the whole thing at least its path.
Can we agree that any custom webapp will respect our <inject> API?
I can't think of any easy way to transfer that information other than the response body. HTTP Response Headers are not accesible in JavaScript for the initial response, they are only avialable for JS-initiated XHR Requests. And we cannot modify the requested URL as well.
What do you think?