Hi Nick,
One specific observation about this particular client: the uploaded KML file needs to have a URL that can be consumed by your mapping API—it needs to have a URL. Also, you need to watch out for caching when displaying the file—if a user uploads a new version of the file with the same name, the map may display the old version still. This is an issue with Google Maps and KML, but I don’t know about leaflet. Other things to look out for: file upload size limits and validation (is the file really a KML file?). Also, beyond the immediate proof of concept, it may be good to see if this connects with the Airavata MFT work. Marlon From: "Mowery, Nicholas Benjamin" <[email protected]> Reply-To: dev <[email protected]> Date: Friday, June 5, 2020 at 6:04 PM To: dev <[email protected]> Subject: [External] Re: Project Update and Questions This message was sent from a non-IU address. Please exercise caution when clicking links or opening attachments from external sources. Hi all, another update on the GeoGateway Django App. This week I've focused on state management with Vuex and developing a modular and lightweight method for adding KML map layers to the Leaflet map. I've opted to use Vuex to make communication between child components easier. I've also removed Vue as a CDN (in favor of Vue CLI + Webpack) and and fully separated the Vue frontend and Django backend. The boilerplate code is significant but I now have a stable development environment that can be deployed quickly. A question I'm considering: What is the best way to implement file upload in an Airavata Django app. Django has a relatively straight-forward method but it might not be the best in our case https://simpleisbetterthancomplex.com/tutorial/2016/08/01/how-to-upload-files-with-django.html Generally, I'm wondering if this problem should be handled locally by the application rather than communicating with Airavata. Some things I've learned: If the application is going to have more than 10 Vue components, implement a Vuex store from the start vue2-leaflet is not extensible enough for large GIS applications that require customized map layers Webpack configuration can be painful and a boilerplate for future Django + Vue + Webpack applications will be helpful Please reply with any comments or questions. Any recommendation regarding file uploads would be appreciated. Thank you! -Nick Nicholas Mowery Student of Computer Science and Philosophy Student Developer | CIRC | GSoC Apache Indiana University Bloomington From: Mowery, Nicholas Benjamin Sent: Thursday, May 21, 2020 5:51 PM To: [email protected] Subject: Project Update and Questions Hi all, This summer I am working on developing a GeoGateway Django app for the Airavata Django Portal. So far I have developed a skeleton of the app and integrated Vue.js for the frontend UI components. At this stage I'm looking for input on some of the choices I've made and if any of them should be adjusted. Leaflet and Vue.js (over Google Maps and React.js) It seems at this scale that a modular app rather than Vue.js style SPA makes more sense (although some of the other Airavata GIS applications are mostly SPA) There are a lot of style choices to be made and many I'm likely still unaware of, so any tips on structuring and organizing a project like this will be helpful. I also have a couple questions I've accumulated about Django for anyone willing to help: When working with a custom Django app in the Airavata Portal, should I redefine the MEDIA_ROOT directory in the apps.py file? Is there a precedent for changing variables like this defined in the project-wide settings.py file on a per-app basis? I'm finding that {% include .....html %} works perfectly but {% extends ....html %} does not. I use the block/endblock syntax with unique names but the content doesn't show up. Is there a reason I should use extends over include? Thanks for reading. -Nick Nicholas Mowery Student of Computer Science and Philosophy Student Developer | CIRC | GSoC Apache Indiana University Bloomington
smime.p7s
Description: S/MIME cryptographic signature
