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"> </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.