Web-интерфейсы и средства реализаций потихоньку развиваются и становятся более приятными и навороченными. :)
С такого рода Шаблонным интерфейсом, легко поддерживать интерактивность сайта, обновляя лишь необходимые участки станицы.
В вашем случае теряется ясность шаблонов. Становится сложно ориентировать в этой кучи значений.
Для поддержки различных языков - я согласен, можно загрузить и .js. Только xml-файл универсальнее: он не завязан на переменных относительно проекта на .js, его в случае чего, можно использовать в любом другом приложении.
Зачем уходить от парсинга, который и так занимает доли секунды?
Ну и может быть ситуация, когда необходимо загрузить конфиг для определенного пользователя (которых в вашей системе будут тысячи) - неужели вы будете генерить JS файл, когда можно просто сгенерить JSON'м и передать в скрипт?
Помойму основная фишка шаблонов в том, чтобы можно было работать с изменяемыми значениями. Иначе это уже просто HTML.
Наверное вы имеете что-то другое ввиду. Объясните?
Имхо - 1000мс вы выдумали. :) Не желаете, не пользуйтесь, я никого не заставляю - просто делюсь своими мыслями и методами решений.
По скорости - на первую загрузку выйдет несущественно больше. (особенно на модеме) Зато на следующие подгрузки будет уходить намного меньше времени, нежели на загрузку всей страницы.
Если это вас так волнует, старенький Athlon XP 1.7 Ghz сейчас держит нагрузку в 150 клиентов одновременно без тормозов. При этом - код ещё не оптимизировался.
На Core2Quad с большей оперативой, это будут совсем другие цифры.
Да и это совсем другая тема для обсуждений.
В моём случае, одним геммороем меньше. А именно -php.
Я не говорю, что мой способ самый-самый лучший, но мне используя его намного удобнее генерить HTML код.
Действительно. Исправил.
Забыл исправить trace_skin_file на trace в 2х местах. Плюс, в ajax_load вместо parcer(par) необходимо сделать return parcer(par).
Не зря я поместил этот топик в "Выхлопы" :)
Я просто этот метод использую лишь для хранения конфигов. :)
Ну, я думаю, что не рентабельно подгружать "У вас в корзине 139 яблок" с сервера ;)
С такого рода Шаблонным интерфейсом, легко поддерживать интерактивность сайта, обновляя лишь необходимые участки станицы.
Для поддержки различных языков - я согласен, можно загрузить и .js. Только xml-файл универсальнее: он не завязан на переменных относительно проекта на .js, его в случае чего, можно использовать в любом другом приложении.
Зачем уходить от парсинга, который и так занимает доли секунды?
Ну и может быть ситуация, когда необходимо загрузить конфиг для определенного пользователя (которых в вашей системе будут тысячи) - неужели вы будете генерить JS файл, когда можно просто сгенерить JSON'м и передать в скрипт?
Наверное вы имеете что-то другое ввиду. Объясните?
Здесь, как и в любом другом обществе, не приветствуется агрессия.
Данное решение JS-Шаблонов имеет и другие минусы. По этому я не считаю его решением от всех невзгод.
Всё зависит от многих факторов, которые необходимо учитывать при реализации.
По скорости - на первую загрузку выйдет несущественно больше. (особенно на модеме) Зато на следующие подгрузки будет уходить намного меньше времени, нежели на загрузку всей страницы.
<!SKIN 'PIECE.IMG'><tr id="%GOODS_ID%"><td class="order_name">%GOODS.NUM%. <img src='%GOODS.IMG%'></td><td>%GOODS.PRICE%</td></tr><!END 'PIECE'>
Либо:
<!SKIN 'PIECE'><tr id="%GOODS_ID%"><td class="order_name">%GOODS.NUM%. %GOODS.NAMEIMG% <!SKIN 'IMG'><img src='%NAME%'><!END 'IMG'><!SKIN 'NAME'>%NAME%<!END 'NAME'></td><td>%GOODS.PRICE%</td></tr><!END 'PIECE'>
На Core2Quad с большей оперативой, это будут совсем другие цифры.
Да и это совсем другая тема для обсуждений.
2) Всё находится в одном шаблоне, который разбит внутри на несколько.
Я не говорю, что мой способ самый-самый лучший, но мне используя его намного удобнее генерить HTML код.
Хотя, у меня более серьёзные проблеммы в унивесальности, по этому я это разрабатывал для своей задачи.
Забыл исправить trace_skin_file на trace в 2х местах. Плюс, в ajax_load вместо parcer(par) необходимо сделать return parcer(par).