One File-Field (Type) to rules them all

[loechel]

PLIP (Plone Improvement Proposal)

Responsible Persons

Proposer: Alexander Loechel

Seconder: Paul Roeland

Abstract

If we look into modern file types from a higher position, it doesn't make a lot of sense to only differentiate between two types: Bitmap-Images and everything else. One Field type is more than enough, and could differentiate between the actual mime-type how to handle.

Motivation

If we look on file types today, we do see a lot of different file types, even if we cluster them, we do see those clusters:

• interpretable binary files:
  • bitmap-images (e.g. png, jpg, ...)
  • container formatted files:
  • bitmap-images (e.g. gif, tiff)
  • videos files (e.g. mp4, avi)
  • audio files (e.g. mp3)
• text-oriented files:
  • vector-images (e.g. svg, eps)
  • Documents (e.g. pdf, docx, ...)

Why do we only differ between bitmap-images (threat them as single framed) and binaries of all other kind? We could change that and make the file field / blob file field in plone.namedfile more generic and eliminate the image fields. Handle all in one file field format and apply different file handler to that field. For example Image-Orientationl, Scaling, streaming, ...

Assumptions

Proposal & Implementation

The proposal is to deprecate the specialised fields NamedImage and NamedBlobImage and use the bases NamedFile and NamedBlobFile instead, and let that single base field handle all special Cases.

Deliverables

• a plone.namedfile 5.X release with deprecation warnings
• a plone.namedfile 6 release with changed implementation so that the Images are handled by the file fields.

Risks

Participants

• Alexander Loechel (proposer and implementer)
• Paul Roeland (willing to review user story/UI)

[tisto]

I am in general in favor of simplifying the content types of Plone. We actually considered this for Volto as well. Though, taking into account our experience with simplifying content types in Volto I'd like to stress the fact that it is easy to forget side-effects of getting rid of content types. e.g. what if an editor wants to create a collection with all images on the site? Adding an "image" tag to the file might not be the best way to solve this. Then you have to create another way of marking and/or indexing files/images which works in collections and listings.

I would be open to trying out some of those ideas in Volto first. We are still experimenting there with getting rid of other content types, so that might be a good place to start.

Though, I would suggest to re-visit the Risks part of this PLIP and think about possible side effects.

[loechel]

@tisto thanks for your comment. Please be aware, that the proposal is to change the underlying Field not the Content Type system itself.

Even if you unify the Field system you could have both a dedicated Image Content Type and a File Content Type. Both would allow to store all kind of files, as it is already today, for the File Content Type. So if you argue on the Content Type Level, it would make sense to set a Marker Type depending of the MIME Type of the file, which could be:

• Image,
• Audio/Video,
• Binary-Files,
• Text-Files,
• ...

If you talk about side effects, that would change something for several other content types as well, as you either need to limit the file by a validator to one of those Marker Types or to special MIME-Types. For Example a Lead-Image does not make sense to be a binary-file.

Also there should be conversions for non Web-Images to render in a Site, e.g. EPS to SVG or PNG.

I think this PLIP needs some more discussion. But could be a good starting point for some more cleanups.

[tisto]

@loechel ok, I got that wrong then. So I am definitely +1 to explore this further, discuss it and work on an example implementation. Thanks for clearing that up. We will discuss this again at the next @plone/framework-team meeting.

[frapell]

Big +1 from me on this... We all understand the reasons behind having 2 separate content types between images and files, but it is often confusing for editors and end users... In my opinion, there should be just 1 content type "File" that would accept any type of file, and then we can mark the file however we like in order to provide the different functionality, totally transparent for the user... Just my 2 cents...

[ale-rt]

Just a note that might be useful: the folder contents dropzone already provides a way to automagicaly upload files or images in the same place.

Then the content is created according to some code that has a comment asking for a better implementation: https://github.com/plone/plone.app.dexterity/blob/badd6839a6ae5381b441a839deecb67615705d5e/plone/app/dexterity/factories.py

[jensens]

I really would like to see this one implemented. Indeed, the dropzone is convenient, but it is just a workaround for the current situation. We had so many discussions already in the past about this, first ones dating back >10 years, but at the end the outcome was: Yes, we want one field and one portal_type, but wow, its a whole bunch of work to implement it - also if it comes to transformation, unique display, preview images i.e. from videos and so on. Its not more difficult than with several types, just it gets more complex and must be unified and has to get an API.

[ebrehault]

@loechel the FWT approved this PLIP