Этот баг требует правильности пути. Видимо, исправив(или нет?) его, разработчики упустили противоположный вариант, о котором говорится в топике — проверка не происходит «в случае задания некорректных путей в шаблоне».
Тут разница в трафике геометрическая(если можно так сказать) — не на сколько-то килобайт, а в несколько раз. И это очень существенно и ощутимо в RIA. Тот же gmail — даже в нем раньше было ощутимо время задержки при переходе по пунктам меню.
Сейчас же все происходит очень быстро — там отдается json(довольно своеобразный — почему-то в начале файла с данными стоит while(1);). Если бы каждый элемент списка был обернут в div'ы, p и span, времени на загрузку данных было бы потрачено в несколько раз больше. Да и просто подумать: зачем грузить данные, которые уже были загружены? (html-шаблон)
Вытягивать шаблоны всех данных можно(например, показывать блок статистики по балансу или форму логина), но сами данные в нормально построенном приложении просто не должны иметь шанса туда попасть например, без валидной сессии аутентификации.
Все превосходно. Задачи-то там тривиальные решаются при рендеринге шаблонов. Не один проект реализовал с использованием шаблонизаторов. Разные решения пробовал. ejs — самый простой и удобный. Все остальные обладают неоправданным излишеством.
Хочу, кстати, заметить, что вдохновителем ejs является erb — стандартный шаблонизатор в RubyOnRails.
До вашего комментария я свято верил в то, что сегодня действительно пятница
Нужно, проверять Content-Length и от этого плясать дальше.
Сейчас же все происходит очень быстро — там отдается json(довольно своеобразный — почему-то в начале файла с данными стоит while(1);). Если бы каждый элемент списка был обернут в div'ы, p и span, времени на загрузку данных было бы потрачено в несколько раз больше. Да и просто подумать: зачем грузить данные, которые уже были загружены? (html-шаблон)
Хочу, кстати, заметить, что вдохновителем ejs является erb — стандартный шаблонизатор в RubyOnRails.