#160: Overhaul FileUpload Widget

Contents

1. Definitions
2. Motivation
3. Assumptions
4. Proposal
5. Implementation
6. Deliverables
7. Risks
8. Progress log
9. Participants

Proposed by

Alan Runyan

Seconded by

Dorneles Treméa

Proposal type

User interface

Repository branch

UploadReferenceWidget

State

draft

Definitions

Motivation

Today in Zope/Plone File-oriented assets are *embedded* into the content object.  This makes a variety of problems more difficult to solve than should be:

• Re-using file assets that are embedded into a content object.  There is no way to 'browse' to these file assets. 
  
• These file assets may not be first class content citizens therefore they may not have UIDs.  Meaning you can not easily reference them.
• Content import/export would be easier if they were decoupled and represented as relationships instead of attributes of the content object.

Plone does very little about directing users on how to store and handle file oriented assets. As side effect of this proposal is to suggest a central place to put file oriented assets.  This has numerous benefits itself:

• Gives users a central folder where file oriented assets should be placed (reduces end users thinking process)
  
• Enables us in the future to incorporate components such as 'Image Repository' since we know where all the file oriented assets should be residing in a default Plone installation
• We could mount this Folder as a separate Database in which we can have a finer grain control over memory usage and performance characteristics

Tomorrow we will need this decoupling.

• Sophisticated deployment techniques such as Entransit Content Deployment or CMFDeployment find it very hard to represent and maintain these 'asset relationships'.  These are solvable problems but as the deployment techniques become more complex we will be unnecessarily carrying baggage.
• Content import/export will be much easier to implement especially if content has 2 or more file asset properties in a content type.
• Users expect to be able to re-use *all* content.  If I upload a logo into a News Item last month and want to reuse that logo this month.  I should be able to do that easily and efficiently. 

Assumptions

Proposal

This would introduce a backwards incompatibility issue.  The client code would have to be changed anytime Field specific calls are being made.  For instance the 'scaling' properties of the ImageFiled would not apply.

Development

• The UploadReferenceWidget development will be moved from Enfold System's public subversion, located at https://svn.enfoldsystems.com/public/UploadReferenceWidget to Archetypes SVN repository into the MoreFieldsAndWidgets folder, located at https://svn.plone.org/svn/archetypes/MoreFieldsAndWidgets/
  
• The User Interface of the UploadReferenceWidget should be reviewed, some questions:
• Should the 'Reference List' be visible when uploading Files?
• Should you be able to remove the target object from the Widget?
  
• Determine what a sensible default would be for location of Uploaded assets.  Currently the assets are contained in the content object.  This widget ensures the assets are uploaded as first-class content objects in the Plone CMS.  Where do we put those?
• One suggestion create a BTreeFolder called 'files-and-images' in the root of each Plone site.
• In the future this 'files-and-images' folder could be converted to a 'Image Repository' product from PSOL.
  
• Identify all of Upload Widget(s) used in Content Types outside of File/Image.  The list of affected default content types:
• News Item

• Assign Copyright to the Plone Foundation

Evaluation

1. The introduction of this widget should add ZERO conceptual overhead for a end user.
2. The software should be bundled into a software release on plone.org and available to the public [DONE]
3. A 'demo' of the Widget should be provided (This comes along with the source code) [DONE]
   
4. Identify and set a default policy for 'files-and-images' to be used.
   

Packaging

Migration

This is going to be the largest chunk of work.  Here is a plan of attack:

1. Identify the location for uploaded assets to be placed instead of inside of content objects, i.e. 'files-and-images' location
   
1. Create this folder in new versions of Plone
2. Figure out the structure (if any) for this Folder, files-and-images
   
2. Change the affected content types from using FileField or ImageField to using ReferenceField
1. ATContentTypes.content.newsitem.ATNewsItem would need to change from using ImageField
2. This means that there needs to be compatibility or a break in compatibility since ImageField supports a different API than ReferenceField.
   
3. Write migration script that yanks out the Image/File data from content types and creates new content instances in files-and-images location
   which will then be referenced in the source content types such as News Item.
4. Wire the migration script into the Plone migration routines
5. Bundle the UploadReferenceWidget with the Plone distribution
   

Integration

This widget is 100% compatible with ReferenceBrowserWidget(s) and ReferenceField.

Implementation

Download UploadReferenceWidget: http://plone.org/products/upload-reference-widget

A specialization of the ATReferenceBrowserWidget.  It is a new Widget not a new Field.

Deliverables

A new ReferencableUpload Widget would be implemented [DONE]

ATCT NewsItem would use the ReferencableUpload so that BLOBs can be shared between News Items

Migration Script

Release Copyright to Plone Foundation

Risks

Introducing a new Widget is minimum risk.

Implementing it for ATNewsItems, by default, requires migration.

Progress log

The initial code has been released and is being used in production. 

Participants

• Dorneles Treméa
• Alan Runyan