Problem/Motivation
#2226533: Changes to the Language class due to the LanguageInterface (followup) is making the properties protected and #2334763: Tidy up of LanguageInterface - removal of setters and other unnecessary methods is taking out setName() and setDirection()
Proposed resolution
use create() parameters
Remaining tasks
see how to handle this
User interface changes
No.
API changes
No.
Comment | File | Size | Author |
---|---|---|---|
#3 | LanguageEditForm-2337843-3.patch | 1.44 KB | martin107 |
Comments
Comment #1
YesCT CreditAttribution: YesCT commenteddiff --git a/core/modules/language/src/Form/LanguageEditForm.php b/core/modules/language/src/Form/LanguageEditForm.php
index de2213a..6cbd1bb 100644
--- a/core/modules/language/src/Form/LanguageEditForm.php
+++ b/core/modules/language/src/Form/LanguageEditForm.php
@@ -52,8 +52,8 @@ public function submitForm(array &$form, FormStateInterface $form_state) {
$languages = language_list();
$langcode = $form_state->getValue('langcode');
$language = $languages[$langcode];
- $language->name = $form_state->getValue('name');
- $language->direction = $form_state->getValue('direction');
+ $language->setName($form_state->getValue('name'));
+ $language->setDirection($form_state->getValue('direction'));
language_save($language);
$form_state->setRedirect('language.admin_overview');
Comment #2
YesCT CreditAttribution: YesCT commentedComment #3
martin107 CreditAttribution: martin107 commentedlooking at \Drupal\language\Form\LanguageEditForm::submitForm()
$languages = language_list(); is a deprecated function ...using the language_list's default parameter $flags ... what follows is its natural successor...
So $languages is pre-filtered to be an associative array of ConfigurableLanguage objects, keyed by the language.
without access to the setter ... the submitForm broken into natural language becomes.
1) clone the language identified by 'langcode'
2) update the values and save.
But who am I to blow against the wind...
I have opted for a solution that does not use setters/getters but note it incurs the cost of a new Drupal\Core\Language\Language constructor inside ConfigurableLanguage::toLanguageObject()
( I am not make the case for a premature optimising ( a bad thing ) I am just turning over the pros and cons of getters/setters
Comment #5
martin107 CreditAttribution: martin107 commentedjust for reference this will conflict with #2338037: Process @todo in \Drupal\language\Entity\ConfigurableLanguage now that other issues are fixed which should maybe committed first.
LOL
- $updatedLanguage = $language.toLanguageObject();
+ $updatedLanguage = $language->toLanguageObject();
my brain has been addled by too much javascript recently.
I will fix this properly in the morning :)
Comment #6
alexpottThis is made obsolete by #2336177: ConfigurableLanguage cannot be created/removed directly, integrate language_save() and language_delete() since that changes this for to be a proper entity form
Comment #7
martin107 CreditAttribution: martin107 commentedyep obsolete. which is a good thing.
Comment #8
martin107 CreditAttribution: martin107 commented