Funbit / ets2-telemetry-server

ETS2/ATS Telemetry Web Server + Mobile Dashboard
GNU General Public License v3.0
628 stars 209 forks source link

Import Additional Javascript #64

Closed mike-koch closed 9 years ago

mike-koch commented 9 years ago

Is there a way to easily import additional Javascript source files (either via HTML or JS) into a skin? I've tried using:

$.getScript('myJavascript.js')

However, since the URL is relative, the path becomes something similar to http://localhost:25555/myJavascript.js, instead of going to the skin's directory (I'm assuming this is due to how the server is written). Additionally, I cannot assume the skin name will be the same as users can change it.

That being said, are there any helper functions that can assist in importing additional Javascript files?

denilsonsa commented 9 years ago

Alternatively, et2-telemetry-server could provide a "shared" folder, available for all skins.


Context: in ets2-mobile-route-advisor#2 we were able to slice up the map you made into 7381 tiny images and serve them in user-friendly map UI. The next step is putting the map inside a skin.

However, other people might also want to make skins containing a map, so instead of copying all images and JavaScript files to each skin, such assets could be stored in a shared folder, available for all skins.

(even better if we could store all the images inside a ZIP file, and the server could serve them from the ZIP; but that requires more work)

Funbit commented 9 years ago

@mkoch227 You may try to load the script inside "initialize" skin's function using skinConfig.name property to construct the full path, i.e.: "/skins/{skinConfig.name}/myJavascript.js". Just as a temporary solution.

@denilsonsa I'm very glad that you guys managed to create a tiled version of the map! As for the shared folder suggestion, I'll try to come up with something this weekend, probably will add support for a shared map and additional javascript/css files defined inside skin's config file. I'm not sure that ZIP support would worth it, we're living in the world where it does not matter if a folder is 5mb (zipped) or 10mb (unzipped).

denilsonsa commented 9 years ago

Regarding the suggestion of zip support: sure, 32.8MB of disk space instead of 8MB is not a big deal. The issue is that some systems struggle when working with thousands of tiny files. My windows system takes a while to create/copy them. At the same time, it is done only once, so it's not a big deal anyway.

(Zip support is still something "nice to have", but only if implementing such stuff is trivial, if you have a library to directly read files from zip archives.)