skoczen/django-ajax-uploader

Ideas for adding different upload client options

Opened this issue · 4 comments

There are a couple promising projects w/o commercial licensing issues, such as fine uploader. These would make great replacements for the outdated fileuploader.js / fine uploader. I'm thinking a simple sub module in the js folder may suffice.

Vanilla:
pluploader - im pretty sold on this actually.

jQuery:
Blue Imps File Uploader
DropZone

... probably 10 different alternatives i haven't bothered tracking down/listing.

I understand you're busy, so dont worry about expediency in your replies. Just letting you know what i'm currently working towards in an effort to make a PR easier later.

I am conceptualizing the best way to include a more fully featured javascript file uploader, maybe even including multiple projects. I may find the widen licensing too expensive / unreasonable, but others who want to use this project may not.

There are three different ways to solve this as far as I can tell.

  1. Submodules: Add submodules for the respective projects, and structure them in such a way that we can build specific versions of said project, and build them in ./ajaxuploader/static/js/{project_build}, packaging them up w/ pypi as we see fit. This seems like a clean way to do it, most anyone who has familiarity with building software should find this intuitive. However, there will be a slight learning curve for building each of the respective projects. i.e. Pluploader uses JakeJS while fineuploader uses grunt. However, most of the difficulty will be in the initial integration points w/ these apps. Once we get them building the way we want, it should be very low maintenance.

  2. Browserify: We can theoretically bundle up whatever plugins we want, however we want, with browserify. I have zero experience with this, but it would probably get the job done. It may even have some use with the above scenario.

  3. Bower: It may be interesting to just leverage bower somehow. Instead of submodules we include a bower file. Not sure what inherent benefits or limitations there are here.

I am planning on doing 1, and should have a PR soon, but i figure it'd be good to show the other options i've considered.

I'm a +1 to supporting other uploaders, a +0 to requiring people to use bower/etc, and also a +1 to continued support for fineuploader. The programmer who wrote it (and it's still, to my mind, the best one out there) made a great open source project, and now is trying to make a living at that. I'm 100% behind supporting projects like that.

In short, I'd say if we can simply and easily bundle in another option, and provide a way for users to have something that just works out of the box, I'm all behind that.

Thanks for all your contributions!

Regarding Bower:

There is a way to leverage bower for development w/o requiring end-users to use it. In short, this project could have a bower file, and when you go to build the project we would $bower install and include the bower files in the project. However, I think the submodule is the better option.

I'm a +1 to using bower for dev and packaging on the plugin side, that makes total sense.

-1 to submodules, just based on past experience. They were a nightmare to deal with when things got weird/stale.