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.

CommentFileSizeAuthor
#3 LanguageEditForm-2337843-3.patch1.44 KBmartin107
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

YesCT’s picture

diff --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');

YesCT’s picture

martin107’s picture

Status: Active » Needs review
FileSize
1.44 KB

looking 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...

   -$languages = language_list();
    +$languages = \Drupal::languageManager()->getLanguages(LanguageInterface::STATE_CONFIGURABLE);

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.

I think this updating procedure defines the perfect use case for setName() and setDirection....

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

Status: Needs review » Needs work

The last submitted patch, 3: LanguageEditForm-2337843-3.patch, failed testing.

martin107’s picture

just 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 :)

alexpott’s picture

Status: Needs work » Postponed

This 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

martin107’s picture

Status: Postponed » Closed (fixed)

yep obsolete. which is a good thing.

martin107’s picture

Assigned: martin107 » Unassigned