Project

General

Profile

Actions

Feature #57454

closed

Trigger events in DragUploader

Added by Stephan Schuler over 10 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2014-03-31
Due date:
% Done:

100%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

Hey there.

I just tried to add some features to the files list module, mostly additinal buttons and stuff.

There I noticed that the DragUploader creates Ajax response data (both, the progress bar as well as the "success" line of uploaded files) in pure JS without hooks/events. This makes it kind of impossible to react on “onUploadComplete” events from the outside.

So I would suggest to adjust the DragUploader JavaScript in a way that allows to communicate with the DragUploader responses from the outside.

Since I don't know about a common TYPO3 way to do that, I would use plain jQuery events being triggered on the $trigger object of the DragUploader. That makes sense to me because the DragUploader itself is done in jQuery.

Code will follow as soon as I have a ticket number.

Regards,
Stephan.

Actions #1

Updated by Stephan Schuler over 10 years ago

https://review.typo3.org/#/c/28976/1
Here we go. Don't know why review.typo3.org doesn't link automatically.

Actions #2

Updated by Gerrit Code Review over 10 years ago

  • Status changed from New to Under Review

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/28976

Actions #3

Updated by Xavier Perseguers over 10 years ago

Hi Stephan,

First of all thanks for your patch. Before introducing a new hook/signal whatever, could you please describe a bit more what you want to achieve and how you plan to implement it? In case of EXT:image_autoresize I had to "hook" as well into the upload but could do it with existing signals telling me that a file had just been added to the corresponding repository. Would be good to know why this signal is not sufficient for your use case.

Greetings

Actions #4

Updated by Stephan Schuler over 10 years ago

Hey Xavier.

Thank you for your response.

Of course you're right, using existing signals on the server side might work in order to adjust "FAL data". I know about several signals being triggered on nearly every situation when FAL records change state. I guess you're talking about those 15 signals being used in ResourceStorage, named like "ResourceStorageInterface::SIGNAL_*". They are good to access FAL data PHP wise.

But I want to adjust the client side.

Have a look at the DragUploader JavaScript file and search for the "me.uploadComplete" method. That's the "onComplete" handler of a single file, and it destinguishes between IRRE and not-IRRE usage. IRRE triggers an AJAX import of the recently created record to be displayed inline. Not-IRRE just draws a table line.
That's a pretty good example of what could be decoupled. DragUploader could either draw the info line or skip that, too, and an additional module then needs to keeps track of propper IRRE form creation. The thing is: As soon as there is a single if/else situation to have completely different results, it's likely that others might want to have other connectors than the existing two.

To give you my real use case: I want to extend the button area of the file module. Regular files have that "edit pen" pointing to the sys_file_metadata record. When uploading a file, the edit pen does not exist in the first place because the DragUploader drawing the "<tr>" node simply doesn't draw any buttons. Currently I need to refresh the folder view (click on the folder in the tree menu). Then the file which previously was positioned at the top of the list (that's the default behavior of the uploader, and this makes perfect sense to me) now changed its position according to its file name. And only this line (that was drawn by the PHP side, not the JS side) has its "edit" button.

And here's another aspect of my use case: In contrast to the default edit button, the one being created by the upload AJAX respons should open the edit dialog in a popup window. That, in theory, should increase usability of the file list for multi file uploads. It's related to the fact that list view changes its order when reloading because newly uploaded files appear at the top by AJAX result. I would like to have that list stay as long as the editor hasn't finished his record adjustments. My editors do need to edit the files after uplading, because I make heavy use of e.g. categories.

All of that can be done easily by just an additional JavaScript file, as soon as there is an event on the client side that notifies me about uploadComplete.

That's actually working code:

JavaScript file:

define('TYPO3/CMS/NxFileEditButtonsTest/Backend/DragUploader/EditButtons', ['TYPO3/CMS/Backend/DragUploader', 'jquery'], function(DragUploader, $) {

    $('.t3-drag-uploader').each(function(key, DragUploaderFrame) {
        $(DragUploaderFrame).data('DragUploaderPlugin').$trigger.bind('uploadComplete', function(event, FileQueueItem, data) {

            var buttonColumn = FileQueueItem.$row.find('td:last');
            buttonColumn.html('');

            var button = $('<a><span class="t3-icon t3-icon-actions t3-icon-actions-document t3-icon-document-open" title="Open">&nbsp;</span></a>');
            button.click(function() {
                vHWin = window.open(
                    'alt_doc.php?edit[sys_file_metadata][' + data['result']['upload'][0]['metaDataUid'] + ']=edit',
                    'popUpID7ce76eed34',
                    'height=350,width=580,status=0,menubar=0,scrollbars=1'
                );
                vHWin.focus();
                return false;
            });
            buttonColumn.append(button);

        });
    });

});

Adding that file to the backend in ext_localconf.php:

$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['RequireJS']['postInitializationModules']['TYPO3/CMS/Backend/DragUploader'][] = 'TYPO3/CMS/NxFileEditButtonsTest/Backend/DragUploader/EditButtons';

The only missing part is: The backend JS does not interact with its environment other than manipulating DOM. The "uploadComplete" event obviously comes from my changed DragUploader.js.

Regards,
Stephan.

Actions #5

Updated by Frans Saris over 10 years ago

For those who are also struggeling with the require js part.

This is how I did the tests:

my_test_extension/ext_localconf.php

$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['RequireJS']['postInitializationModules']['TYPO3/CMS/Backend/DragUploader'][] = '/typo3conf/ext/my_test_extension/Resources/Public/Javascript/UploadTest';

my_test_extension/Resources/Public/Javascript/UploadTest.js

define('/typo3conf/ext/my_test_extension/Resources/Public/Javascript/UploadTest', ['TYPO3/CMS/Backend/DragUploader', 'jquery'], function(DragUploader, $) {
    console.log('loaded');
    $('.t3-drag-uploader').each(function(key, DragUploaderFrame) {
        $(DragUploaderFrame).data('DragUploaderPlugin').$trigger.bind('uploadComplete', function(event, FileQueueItem, data) {
            console.log('uploadComplete', event, FileQueueItem, data);
        });
        $(DragUploaderFrame).data('DragUploaderPlugin').$trigger.bind('uploadStart', function(event, FileQueueItem, data) {
            console.log('uploadStart', event, FileQueueItem, data);
        });
        $(DragUploaderFrame).data('DragUploaderPlugin').$trigger.bind('uploadError', function(event, FileQueueItem, data) {
            console.log('uploadError', event, FileQueueItem, data);
        });
        $(DragUploaderFrame).data('DragUploaderPlugin').$trigger.bind('updateProgress', function(event, FileQueueItem, data, aa) {
            console.log('updateProgress', event, FileQueueItem, data, aa);
        });

    });

});

Actions #6

Updated by Stephan Schuler over 10 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #7

Updated by Benni Mack about 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF