Changes between Initial Version and Version 1 of FileUploadAndDownload

Timestamp:

Mar 25, 2009, 1:30:38 AM (15 years ago)

Author:

simonp

Comment:

--

FileUploadAndDownload

@@ +1 @@
+= Proposal number : ? Proposal title : File Upload and Download =
+
+|| '''Date''' || 2009/03/23 ||
+|| '''Contact(s)''' || Simon Pigot ||
+|| '''Last edited''' || [[Timestamp]] ||
+|| '''Status''' || draft - complete in BlueNetMEST sandbox ||
+|| '''Assigned to release''' || 2.4 ||
+|| '''Resources''' || Available ||
+
+== Overview ==
+
+File Upload: In the 2.2 editor: File Upload submits the form with the uploaded file and saves all changes made to the record together with the file. There are two issues with this:
+
+ * If there is an error on upload (eg. file already exists or exceeds the maximum size allowed in the config.xml file) then it is difficult to give a useful error message back to the user because the upload service forwards to metadata.edit.
+ * Changes must be saved and a filename specified before the upload button will appear - this understandable from an HTML form point of view but somewhat strange to users.
+
+The proposal is to separate the submission of the file upload from the editor - a new service resources.prepare.upload is added which displays in a modalbox dialog (JavaScript Modalbox widget) overlaid on the editor screen, accepts the name of the file to input and supplies it plus the required parameters to the file.upload service, displays any errors and sets the value of the filename into the editor form.
+
+File Download: In 2.2 files are downloaded with a call to the resources.get service or if feedback is required on the reasons for download then a call is made to file.disclaimer. Choice of method can be set by changing the URL builder in update-fixed-info.xsl for the metadata schema in use. In some cases though:
+ * specific constraints on the resources attached to a metadata record can be defined in the metadata record itself (eg. resourceConstraints in the Data_Identification section of ISO19115) and users of resources may be required to agree to or view these constraints before downloading a resource attached to the metadata record. 
+ * there may be multiple resources attached to the record and a user may be interested in downloading one or all without having to view and accept the constraints
+ * the metadata record with the embedded constraints may need to be supplied with the resource(s) being downloaded as a record of the constraints
+
+The proposal is to:
+
+1. enhance the file.disclaimer service to display resourceConstraints from ISO records if present (otherwise fall back to the existing usage of global fields from strings.xml)
+2. add a file.prepare.download service which extracts resources from any metadata record and allows the user to select those that are required for download - this is run when the download button is pressed and there are multiple resources attached to a record.
+3. enhance the resources.get service to build a zip archive containing a mef of the metadata record, constraints extracted from the metadata record (if any) + other info such as date of download etc and whatever resources were selected for download.
+
+=== Proposal Type ===
+ * '''Type''': User interface and core functionality additions
+ * '''App''': !GeoNetwork and !Jeeves
+ * '''Module''': Metadata XSLTs, add new services and enhance existing ones
+
+=== Links ===
+ * This has been available in the BlueNetMEST sandbox for some time - tested by users in the !BlueNet project
+
+=== Voting History ===
+ * None yet
+
+----
+
+== Motivations ==
+
+File upload: improve user interface
+File download: include any specific constraints on resource use, improve user interface - especially when dealing with multiple resources
+
+== Proposal == 
+
+See overview.
+
+=== Backwards Compatibility Issues ===
+
+== Risks ==
+
+== Participants ==
+ * As above 
+