Перейти к содержанию
sv2109

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

Рекомендуемые сообщения

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

 

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

 

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

Вместо:

$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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Изменено пользователем korsox

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Вот я специально посмотрел: основной языковый файл русского языка для каталога весит аж 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 прямо в шаблоне и не "трогать" в контроллере

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Out of memory (allocated 3145728)

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу

×

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.