Jump to content
Sign in to follow this  
sv2109

Присвоение языковых переменных в контроллере [Решение]

Recommended Posts

Наверное самым нудным в создании любого модуля является присвоение языковых переменных в контроллерах.

 

Сначала все эти переменные нужно внести во все языковые файлы, после чего каждую(!) переменную нужно прописать в контроллере, а в модулях их десятки (а например в контроллере товара в админке больше сотни!), после чего каждую переменную прописать в шаблоне..

 

Я уже начал писать свой хелпер для этого, как нашел одно очень простое решение:

Вместо:

$this->language->load('path/file');
$this->data['foo1'] = $this->language->get('bar1');
$this->data['foo2'] = $this->language->get('bar2');
// еще 100500 строк с $this->language->get()

учитывая то, что лоадер языка возвращает массив всех языковых переменных, можно сделать:

// для 1.5.x
$this->data = array_merge($this->data, $this->language->load('path/file'));
// для 2.0
$data = array_merge($data, $this->language->load('path/file')); 

Это присвоит все языковые переменный в $this->data автоматически.

 

Нужно помнить, что $this->language->load('path/file') возвращает не только массив из файла 'path/file' но и все языковые файлы загруженные до него, например главный языковый файл в корне. Но конфликтов быть не должно, так как если вдруг и попадется какая-то ненужная языковая переменная с одинаковым названием с переменной контроллера то учитыая то, что языковые файлы грузятся с самого начала, эта перменная потом просто переопределиться в контроллере. 

 

Проверено на admin/controller/catalog/product.php и catalog/controller/product/product.php как 2-х самых больших контроллерах с большим к-вом языковых перменных. 

 

Почему это не используется в движке? Неужели кому-то проще писать десятки ненужных строк кода в каждом контроллере?..

  • +1 1

Share this post


Link to post
Share on other sites

Спасибо, интересное решение, но я предпочту такую реализацию только там где все языковые переменные используются в одном представлении, т.к. при таком подходе теряется возможность их выбора.

Share this post


Link to post
Share on other sites

Спасибо, интересное решение, но я предпочту такую реализацию только там где все языковые переменные используются в одном представлении, т.к. при таком подходе теряется возможность их выбора.

 

Приведите пример с "возможностью выбора". Зачем вам что-то выбирать? Вы просто берете все языковые переменные, после чего в шаблоне выводите то, что нужно. Если посмотреть код лоадера языка то там используется точно такой же код - все языковые переменные из предыдущих языковых файлов из других контроллеров просто заменяются новыми из нового файла, если имена совпадают.  

Share this post


Link to post
Share on other sites

Один языковой файл может использоваться в разных контроллерах и представлениях. Как раз в таком случаи нет нужды получать из него все языковые переменные, т.к. не все они будут использоваться.

Edited by korsox

Share this post


Link to post
Share on other sites

Один языковой файл может использоваться в разных контроллерах и представлениях. Как раз в таком случаи нет нужды получать из него все языковые переменные, т.к. не все они будут использоваться.

Какая разница в скольких контроллерах используется этот языковый файл? В шаблоне вы берете те перемнные, которые вам нужны, что не нужно просто не используете. Если вам больше нравится присваивать каждую перменную отдельно и писать десятки строк ($this->data[''] = $this->language->get('');) в каждом контроллере - пишите.  

Share this post


Link to post
Share on other sites

Какая разница в скольких контроллерах используется этот языковый файл? В шаблоне вы берете те перемнные, которые вам нужны, что не нужно просто не используете. Если вам больше нравится присваивать каждую перменную отдельно и писать десятки строк ($this->data[''] = $this->language->get('');) в каждом контроллере - пишите.  

Ваша реализация мне понравился, я просто подметил, что при таком решении в представлении могут быть не используемые переменные.

Share this post


Link to post
Share on other sites

Ваша реализация мне понравился, я просто подметил, что при таком решении в представлении могут быть не используемые переменные.

 

На производительность это никак не повлияет.

Share this post


Link to post
Share on other sites

На производительность это никак не повлияет.

 

Зато сильно влияет на "память"

Share this post


Link to post
Share on other sites

Зато сильно влияет на "память"

