Я не исключаю, что есть задачи, для которых оптимальнее хранить в таблицах сериализованные объекты. Но я не считаю, что в случае с локализацией это уместно.
«JSON в базе данных это ужасный code smell» — code smell не всегда говорит о том, что что-то не так. Но в своей практике я ни разу не встречал JSON/XML в базе, которые бы со временем не начинали создавать проблем. Да, изначально с такой структурой проще работать. Да, кода писать меньше. Но сам факт того, чтобы вы не сможете работать с данными при помощи базы данных, уже накладывает слишком много ограничений. Ни вам foreign keys, ни выборочных быстрых апдейтов по индексам… в подавляющем большинстве случаев лучше написать немного больше кода изначально, чтобы не страдать впоследствии, при поддержке системы.
И я считаю, что локализация — как раз хороший пример, когда данные нужно хранить нормализованно. Тем более, что это совсем не сложно.
>> json кстати для случая введения нового языка идеален… нет элемента в массиве — нет перевода
Этим свойством обладает, фактически, любой подход. Это не плюс использования JSON'а.
JSON в базе данных это ужасный code smell. Зачем таким способом денормализовывать данные, если их можно хранить нормализованно?
Хранить JSON в базе данных — ужасное решение. Для любого изменения данных прийдётся их вытягивать в приложение, изменять и записывать обратно.
К тому же, такой подход очень плохо расширяем — в том плане, что при добавлении нового языка нужно будет изменять данные во всех строках многих таблиц.
Скажите, а что вы имеет в виду, когда пишете «передача данных между php сценариями»? Из вашего «при нажатии на ссылку» можно подумать, что речь идёт о передаче данных от странички в браузере к серверному скрипту.
Хотя, если вы говорите об объекте i18n, то соглашусь. Лучше его создать один раз в своём модуле и получать этот объект через define во всех модулях, где необходимо реагировать на его события.
В данном случае, LocaleModel, похоже, используется только одной View'хой (которая, судя по всему, сама глобальна), поэтому вполне логично локаль ассоциировать именно с этой View и не показывать её другим View.
pxx, В Хроме для всех файлов, которые берутся из кэша, задержка составляет 0ms. Возможно, вы открыли страницу, а потом закрыли её ещё до того, как all.js успел загрузиться? И тогда в следующий раз он будет браться не из кэша, а загружаться с сервера.
Вот именно. Если в коде так много TODO, что их нужно разделять на типы, то этот код вообще не должен был попать в репозиторий. А если нужно упорядочить будущие задачи, то это нужно делать в task/issue-tracker'е.
