Z
Z
zaartix2019-01-04 15:13:51
symfony
zaartix, 2019-01-04 15:13:51

Service with translated parameter dictionary. Something is wrong?

There is a service (let's say StaticList) where all sorts of parameter lists are stored, for example:

public static function getCommissions()
    {
        $list = [
            [
                'key' => self::COMMISSION_NO_PROXY,
                'name' => self::$translator->trans('_No proxy phone, no commission_'),
                'projects' => ['all']
            ],
            [
                'key' => self::COMMISSION_ANSWERS,
                'name' => self::$translator->trans('_Commission_'),
                'projects' => ['1']
            ],
        ];
        return $list;
    }

there as a key value - constants, which are sometimes obtained in controllers and checked, so it is static.
In some models, I use methods like getCommissionText , which no longer return the key recorded in the database, but get the text value from this service by key. Accordingly, the only way to reach the service from the entity (model) is a static method call, like StaticList::getTextForKey($this->commission_key
) .to. many problems arise due to static calls to this service (for example, the constructor is not called, so there is no translator interface because of this).
I summarize:
There should be a file listing the parameters, their translated (localized) names, and there should be a way to easily get the localized text value of the parameter from the model (entity).
How would you solve this problem?

Answer the question

In order to leave comments, you need to log in

1 answer(s)
D
dosim86, 2019-01-10
@zaartix

The existing approach is quite appropriate, because accessing a service from a model is bad practice and displaying localized text from a model is not the job of the model, although the name field can be changed to type json in the DBMS.
In this case, I recommend renaming the StaticList service to ComissionManager and not making the getCommissions and getTextForKey methods static, because since the self::$translator construct still requires initial manual initialization of the object of the Translation class, let the constructor itself deal with it implicitly. Further, it is enough to implement the ComissionManager service as a dependency in the desired controller method and call $comissionManager->getTextForKey($model->commission_key), substituting the model explicitly, but $comissionManager->getText($model) can be shorter and more flexible.
Of course, you can go further and create an interface ComissionInterface with a getKey method and add it to models that will work with commissions. Then the implementation of the getText method will look like this:

public getText(ComissionInterface $model)
{
    $key = $model->getKey();
    $text = ...
    return $text;
}

Thus, the service does not need to know anything about the models, because it is enough that they implement the ComissionInterface interface, which guarantees that the getKey method will definitely be in the model. Those. we abstract from specific classes of models.
You have a typical situation where people try to solve a problem with one big method or class. Follow the class and method single responsibility principle.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question