Сильно? Можно подробнее насчет сильно? :)

Вот я специально посмотрел: основной языковый файл русского языка для каталога весит аж 3 кб. еще 2 кб. файлы common (это то, что грузится постоянно) + файлы модулей (от 53 байт до 847 байт) из которых обычно загружено 2-3 максимум (а иногда и ничего) + еще 1-3 кб. это файл из product - страница товара, категории, поиска, производителя (загружается только 1 из них) В результате получается от 6 до 8 кб минус вес того контроллера что загружается так как его в любом случае нужно грузить. Это для русского языка, для английского еще меньше. Поистине сильно влияет на память! :)

Share this post


Link to post
Share on other sites

Сильно? Можно подробнее насчет сильно? :)

Вот я специально посмотрел: основной языковый файл русского языка для каталога весит аж 3 кб. еще 2 кб. файлы common (это то, что грузится постоянно) + файлы модулей (от 53 байт до 847 байт) из которых обычно загружено 2-3 максимум (а иногда и ничего) + еще 1-3 кб. это файл из product - страница товара, категории, поиска, производителя (загружается только 1 из них) В результате получается от 6 до 8 кб минус вес того контроллера что загружается так как его в любом случае нужно грузить. Это для русского языка, для английского еще меньше. Поистине сильно влияет на память! :)

Счас, с реального сервера клиента, PHP Fatal error:  Out of memory (allocated 3145728) (tried to allocate 32 bytes) Вот такие у нас хостеры, каждый байт на вес золота :)! Плевать они хотели что у вас 64 метра, видите ли серверу не хватило, мыши у соседей згрызли всю !

Так что привычка не расходовать зазря память еще с DOS-a осталась :)

Вы вообще-то имеете ввиду стандартную тему (и то вы не правильно посчитали, сколько надо памяти чтобы выделить для двух копий переменных только в /module (почти всё на главной ~64Kb * 2 и плюс еще /common /account ... всего ~ будет выделено 1-2 Mb ! Теперь вспомним про наших доблестных хостеров...). Вы еще не видели языковых файлов других тем. Туда засовывают и инструкции и чего только не лень. А в админке тем более, особенно страница Дополнения, для неё только иногда выделяется до 10 метров language памяти а вы предлагаете её еще в два раза умножить.

Так что уж лучше $this->language->get прямо в шаблоне и не "трогать" в контроллере

Share this post


Link to post
Share on other sites

Out of memory (allocated 3145728)

8кб от 32 Мб это где-то аж 0.25% соответственно если памяти не хватает то причину нужно искать никак не в 8кб. языковых переменных, а где-то в другом месте..

Вы вообще-то имеете ввиду стандартную тему. Вы еще не видели языковых файлов других тем. Туда засовывают и инструкции и чего только не лень.

Языковые переменные к теме вообще не должны иметь отношения. Тема это тема - css, html, яваскрипт. Что в теме выводить на разных языках? Посказку/инструкцию? это пусть еще ну максимум 10кб. хотя я даже не представляю что в 10кб можно впихнуть для темы. В любом случае это ничено не меняет. Экономить 5-10кб это "экономия на спичках".

Share this post


Link to post
Share on other sites

8кб от 32 Мб это где-то аж 0.25% соответственно если памяти не хватает то причину нужно искать никак не в 8кб. языковых переменных, а где-то в другом месте..

Языковые переменные к теме вообще не должны иметь отношения. Тема это тема - css, html, яваскрипт. Что в теме выводить на разных языках? Посказку/инструкцию? это пусть еще ну максимум 10кб. хотя я даже не представляю что в 10кб можно впихнуть для темы. В любом случае это ничено не меняет. Экономить 5-10кб это "экономия на спичках".

 

Да понятное дело.. :)  У хостера соседи могли сьесть все запасы памяти. И сервер не выделил твои законные 64 метра, а только что осталось. Вот в чем суть. Что даже на метре памяти (а вы её засоряете копиями переменных не считая указателей и т.п.) могут сыпаться ошибки. даже 10 -100Кб иногда бывают критичны (и не важно уже серверу "где"). Я пример привел.

Кстати в OC 2.0 сильно поработали над экономией  "памяти"

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
You are posting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.