Что-то я не подумал вообще об этом
такая таблица существует и именно для этого создана, т.е. на какой странице (в какой категории или в каком компоненте) какой модуль подключать (выводить). Хоть это и отвлечение от темы, но зато тема для нового "велосипеда"
Что-то мы о разном наверное.. Что значит отключить? Во-первых, файлы то остаются, если все языковые файлы подключать. А во-вторых, ну так модуль может отображаться на одной странице, но не будет выводиться на другой. Так же и всякие компоненты и плагины..
Тем более ничего кроме лаконичности вызова данный способ не дает
Ну если это не ухудшает производительность и не кушает лишней памяти, то именно для этого и задумал Что касается занимать магическое свойство, ну в данном случае оно и не нужно для других целей
LIME пишет:
Ну и при генерации можно обходить все языковые файлы вообще
А не
слишком ли накладно получится? Может всё таки подключать только то что используется?
У меня в проекте под сотню языковых файлов
Я в своё время проводил тесты: ini-файлов, констант и т.п.
Пришёл к выводу что INI лучше. Скорость подгрузки и преобразования в массив сумасшедшая, по сравнению с загрузкой констант. Но приходится жертвовать памятью.
Дума ещё над JSON, формат гибче, но очень критичен к ошибкам синтаксиса, вообще всё перестаёт работать ))))
НУ так вернёмся к самому вопросу.. На сколько правильно всё таки таким образом использовать магические методы? Т.е. получается я принудительно их вызываю. С другой стороны PHP это разрешает
Для существующих методов/полей IDE предлагает автокомплит, для несуществующих - нужно либо все помнить, либо подсматривать где-то.
Согласен. Это один офигенный минус
Но(!) языковые константы всё равно подсматривать придётся.
DeepVarvar, да вот в том то и дело что не хочется постоянно перед выводом подключать нужный язык, хочется сразу на вывод пускать. Расширений для ядра много, иногда они используют языковые константы ядра. И получается что много это этих подключений...
Хотя может это просто "капризы"
а почему языковые файлы ты в PHP-коде хранишь? Как-то принципиально? И почему бы сразу не возвращать массив а объекты? (Добавление)
DeepVarvar пишет:
Это хреновастый пример. Откуда вообще в каком-то классе ты делаешь echo?
почему хреновастый ?
И в классе я не делаю вывод, только возврат.
нужно получить константу, делаю так
То есть я постоянно загружаю в переменную языковой файл. К использованию глобальных переменных отношусь плохо. Вот и затеял такую штуку.. И Только сам компонент знает свои языковые переменные. Но вот только существует единая "точка" подключения (Добавление)
В принципе вот идея моего велосипеда
В самом классе соответственно подключаю, запоминаю, оптимизирую, что-то там ещё делаю... и в конечном итоге передаю переменной массив с языковыми данными именно для этого компонента.
Ну и в где-то в коде уже использую
В принципе достаточно просто. Но приходится или в каждой функции/методе создавать переменную с данными или хранить что-то всё в глобальной. Можно конечно сразу всё объединить в одно, например
Вот в качестве эксперимента решил попробовать изобрести более простой "велосипед".
Достаточно просто и человекопонятно.. Вот и спросил на сколько "правильно" использовать магические методы
Появилась интересная мысль для вызова языковых констант (ну может не я один к такой мысли пришёл, но всё же..)
Допустим в движке используются компоненты, модули, плагины. Каждое расширение имеет свой пакет языковых файлов.
Суть в том чтобы сделать единый обработчик без дополнительного подключения необходимых языковых файлов. Ну то есть всё это делать в одном месте.. И при этом воспользоваться допустим __callStatic()
Перевожу одну спецификацию, вернее создаю свою на основе некоторых. Но все спецификации W3C написаны на XML Schema. В принципе проблем нет, но есть тонкие места которые не могу понять как сделать.
DeepVarvar, так задача какая? Какая цель парсить ссылки всего сайта? Если это мой сайт, то есть более гуманные методы.. А тут человек хочет создать конкурента гугла или яндекса ))))) И для таких целей даже библиотек будет мало