Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ideas for adding different upload client options #70

Open
derek-adair opened this issue Mar 18, 2015 · 4 comments
Open

Ideas for adding different upload client options #70

derek-adair opened this issue Mar 18, 2015 · 4 comments

Comments

@derek-adair
Copy link

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.

@derek-adair
Copy link
Author

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.

@skoczen
Copy link
Owner

skoczen commented May 29, 2015

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!

@derek-adair
Copy link
Author

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.

@skoczen
Copy link
Owner

skoczen commented Jun 3, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants