Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
(Coming from #1943776-9: In-place editors (Create.js PropertyEditor widgets) should be loaded lazily.)
… because AJAX commands are such a pain to use when they're triggered by the client-side:
+ var id = 'edit-load-metadata';
+ // Create a temporary element to be able to use Drupal.ajax.
+ var $el = jQuery('<div id="' + id + '" class="element-hidden"></div>').appendTo('body');
+ // Create a Drupal.ajax instance to load the form.
+ Drupal.ajax[id] = new Drupal.ajax(id, $el, {
url: drupalSettings.edit.metadataURL,
+ event: 'edit-internal.edit',
+ submit: { 'fields[]' : _.pluck(remainingFieldsToAnnotate, 'editID') },
+ progress: { type : null } // No progress indicator.
});
+ // Implement a scoped editMetaData AJAX command: calls the callback.
+ Drupal.ajax[id].commands.editMetadata = function(ajax, response, status) {
+ // Update the metadata cache.
+ _.each(response.data, function(metadata, editID) {
+ Drupal.edit.metadataCache[editID] = metadata;
+ });
+
+ // Annotate the remaining fields based on the updated access cache.
+ _.each(remainingFieldsToAnnotate, annotateField);
+
+ // Find editable fields, make them editable.
+ Drupal.edit.app.findEditableProperties($context);
+
+ // Delete the Drupal.ajax instance that called this very function.
+ delete Drupal.ajax[id];
+
+ // Also delete the temporary element.
+ // $el.remove();
+ };
+ // This will ensure our scoped editMetadata AJAX command gets called.
+ $el.trigger('edit-internal.edit');
That's just… evil. Instead, we should have something like Drupal.loadLibrary()
that allows client-side code to decide when to load a library. edit/metadata
can then again just return a JSON response, and part of that metadata can indicate which libraries should be loaded.
Comment | File | Size | Author |
---|---|---|---|
#5 | edit_metadata_json_attachments_ajax-1980744-5.patch | 14.33 KB | Wim Leers |
Comments
Comment #1
effulgentsia CreditAttribution: effulgentsia commentedRegardless of this issue, that would be a nice thing to fix: #1533366: Simplify and optimize Drupal.ajax() instantiation and implementation
I wonder if that would make sense as a separate issue.
Once we have a Drupal.loadLibrary(), then sure, why not :) But I also don't think there's anything wrong with leaving it as AjaxResponse other than #1533366: Simplify and optimize Drupal.ajax() instantiation and implementation.
Comment #2
webchickGiven this code evoked the response of "majestic PITA" by a so-affected developer, I think it's fine to call this normal rather than minor. :)
Comment #3
Wim LeersThis is blocked by #1533366: Simplify and optimize Drupal.ajax() instantiation and implementation.
Comment #4
Wim LeersThis needs to happen anyway, because
edit/metadata
is doing two things: returning metadata *and* loading editors. This against HTTP/REST principles and makes it effectively impossible to do #1872264-6: Minimize metadata HTTP requests triggered by Edit's JS.Instead of blocking on
Drupal.loadLibrary()
, which is not possible here after all because an in-place editor can dynamically return different attachments, I'm going to introduce aedit/editors
route to load in-place editors via an AJAX command.Comment #5
Wim LeersAs promised in #4.
Comment #6
effulgentsia CreditAttribution: effulgentsia commentedCool!
Comment #7
Dries CreditAttribution: Dries commentedLooks good. Committed to 8.x. Thanks!
Comment #8
Wim LeersHurray, thanks! :)
Comment #10
YesCT CreditAttribution: YesCT commentedchanging to use the more common tag, so the less common one can be deleted, so it does not show up in the auto complete and confuse people.