Ticket #888 (closed Feature Request: worksforme)

Opened 9 years ago

Last modified 9 years ago

dm4-files: extend the upload_dialog about a destination folder choice

Reported by: Malte Owned by: jri
Priority: Major Milestone: Release 4.8
Component: DeepaMehta Standard Distribution Version: 4.7
Keywords: Cc: JuergeN
Complexity: 3 Area: GUI / Usability
Module: deepamehta-files


The basic idea for improvement is, if plugin developers use the upload_dialog the files-plugin offers, the user using it should be able to select a folder into which she wishes to upload the file.

This gives maximum flexibility to the end-user where to store, e.g. her .csv file in the filerepo and in the same time frees up the file repo from mechanically created folders.

You can read more about the use case in #887.

Change History

comment:1 Changed 9 years ago by jri

Uploading a file does not necessarily mean the file is to be stored at server-side. Its up to the service which receives the upload to decide what to do with the file.

Consider an import plugin: the user uploads a file, the service processes it on-the-fly, and don't even stores the file.

In short: you upload to a service, not to a folder. You provide the service, you provide the upload request URL. So, from my view this provides the most flexible upload support the Core/Files? service can offer. This flexible upload support was introduced in DM 4.3. See #655.

Or are you seeking for a possibility to extend the Files service's upload dialog as a plugin developer?

Last edited 9 years ago by jri (previous) (diff)

comment:2 Changed 9 years ago by Malte

I see, thanks for your thoughts on this.
The thing is, the codebase of the CSV plugin just takes in a fileTopicId and does not provide any service which receives file uploads. If i am not mistaken, the csv webclient extension just uses the files plugin upload dialog and has specified a folder path, at some time in the life of dm4 this must have been working.

To just take a fileTopicId, i find this the right approach and thus i don't want to change anything here. Maybe we should think about how a topic command (Import CSV) will fit into the webclients generic file browsing functionality.

Currently the "Import CSV" topic command is bound to a "Topic Type". Either way, some work to do.
Will see, thanks for your input!

comment:3 Changed 9 years ago by jri

Currently the "Import CSV" command opens the Files plugin's upload dialog, which then POSTs the selected file to /files/, that is the Files services storeFile() method. The trailing slash of /files/ is actually the file repo path where to store the file. Here it is / which denotes the file repo root directory.

Once the upload is complete the CSV plugin sends another request, now to the CSV service to trigger the actual import process (/csv/import). The topic ID of the just created File topic is passed.

dm4c.get_plugin('de.deepamehta.files').open_upload_dialog('/files/',  function(file) {

    var status = dm4c.restc.request('POST', '/csv/import/' + dm4c.selected_object.uri + '/' + file.topic_id)

In principle this still works with DM 4.7. However since DM 4.7 the repo path as passed with the POST /files request must be encoded, that is /files/%2F, or in general:

"/files/" + encodeURIComponent(repoPath)

See #819.

To summarize: the Files service allows you to POST a file to an arbitrary file repo location.

comment:4 Changed 9 years ago by jri

My suggestion would be to not store the import file at all. Instead POST it directly to the CSV service and process it on thy fly. Only 1 request is required. See the dm4-import-export plugin as an example. I guess the original CSV plugin was developed at a time when the flexible upload mechanism as of DM 4.3 (#655) did not exist. When solved this way this ticket's original issue would change direction completely resp. goes away.

comment:5 Changed 9 years ago by Malte

  • Status changed from new to closed
  • Resolution set to worksforme

Great, thanks for the comment!
The original plugin works like a charm now with 4.7 :) - no need to change anything!
I see your point about not storing the .CSV file at server side and it makes sense to me, too. I like this new approach and i aim to go for that solution in the next "feature" release (or #887).

Note: See TracTickets for help on using tickets.