turkle
turkle copied to clipboard
hltcoe
Allow per-project static file uploads
This is one possible solution to a common issue, but I'm not certain it's the right solution. Feedback appreciated!
Turkle, like Mechanical Turk, only allows a single HTML template file per project. While third-party libraries (jQuery, Bootstrap) can be accessed via links to third-party CDNs, any project-specific CSS and JavaScript needs to be in the single HTML template file. There is no support for project-specific image files.
When Turkle is used offline machines, the third-party CDNs are inaccessible, and users need to resort to things like copy-pasting entire jQuery libraries into an HTML template.
If a web application is built using a framework like React, there are potentially a lot of project-specific CSS and JavaScript files, and copying the contents of these files into a single HTML template adds complexity to the development process.
One way to address these copy-pasting issues is to allow Turkle users to upload static files that are tied to a specific project. In order to prevent path collisions, we would need to introduce a new Turkle-specific template variable - e.g. $TURKLE_STATIC_PATH. When the template is rendered, the Turkle template variable would be replaced with with a Django-generated, project-specific URL prefix.
This behavior would obviously diverge from MTurk's behavior, but could make it easier to support offline environments.
CC: ccostello dpennell vandurme
Poster: Craig Harman id: 143
including them as static files is one option, but couldn't we just host them somewhere else accessible and link to that instead of the external CDN? Then we don't need to include a static file in every app we release. I'm pretty sure that's what we are doing for other apps.
Ok, I guess reading your email you just sent, even if we did this we'd have to edit the files to point to our thing before releasing so it doesn't actually help.
Poster: Deana Pennell Burchfield
That approach seems like it would work well for stable third-party libraries. Turkle currently comes with a copy of jQuery that you can link to from templates (though, as Cash discovered the other day, this can cause paths to break if you move the Turkle Django app to a different relative path).
The use case that prompted this issue was an app that a grad student created using React.js. Changing a React app's functionality can involve updating half a dozen different CSS and JS files. If multiple people create HITs with complex UI's built on frameworks like React, there's the risk of name collisions if we don't put CSS and JS files in project-specific sub-directories.
Poster: Craig Harman
Is there standalone CDN-like package that we can recommend be used alongside Turkle so that we don't have to manage this?
Template builders/deployers are encouraged to first upload their libraries using a standardized naming scheme based on library/version similar to CDNs (and maybe the local CDN is just a proxy to a external CDN).
I do think we should strongly discourage linking directly to the static libraries included in Turkle (or really cheating by shoving the library you need into Turkle when Turkle doesn't need it!).
Poster: Cash Costello
There are a variety of different Django packages related to uploading and managing files to a server:
https://djangopackages.org/grids/g/file-managers/
Taking a step back from my original proposal for modifying the turkle repo, I'll consider a much more specific use case:
For researchers who are using turkle.hltcoe.jhu.edu, I would like to offer them an easy way to upload project-specific static files using their existing Turkle usernames and passwords.
One approach to this would be to create a separate repo that contains a separate Django app (but not a Django site) that handles file uploads and permissions. On the turkle.hltcoe.jhu.edu site, I could install this Django app as a Python package and then modify that Turkle installation's settings.py file to add this new Django app to the existing Turkle site. The functionality for uploading files would now be available through the Django admin portion of the existing Turkle site. This would allow CDN-like functionality on the turkle.hltcoe.jhu.edu server without any changes to the Turkle codebase.
Poster: Craig Harman
charman That sounds like a good solution for COE. You'll still have to work out whether you want a sitewide CDN that uses name/version or avoid conflicts by limiting CDN access by project. I would tend to avoid the tighter integration with projects and require name/version as unique identifier...and also make it really easy to see what packages are currently available from the CDN to encourage reuse.
Poster: Cash Costello
charman I've been thinking a little about writing documentation for creating templates. I'd like to say something about referencing static files. I guess for now I should say that the template builder should use CDNs, host their own resources or embed the static resource, correct?
Poster: Cash Costello