forms icon indicating copy to clipboard operation
forms copied to clipboard

Integrate with DocumentManager/FileUploader

Open jlsjonas opened this issue 6 years ago • 16 comments

This is a feature request.

Prerequisites

  • [x] Are you running the latest version?
  • [x] Are you reporting to the correct repository?
  • [x] Did you check the documentation?
  • [x] Did you perform a cursory search?

Description

Allow adding a "document" type to the form builder; integrating with (parts of?) DocumentManager//fileUploader to allow easily saving a specific document/image along with a form/model

jlsjonas avatar Aug 21 '18 10:08 jlsjonas

I'm assuming this is currently not a priority right now?

Could you point me in the right direction to implement this in the framework (places/sub-projects that will definitely have to be modified to properly support this) I'll look into making a PR for it in that case (we need to add images to a form)

Alternatively, if the framework regarding images/documents is changing soon, I'll resort to a custom object instead.

jlsjonas avatar Oct 17 '18 08:10 jlsjonas

This is a very nice feature and I want it added as soon as possible. The reason it was left behind is because we didn't had the time to really think it through.

Let's use this issue to discuss what the expectations are.

@gandesc please add your suggestions here.

From the FE point of view it can be a nice file field with and upload button with its presence controlled from the json template. It should have a multiple option.

But once we upload one or more files, what do we expect from this field to be visual represented in the edit form? How will one file/more files be displayed?

About behaviour:

  • do we want additional controls, like the ability to delete file(s) from the field?
  • at what moment the file(s) should be persisted? Once the upload is done? Or when we click the Store/Update actions?

From the BE point of view, what are the implications regarding the current FileManager, and so on.

aocneanu avatar Oct 17 '18 08:10 aocneanu

I think the best strategy from the FE perspective is to include a "content"-like option, or create 2 type fields to differentiate between images & files.

EDIT: a specific max filesize / filetype option would also be recommended

Images

  • use a thumbnail-like grid as the upload button/dropzone
  • (preview of) images replaces the thumbnail visually
    • multiple: the upload zone moves to the right. (prepend the image instead)
  • the top-right of (each) image preview should contain an x to remove the image from the upload queue

Files

Similar to images, but using a list instead of thumbnails, and I would keep the upload zone row fixed at the top instead. each preview (row) should ideally contain:

  • an icon indicating the file type
  • the file name, cropping in between if the width is insufficient (i.e.: con...456 vs. concep...)
  • an x to remove the file from the queue

Behaviour

(in my opinion, of course)

  • Deleting files should definitely be possible (in a later stage perhaps allowing an alias?)
  • persist should happen when clicking Save/Update, as would be expected from a form (in a later stage perhaps provide the option to upload the file to a temp folder to increase fluidity; however this should remain an option

jlsjonas avatar Oct 17 '18 09:10 jlsjonas

I think the best strategy from the FE perspective is to include a "content"-like option, or create 2 type fields to differentiate between images & files.

sounds good.

EDIT: a specific max filesize / filetype option would also be recommended

filesize seems ok, but for filetypes we will stick with the above (content) and do extra validations on the back-end

Images use a thumbnail-like grid as the upload button/dropzone (preview of) images replaces the thumbnail visually multiple: the upload zone moves to the right. (prepend the image instead) the top-right of (each) image preview should contain an x to remove the image from the upload queue Files Similar to images, but using a list instead of thumbnails, and I would keep the upload zone row fixed at the top instead. each preview (row) should ideally contain:

sound good.

an icon indicating the file type the file name, cropping in between if the width is insufficient (i.e.: con...456 vs. concep...) an x to remove the file from the queue Behaviour (in my opinion, of course)

can be a future development

It would be cool if you could find/post some pics as examples, maybe found nice implementations elsewhere.

aocneanu avatar Oct 17 '18 12:10 aocneanu

filesize seems ok, but for filetypes we will stick with the above (content) and do extra validations on the back-end

Sounds good (though for "files" it might be really useful (limit to .pdf, .csv, ...) )

can be a future development

👍

Inspiration

Images

my original thought (quick mockup): pre-upload: image

after a couple uploads: image

extra inspiration (dropzonejs):

files

some combination of these (with a clean enso-look)

jlsjonas avatar Oct 17 '18 12:10 jlsjonas

Also note that --ideally-- clicking on the image preview shows a bigger (modal?) view of it

use case: form edit being used by another user than the one creating the form; wanting to inspect the uploaded pictures

jlsjonas avatar Oct 22 '18 10:10 jlsjonas

https://rowanwins.github.io/vue-dropzone/docs/dist/index.html#/custom-html looks like a great implementation example, btw; perhaps it can be used instead of recreating the wheel? (their github seems active)

They do seem to be handling the upload part internally, and for swiftness I think it wouldn't be a bad idea to just have the dropzone upload files (filemanager) and then saving the attributes/id's with the form itself.

as for the editing part: it does support programmatically loading in data

jlsjonas avatar Oct 30 '18 08:10 jlsjonas

looks fit.

aocneanu avatar Oct 30 '18 08:10 aocneanu

apparently makes more sense to build a custom wrapper around https://www.dropzonejs.com/

aocneanu avatar Oct 30 '18 08:10 aocneanu

vue-dropzone (linked above) looks like a better fit though; it's already in Vue & has closer feature-parity to the implementation features above (deleting; slots for styling; already a vue component; ...) but I'll let you decide what you seem more fit. (if I compare the docs I'm pretty sure vue-dropzone includes all options that make sense as props/similar; so either should work)

EDIT:

there's an options prop that accepts all valid dropzonejs options; along with that vue-dropzone has s3(-compatible) upload capabilities; which is used quite often in modern development to distribute/reduce server load

jlsjonas avatar Oct 30 '18 09:10 jlsjonas

I've noticed that Dropzone got added last week; is this feature (partially) implemented that are just missing docs? or is it just preparations that had been made? I can definitely help with testing/finalizing if useful.

jlsjonas avatar Nov 15 '18 12:11 jlsjonas

it's WIP and will take some time.. I'm working at rewriting some other features with higher priority

aocneanu avatar Nov 15 '18 12:11 aocneanu

Ok, no problem; was just curious.

I've been noticing the great work being pushed recently ;)

jlsjonas avatar Nov 15 '18 12:11 jlsjonas

Is this still planned?

curtisdelicata avatar Sep 01 '20 19:09 curtisdelicata

Hi @aocneanu,

I just started to create the same issue but luckily I found this existing one.

Can you please give me a quick update for this feature? I would need it for my project too. Thx.

mauthi avatar Nov 27 '20 15:11 mauthi

Hi @aocneanu,

Hope you are doing well?

Do you maybe have any update for this if this is still planed?

mauthi avatar Feb 26 '22 14:02 mauthi