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.
Updated: Comment #N
Problem/Motivation
Currently, we have getPluginTypes and viewsHandlerTypes methods on ViewExecutable. These methods are used all over the place so we end up calling ViewExecutable::method. Which in some contexts doesn't look like it makes much sense.
Also, we need getPluginTypes to be more flexible; so we can e.g. just return a list of regular plugin types or just handler types (or all, as we do now).
Proposed resolution
Create a ViewPluginInfo class (bikeshed/find a better name). Move these methods into there. Make them more flexible.
Remaining tasks
User interface changes
API changes
Comment | File | Size | Author |
---|---|---|---|
#17 | 2219689-17.patch | 1.9 KB | damiankloip |
#12 | interdiff-2219689-12.txt | 714 bytes | damiankloip |
#12 | 2219689-12.patch | 9.22 KB | damiankloip |
Comments
Comment #1
damiankloip CreditAttribution: damiankloip commentedHere is a start.
Comment #2
dawehnerI wonder why we don't put it into the views class. It is a bit similar to \Drupal::version
Comment #3
damiankloip CreditAttribution: damiankloip commentedThat works for me.
Same shit, different class :)
Comment #4
dawehnerNice shit!
Comment #5
webchick3: 2219689-3.patch queued for re-testing.
Comment #7
alexpott2219689-3.patch no longer applies.
Comment #8
damiankloip CreditAttribution: damiankloip commentedComment #9
damiankloip CreditAttribution: damiankloip commentedComment #10
damiankloip CreditAttribution: damiankloip commentedComment #11
alexpottt('bajillion')?
Comment #12
damiankloip CreditAttribution: damiankloip commentedOK FINE :)
How about that?
Comment #13
alexpottLooks good to me.
Comment #14
damiankloip CreditAttribution: damiankloip commentedBack to RTBC in that case :)
Do your worst.
Comment #15
alexpottWorst done.
Committed 55b0a05 and pushed to 8.x. Thanks!
Comment #17
damiankloip CreditAttribution: damiankloip commentedHow did the $plugins property get all the way down there...? Let's move it quickly to be with the other properties.
Comment #18
dawehnerha
Comment #19
alexpottCommitted 3c89fb9 and pushed to 8.x. Thanks!
Comment #21
damiankloip CreditAttribution: damiankloip commentedThanks and apologies, all at the same time :)
Comment #22
ParisLiakos CreditAttribution: ParisLiakos commentedi dont think static::t() works for the string extractor. We should either open an issue for that or revert them back to t() ? those strings are untranslatable now
Comment #23
damiankloip CreditAttribution: damiankloip commentedBooo :( open a follow up?
Although, IMO we need to try and make this sort of static t() implementation work?
Comment #24
ParisLiakos CreditAttribution: ParisLiakos commentedi agree we need a static version of t(), this usecase never occurred to me..but i dont see the point of having
static::translationManager
property and fill it from\Drupal::translation()
..a\Drupal::t()
would do the exact same thing, and would be far less to type for you..so i guess we need an issue: deprecate
t()
for\Drupal::t()
(To make static things unit testable)?But i still think we should have another one quick followup here, to remove the static::t() and translationManager bits. do you agree?
Comment #25
damiankloip CreditAttribution: damiankloip commentedYes, sounds like a good settlement to me!
ParisLiakos++
Comment #27
lauriiiComment #39
andypostFollow-up for #22 #27 filed #3150721: Review static translation for \Drupal\views\Views::getHandlerTypes()