Open dhlevi opened 6 years ago
Initial planning for the first cut at the export tool will be an exported "zip" of the client/viewer application code itself, with a pre-built configuration. It will be up to the exporter to integrate this with their own application logic (stand alone or as an embedded tool)
A new service endpoint has been added to the "Publish" endpoints for creation and fetch of the exported application. Calling {GET} /MapConfigurations/Published/{id}/Export enpoint will create a Zip file containing the Client application and the json configuration and attachments. Once created, the export will be saved as an attachment to the published version of an application in CouchDB. Only "Published" applications can be exported (app lifecycle: develop-publish-export).
Admin UI requires additional update to create the "Export" button on published apps.
@dhlevi @qqnluaq Is there a reason it's a WAR file as opposed to a ZIP? WAR implies enterprise Java archive.
@mraross @ll911 please take note.
Could we consider naming the HTML file within the WAR/ZIP "index.html" for ease of use/deployment?
If I drop the WAR file in my apache tomcat instance and start it, it explodes/deploys the WAR but I cannot call it easily unless I manually rename that file to index.html or another supported default name:
http://nc051110.idir.bcgov:8080/LMs/ note: this tomcat instance is not always running as it is on my laptop
The extension is war, mainly because we just copy the name of the client package deployment. It can be changed to zip if preferred.
Regarding the index, it was created via java temp file which adds extra unique characters. We'll update the service to clean the name up so by default you get a single index.html in the zip.
zip is preferred. since static web files can be simply served via regular web server.
Create functions in the admin tool (and service if required) to allow for the export of a configuration into a stand-alone application.