Passing additional uploaderOptions to DropZone

[damanic]

DropZone supports a number of options, why aren't these options being passed through init ?

The issue can be seen here:

    FileUpload.prototype.bindUploader = function() {
        this.uploaderOptions = {
            url: this.options.url,
            paramName: this.options.paramName,
            clickable: this.$uploadButton.get(0),
            previewsContainer: this.$filesContainer.get(0),
            maxFiles: !this.options.isMulti ? 1 : null,
            headers: {}
        }
...
   this.dropzone = new Dropzone(this.$el.get(0), this.uploaderOptions)

Only two options are passed through to Dropzone directly on init

• url
• paramName

This plugin would be more flexible on frontend if we could pass dropzone options as part of the fileUploader init.

Use case Example: I want my single image uploaders to offer more than one clickable upload element, and I would like to override the default onClickSuccessObject behaviour. This would be easily done if we had a more flexible constructor and some events that allow default behaviour to be overridden.

Example of how one might expect to implement this on construct:

        var singleImageUploader = $('.singleImageUploader ').fileUploader({
            isMulti : false
            dropzoneOptions : {
                clickable : [ '.button', '.image-container' ]
            },
        });

        singleImageUploader .on('onClickSuccessObject', function(ev){
             //do something other than opening the uploaded file in a new window
        });

I cant see a straight forward way to do this using the fileUploader as is. Have I missed something, or is the fileUploader obj being unnecessarily restrictive?

[LukeTowers]

My guess would be because then we'd have to always support all of dropzone's options, even if at some point in the future we dropped it.

[damanic]

Regardless of DropZone dependancy, the main issue is that there is no clear way to set which elements trigger the open-file-browser event, because it is locked to a specific button class. In the singleFile instance this button class is also subject to show/hide states, so for a singleImage implementation we end up with:

1. The upload button is hidden once an image is uploaded
2. Clicking on the uploaded image will open that image in a new browser window

Both of those are undesirable when you want the container for an uploaded image to continue to be replaceable by drop or click.

I found it frustrating that the clickable parameter could not be easily overridden

clickable: this.$uploadButton.get(0),

And also this event which makes all the uploaded file containers click through to the file URL: onClickSuccessObject

As a developer tool, it would be helpful if these behaviours were more easily overridden.

[LukeTowers]

@bennothommo I haven't had the time to properly think about this issue yet, do you have any initial thoughts?

[bennothommo]

@damanic @LukeTowers to be honest, I think if you need a high degree of flexibility with how the Dropzone widget works on the frontend, I would recommend just copying the plugin and customising it to your needs. I think the idea of this plugin (and the FileUpload widget itself in the backend) is to provide a controlled, user-friendly experience of managing the uploads, easily configured through PHP / Yaml. I'm not sure about the "cleanliness" of having JavaScript fed through PHP or Yaml files.

Perhaps a JavaScript event could be fired on configuration which gives people access to the config and necessary elements.

[damanic]

@bennothommo

RE:

I think if you need a high degree of flexibility with how the Dropzone widget works on the frontend, I would recommend just copying the plugin and customising it to your needs.

I am recently getting back into OctoberCMS for a project, and this is something I am coming to realise. When Plugin components present through partials that can be overridden at THEME level, there is great potential for custom presentation and UI. But in practice I find that I am having to copy plugins or components because the JS/AJAX actions provided to the components are too restrictive. Sometimes there is good enough reason, but other times its because the plugin was built to support the provided component output with little to no thought given to customisation.

In this case the Uploader plugin offers a straight forward service to handle uploads, and leverages a flexible JS library in DropZone to provide the front end interaction. So I find it hard to understand why one should have to copy the plugin to access what is available here.

If I am going to copy this plugin, all I need to do to progress my project is:

Turn this

clickable: this.$uploadButton.get(0),

to this

clickable: this.options.clickable

And facilitate the override of the action:

onClickSuccessObject

Is it worth me submitting a pull request for these revisions?

[bennothommo]

@damanic I definitely get ya - I've encountered that myself recently with the Dashboard widgets functionality and its JavaScript. One simple change to a configuration option (in JS) was almost impossible to make without overriding the core JS, which is obviously not ideal.

I have come up with a more "graceful" way of extending JS assets, which I hope to have written up in the next few days as a tutorial. I'll post it here when I do, if it's of any use to you.

As for submitting a PR for this, I'd say go for it, just keeping in mind what I said about JS being fed through Yaml or PHP files. I don't have any control over this repo, but I'm sure @LukeTowers can go over it when he has a chance.