🇫🇷France @zigazou

The first lines of the build method are the following:

    if (!empty($this->built)) {
      return;
    }

Therefore calling the build method on an already built view should not have a performance impact.

On another side, this might hide an incorrect view manipulation along the process.

MR has been done.

The proposed patch works for my case but I’m really not sure if this is what needs to be done.

zigazou → changed the visibility of the branch 3506138-unable-to-use to hidden.

zigazou → created an issue.

zigazou → created an issue.

Hi!

The patch works as expected for the attribute fields group:

But it does nothing for the class fields group:

Note: translation of "Add another class" and "Remove last added class" could be included as well.

Hello!

I'm currently developing SDC components that I then want to use in my site by configuring the entity displays.

So I've come to test both solutions (UI Patterns 2 and SDC Display).

Here's what I've come up with so far (Note that this is in no way intended to denigrate the contributors to the two projects or the projects themselves, a great job has been done, thanks to them).

Ease of use: SDC Display is the big winner

Associating fields with the properties and slots of SDC components is very simple (one click for each) with SDC Display and very error-free.

In contrast, UI Patterns 2 offers extensive lists for each field, and you then have to configure each association, which can be nested... In other words, the possibility of error is much greater and often leads to an empty result without you knowing why.

Power: UI Patterns 2 is the big winner

UI Patterns 2 offers much greater flexibility in the use of SDC components, both in terms of configuring the association and the availability of the tool at all levels of the rendering chain (for example in views, where SDC Display is absent).

zigazou → created an issue.

zigazou → created an issue.

Zigazou → changed the visibility of the branch 1.0.x to hidden.

Zigazou → created an issue.

Sorry to reply this late.

Yes, this solve the issue.

Thanks!

Standard view with openstreetmap.org tiles:

Modified view with custom tiles:

The proposed patch

Zigazou → created an issue.

Zigazou → created an issue.

Cassien, be aware that the patch https://www.drupal.org/project/rules/issues/3338673#comment-14914467 🐛 [10.0] Remove jQuery dependency from the once feature Fixed has not been extensively tested and it does not take debug.js and rules-ui_listing.js into account.

Could you please report any problem on the page https://www.drupal.org/project/rules/issues/3338673 🐛 [10.0] Remove jQuery dependency from the once feature Fixed ?

Hi!

Following comment #5 saying rules/autocomplete.js was forked, I did the same with Drupal 10 core/misc/autocomplete.js.

From what I saw, the custom autocomplete.js:

• immediately pop-up autocomplete suggestions when the field gets focus
• uses rules-* classes instead of form-* classes
• starts autocompletion with a minimum length of 0

I did not look at debug.js and rules_ui_listing.js.

Can someone please review the patch?

Hi!

After applying the patch, the '$' variable is no more available and triggers the following message:

Uncaught TypeError: $ is undefined
    attach https://sandbox.local/modules/contrib/rules/js/autocomplete.js?rpnskb:115

Zigazou → created an issue.

I attached a patch file which works in my case but I highly suspect it does not take into consideration lots of other use cases, neither is it solid.

Zigazou → created an issue.