forms
forms copied to clipboard
Integrate with DocumentManager/FileUploader
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
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.
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.
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)
- multiple: the upload zone moves to the right. (
- 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
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.
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:
after a couple uploads:
extra inspiration (dropzonejs):
files
some combination of these (with a clean enso-look)
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
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
looks fit.
apparently makes more sense to build a custom wrapper around https://www.dropzonejs.com/
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
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.
it's WIP and will take some time.. I'm working at rewriting some other features with higher priority
Ok, no problem; was just curious.
I've been noticing the great work being pushed recently ;)
Is this still planned?
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.
Hi @aocneanu,
Hope you are doing well?
Do you maybe have any update for this if this is still planed?