Практическое продолжение темы, начатой здесь - http://forum.vingrad.ru/index.php?showtopic=108433 ("Сделать парсер-генератор кода страницы ").

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

Сделать можно не циклом, а рекурсией, но нагляднее не становится.

Задача  скрипта - ужать данные большой-большой структурированной страницы, чтобы удобнее было работать с исходным кодом данных. Хотелось бы в будущем отойти от написания индивидуальных генераторов для страниц, иметь управляемость и расширяемость представленного в нём шаблона.

Не буду приводить код - всё есть на странице http://js2.ru/files/js-man3.htm (55 K, из них кода - 1.5 К).

Самое интересное начинается с заголовка "Клиентские объекты" в коде. Примерно строка - 580. Функция rdCell() обрабатывает подаваемый ей код, но интересен вызов её:

fCell -это строка с кодом функции, которая исполняется нужное число раз, пока не исчерпаются образы ячеек во входном потоке. Так реализован шаблон, который, к сожалению, оказывается не наглядным.

Практические результаты - участок кода, который в HTML занимал около 140К, в кодированном виде занимает около 25 К. Важно, что он сохраняет читабельность. Но далее требуется, чтобы он мог достаточно легко развиваться проектировщиком страницы - не просто добавлять новые элементы списка, которые описаны шаблоном fCell , а изменять структуру их. Поэтому есть желание сделать шаблон наглядным.

Это сообщение отредактировал(а) 12345c - 3.3.2008, 14:10

1) 12345c - ты шаман 
2) вёрстка впаяна в скрипт, следовательно HTML only
3) формат подаваемых данных на прямую зависит от скрипта, меняем скрипт, всё может слететь
4) не все шаманы как ты, следовательно нужно учить 

Отсюда, повтороюсь, я бы делал на XML + XSLT, как и большинство наверное.

Конечно, HTML, на него рассчитано. XML стоит делать до него. Переводить на сервере ХML в такую структуру, генерировать скрипт генерации кода, скомпилировать страницу, если она в созданном виде будет вызываться многократно.

Посмотри на это, если у тебя ещё останеться желание генерить из XML страницу с особым форматом и скриптами, то приведи хотя бы пример зачем такие сложности если чистый XML можно отправить клиенту (опера вроде как XSLT уже поддерживает, не знаю точно), а форматирование отложить в кешируемые стили. Плюсы компактности на лицо (тем более если передача gzip'ом), плюсы переносимости тоже, хоть XHTML, хоть XSL-FO, хоть что угодно.

Не отговариваю, просто это первый проект который я даже с 12 раза не врубаюсь как применить, когда есть более лучшие альтернативы.

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

А где прочитать про зипование при передаче? Известно, что в модемной связи по V42+ поток зипуется, а до местного провайдера как? И делается ли сжатие по ADSL и локальным сетям?

Через что этот архив смотреть? (localisation_static) 
XSLT - конечно, хорошая и правильная альтернатива, только XML с тегами иметь придётся. В зипе они уничтожаются, но в открытом коде занимают место. В конце этот алгоритм должен перекликаться по содержанию с XSLT-кодом для XML-представления.

Гуглить HTTP заголовок accept-encoding, используеться часто gzip, по моему реже deflate (простой zip). Сжатие на уровне HTTP, а не ниже по слоям.


Хорошо спроектированный XML занимает сам по себе немного места, также модно XML ложить в архив (gzip), файл действительно почти ничего не весит тогда.


Какой алгоритм? В XML документе оставляем <?xml-stylesheet type="text/xsl" href="путь до твоего .xsl"?>, браузер при открытии сам поднимет стили и трансформирует документ по ним в нечто красивое/читабельное. И никаких заморочек