Прошу прощения за название темы - плохо представляю, как ее назвать. Суть: хочется обсудить некоторые нюансы идеологии программирования софта для работы на компьютере клиента (именно идеологии, а не собственно программирования, с самым общим кодом принципиальных моментов). Крайне желательно без "наворотов" типа ActiveX или там DHTML, т.е. примерно с возможностями JS образца IE3). Основная задача - разгрузить серверное ПО (все, что можно делать на клиенте, нужно делать на клиенте). Иными словами, что в принципе можно выжать из JS.

Я очень мало (и давно) программировал для броузера, но некоторые наработки остались. Общие впечатления от тех времен: большинство возможностей JS на фиг не нужны, но именно они почему-то чаще всего встречаются на веб-страницах . Мой (затравочный, субъективный) перечень абсолютно необходимых: charAt, document(close/write), eval, indexOf, length, new(Array/Object), parent, substring. Кажись, все. Ах, да - onLoad. Кроме того, для полноценного программирования обязательно наличие фреймов.

Примерный перечень задач (тестовые):
- перепись кадра из себя и из дочернего кадра (сына, внука).
- установка (удаление, переименование) объектов и их полей.
- создание поля со ССЫЛКОЙ на другой объект (а не КОПИЕЙ самого объекта).
- итерационный обмен с сервером(ами) из разных фреймов, обмен данными между ними.
- диалоговая настройка параметров страницы (количество и расположение фреймов, палитра).
- вывод "вражьей" (запрошенной из Инета) страницы в своем формате. Собссно, нужен доступ к тексту страницы (фрейма) как к строке (загоняем в невидимый фрейм, парсим, и выводим "как надо").
- установка (удаление, переименование) обработчиков событий клавы и мыши.
- генерация событий (нажатие клавиш на клавиатуре или мыши, перемещение мыши) вместо юзера.
- модификация защищенных от записи полей объектов.

Вот что навскидку получилось. Что упустил, что лишнего нагородил, где наврал?

Vladimir Rybinkin
хм... ну с IE3 вы загнули. зачем изобратать колесо?
Если вам нужно нормально писать на клиенте в javascript, то используйте библиотеки. То, что вы написали это действительно уровень примерно 1999-го года.

И вообще, в принципе не очень понятно что вы написали (что значит "перепись кадра" например). Поставьте нормально задачу.

В общем есть два уровня библиотек:
jQuery (и подобные) - обычные операции с элементами страницы, а так же с сетью
ExtJS, jQuery UI (и подобные) - для визуальных элементов

arsaЧтобы не плодить лишние сущности.С удовольствием. Какие библиотеки реализуют указанное?Ха-ха-ха! Тем более.Ну, здрассьте! Так что ж Вы про библиотеки? Переписать - значит изменить текст. Скажем, выдать в иной палитре, с иными расположением фреймов.

Так как получить доступ к тексту страницы, как к строке?

ох... так это вы так frame перевели понятно теперь.
в принципе всё делается через DOM, через document.getElementById , да и в общем остальные вещи что вы написали тоже.
честно говоря я и сам не думал что через jQuery будет сильно проще, но однако сильно упрощает.

главный в общем момент - фреймы в современных браузерах не нужны - их спокойно заменяют div-ы и динамическое их наполнение через javascript (например jQuery UI Tabs умеют загружать страницы сами). фреймы только усложняют излишне структуру.

Я бы сказал, что требования несовместимы. JS образца IE3 не умеет практически ничего. И уж точно ничего из того, что Вам нужно.

Вы вообще себе, похоже, слабо представляете принципы работы клиент-серверных приложений. Если хотите разгрузить сервер - клиент должен быть толстым. А для этого ограничиваться JS более чем десятилетней давности - абсурд. Тут надо писать полноценное приложение. Если хотите клиента в браузере - очень советую проникнуться мыслью, что сервер в этом случае разгрузить не удастся.

Когда определитесь, чего хотите - выбирайте архитектуру и будем обсуждать.

Вполне реально написать толстого клиента на JS, сам этим занимаюсь (например на ExtJS).
Даже можно хранение данных привинтить через Gears/AIR/HTML5 - некоторые демки ExtJS являются законченными приложениями вообще без общения с интернет.

Другой вопрос зачем это делать в браузере. На данный момент это создаёт множество проблем, так как всё таки средства разработки нормальных приложений намного более гибкие - в них можно сделать всё что угодно, и есть большой выбор языков, сред и специалистов. Написание сложных больших проектов на javascript на данный момент усложнено.

Но всё таки есть класс приложений которые должны быть в "облаке" - я считаю что это практически все приложения, работа которых сводится к вводу данных в формах. Основная мотивация - приложение будет в основном работать через интернет (простота доставки, обновления), и хочется кросс-платформенности. см. google, SaaS и.т.п.

Исправлено: arsa, 09.07.2009 22:17

Еще раз по теме (после вынужденного перерыва):

По содержанию предыдущих ответов я пришел к выводу, что меня просто не поняли. Совсем не поняли. Тема мне представляется важной, так что попробуем еще раз.

1. По поводу "использования библиотек". Согласен, при условии, что для интерпретатора (то бишь JS) библиотеки и есть ТЕКСТЫ функций. Ничто другое меня не интересует, меня интересует ИДЕОЛОГИЯ программирования на JS, т.е. не продукт, а инструмент для его получения. Максимально использующий все возможности языка.

2. IE3 взят сознательно, поскольку это более ранние, более простые, более отлаженные, и даже более важные (по крайней мере, на момент разработки языка) возможности. Именно эти возможности я и хочу в первую очередь "выпотрошить". Использовать же то, что появилось после примерно 1999-го года, по-моему, нужно лишь в случае невозможности простого решения, реализуемого для IE3. Тем более, что фразы типа JS образца IE3 не умеет практически ничего без смеха читать нельзя. Равно как и про абсурдность использования "неполноценного" ПО более чем десятилетней(!) давности. Извините, господа, но для меня подобные фразы свидетельствуют лишь о квалификации автора. И не стоит меня уверять, что с "примерно 1999-го" по примерно 2009 в программировании произошла революция - произошла скорее ДЕГРАДАЦИЯ!.

3. О фреймах: я допускаю, что "фреймы в современных браузерах не нужны", но на слово никому не верю. Если действительно "их спокойно заменяют div-ы", то мне нужно знать, ПОЧЕМУ ИМЕННО фреймы хуже. "Динамическое их наполнение" или "умение загружать страницы" не предлагать - фреймы, по моим данным, тоже прекрасно все это умеют. Кроме того, в моем понимании, фрейм - это:
3.1. HTML-код, интерпретируемый броузером для выдачи юзеру.
и/или
3.2. набор функций JS для каких-либо действий на клиенте.
и/или
3.3. набор данных, над которыми эти действия выполняются.
и/или
3.4. место для хранения HTML-кода, функций и данных (важнейшая вещь!).
и/или
3.5. автономно работающий ПРОЦЕСС в рамках единой задачи (окно броузера).

Поэтому мне совершенно непонятно:
- чем может кого-то не устраивать такая прелесть?
- что здесь может быть сложного?
- чем это вообще можно заменить (что могут предложить неведомые мне div-ы)?
- и, если даже и можно - НА ХРЕНА?!

4. Про серверное ПО, тонкого и толстого клиента. Клиент не просто тонкий, а тончайший - голый броузер. Но должен при необходимости "косить под толстого", подгружая (прозрачно для пользователя) нужные методы, классы, структуры. Серверное ПО разгружается автоматически, поскольку ему не нужно выполнять любые задачи, которые могут быть сделаны на клиенте. Скажем, заниматься оформлением страницы (а это иногда намного больше половины кода). Или фрагментировать выдачу, возложив на клиента итерационные запросы (например, при работе с СУБД). Иными словами, возможность динамически подгружать необходимый инструментарий (и удалять ненужное) снимает проблему "толщины клиента" напрочь. Возражения?

5. JS есть интерпретатор. Более того, у него даже int/float, по слухам, отсутствуют (руки бы оторвал). Т.е. имеем всего-то тип данных STRING, да две группы: ARRAY и OBJECT. Любой метод - тот же STRING. В головном (FRAMESET) кадре храним классы и методы - доступны из любого верхнего. Остальные - перезаписываемые при необходимости (даже если он один) - могут модифицировать базовый инструментарий, при желании иметь свой. Т.е. итерационный обмен с сервером, смена палитры, и прочая Query/UI получаются чуть ли не автоматически. Во всяком случае, ПРОСТО. Ну и на закуску программирование в объектах и событиях под рукой (при наличии совсем малого числа базовых функций, вряд ли более 20). Где я неправ?

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

Мне уже говорили (даже здесь), что JS/IE3 устарелый, беспомощный инструмент. Не могу согласиться, по одной простой причине: там имеется eval, т.е. аналог указателя, со всеми вытекающими. Это же инструмент ЧУДОВИЩНОЙ силы! Если бы не было eval - согласен, язык и был бы как раз тем самым дерьмом, как меня здесь уверяют. Да и я бы не дергался. Но eval-то есть...

Ой, мамочки! Завалялся тут у меня набор примеров, как надо писать на JS - старенький, от 2003 года. "The best software you can imagine", так сказать. Чего-то там прыгает, тикает, в Инет лезет, броузер детектирует... Решил я глянуть, как они eval используют. И просто со стула рухнул: на 37 файлов учебных примеров eval не используется НИ РАЗУ!!! Охренеть!

Господа! Если и вы ТАКОЙ технологией программирования на JS пользуетесь, то я теперь понимаю, ПОЧЕМУ вы мне ТАК отвечали. Но это же детский сад - прости, Господи! Ау, господа - скажите, что это не так, что вы eval активно используете. Ведь в противном случае мы вообще на разных языках говорим... Тады - ой. Тады "дайте мне eval, и я переверну Землю".

Планируемая технология: берем головной кадр (index.htm), ставим туда FRAMESET (на один фрейм). Там по onLoad вешаем функцию инициализации, которая создает на родителе (в том самом index.htm, который и нужен-то исключительно для хранения) базовый набор методов, и переписывает фрейм (сама себя, она больше не нужна) на любой другой (рабочий). Или тоже на FRAMESET, если рабочих кадров больше одного. В любом рабочем кадре повесим на какое-нить событие (тот же onLoad) функцию, которая ИСПОЛЬЗУЕТ этот самый набор. Проверяем - все данные, все методы живы и здоровы. Ура! Теперь из любого кадра можно пополнять, удалять, модифицировать этот набор, т.е. мы автоматически имеем хоть толстого клиента, хоть тощего, динамически худеющего или толстеющего, как нам заблагорассудится. Вешаем нужное количество фреймов (в т.ч. невидимых), раздаем им задания, и наслаждаемся жизнью. Обмен данными - тривиален, мультизадачность - реализуема, настройку всяких там палитр юзеру и отдадим - нехай ковыряется. Что остается? Программирование в объектах и событиях. В объектах у меня уже все работало именно так, как я и хотел бы в идеале (привираю, естественно), в событиях - пока хреновенько. Господа, ну это же сказка! Поработаем малек?

Ах ты сволочь, ах ты падла-то вонючая! "Не могу выполнить программу из освобожденного сценария". Переменную могешь, а функцию нет?! Переменную, стало быть ты присваиваешь, а вместо тела функции указатель на нее втихаря лепишь. Тело функции тебе в переменной интерпретировать влом, тебе файл обязательно подавай. И какая, в зопу, разница?! На один кусок ОЗУ мы указатель могем поставить, а на другой нет? Вот паскуда, все настроение испортила!

Ах, ну да - тебе ж нужно обеспечить возможность использования встроенных функций по указателю, а это куда важнее. Так, остынем, подумаем. Очевидно, что я был неправ - существующая технология неизмеримо лучше. Итак, судя по всему, переменные "на морде" все-таки хранятся, хоть она и FRAMESET. Стало быть, тексты функций можно залепить именно туда. Упс! А вот этого как раз делать и нельзя - теряется динамика "толщины клиента". Иными словами, фрейм с инструментарием перезаписывать нельзя, и не перезаписывать тоже нельзя. Хоть заводи еще один промежуточный FRAMESET для хранения уже текстов функций (динамического набора и ре-инициализации опирающихся на них методов). М-д-а-а. Грустно. Впрочем, почему бы и нет - ведь это всего лишь неудобства, но не функциональные ограничения.

Ладно, допустим - базовых функций кот наплакал (их и храним на морде), а основные методы будут сосредоточены на технологии программирования в объектах - так, собссно, и планировалось. Далее: переменные, представляющие собой тело функции, тоже ведь заводить не запрещается. И, если мы динамически сгенерим страничку, запишем туда содержимое этих переменных, то эта гнида обязана (надеюсь!) посчитать их за настоящие функции. Таким образом, какая-никакая динамика даже по набору функций все же возможна, хоть это и левой ногой правое ухо. Детям, к тому же, помимо собственных текстов, доступны и родительские.

Продолжение следует...

lvqcl
Конечно, конечно . Впрочем, комментарии я как раз с удовольствием бы послушал. Даже от "dozen'a".

Продолжаю "поток сознания":

Черт, еще одна неприятность - кажись, удаление объекта по указателю не работает. По технологии "левой ноги", стало быть, нужно сгенерить дочерний фрейм с приказом удалить объект, а затем убить и сам фрейм? Весело...

Та-а-ак! А куда же повесить инициализацию на морде, чтобы она сработала до FRAMESET? Инициализацию запустить можно, наскоко я прнимаю, только из BODY, а FRAMESET еще в хидере. Таким образом, ребенок может запуститься раньше, чем завершится инициализация. И помешать этому лично я не вижу никакой возможности. Да, начинаю понимать, ПОЧЕМУ фреймы могут не нравиться - лезут поперед батьки в пекло. И как же мы раньше это обходили? Ах, да - у нас толщина клиента не менялась... Что же делать? Ага! А если флаг поставить?

Вот зараза! Флаг ставится, флаг виден, без FRAMESET по окончании инициализации снимается, а вот вместе... видимо, фрейм перехватывает управление, и не дает завершить инициализацию. Господа, а что там вместо onLoad можно предложить? Что-то я слыхивал про передачу фокуса... Ах, нет - все еще хуже: сам факт наличия FRAMESET в хидере уже есть основание "положить" на BODY. Оригинально!

Еще раз формулируем задачу: нужен один "вечно живущий" фрейм (я уж буду пока использовать этот термин), предназначенный исключительно для хранения инструментария (методы, классы, тексты основного набора функций). Над ним (вынужденно, поскольку тело функции внутри переменной непригодно для ее вызова) - второй (уже перезаписываемый) фрейм для хранения тел функций переменного состава (толщина клиента). И уже над ними - рабочие фреймы, состав которых определяется конкретной задачей. Вопрос: как это реализовать? Ах, да - до "появления на свет" второго фрейма, первый должен завершить инициализацию.

Пока суть да дело, попробуем сосредоточить тела функций на морде, а инициализацию провести из ребенка. Ух ты! Неужто работает? Ребята, а ведь это, кажись, альтернатива! И после перезаписи "толщины клиента" ре-инициализацию тоже можно выполнять из ребенка... В обчем, тьфу-тьфу.

Теперь попробуем скроить что-нить читабельное из броузера. Что нам нужно? Пока что заведем три основных объекта: c(CLASSES), d(DATA) и m(METHODS). Извиняюсь за мало прорубаемую нотацию - вся эта кухня у меня предназначена для генератора, а там все подробно излагается. Для броузера же нотация вполне съедобна - ничуть не хуже, чем любая другая (разве что компактнее).

Для затравки - перечень раннего "барахла" (просьба уточнять, дополнять, модифицировать).
Методы:
- анти-eval
- закрытие окна (Close/Delete)
- открытие окна (Create/Open)
- передача фокуса
- перечень методов/свойств объекта
- получение индекса объекта в массиве
- получение значения поля/удаление поля
- прорисовка (конструктор) объекта/класса
- прорисовка окна/фрейма, перемещение окна
- создание класса/объекта по существующему классу
Классы: button, checkbox, form, frame, hidden, image, link, option, password, radio, select, table, text, textarea, textbutton
Теги: BODY, CSS, END, HEAD, HTML, MAIN, META, SCRIPT, TITLE

Что нам нужно из методов-функций? Начальный "джентльменский набор": eval, document.close/write, new Array/Object, indexOf, substring. Плюс парсер для работы в объектах. Из данных - разделитель параметров строки объектов. Из классов... Вау! Пока ваще ничего - эта хреновина уже рисует страницы.

Короче говоря, в первом приближении старые наработки восстановлены. Раньше вся эта кухня меняла набор фреймов и палитру, как перчатки, делала итерационные запросы в зависимости от текущих данных и т.д. Теперь аккуратненько все проверим, расставив данные по нужным файлам, и займемся, наконец, классами и методами на объектах. Второй фрейм пока не нужен - затирается. Что-то мне подсказывает, что он вообще не понадобится: объем базовых функций ничтожен (на данный момент - стыдно сказать - 478 байт), и я не вижу решительно никаких поводов для его сколько-нибудь серьезного увеличения.

Продолжение следует...

Добавление от 31.07.2009 09:23:

Ну что молчим? Как там с "изобретением колеса", "номерами палат", "дохлыми" возможностями JS/IE3, "излишне усложненными структурами", "уровенем примерно 1999-го года", "слабыми представлениями принципов работы клиент-серверных приложений", толстыми и тонкими клиентами, "полноценными приложениями", супер-пупер-библиотеками? Что ж вы, черти, приуныли?

Продолжаю "поток сознания":

Так. Программирование в объектах худо-бедно работает. Возможна и рекурсия, т.е. технология стека очередей. Реализована также двухпоточная технология (сопрограммы). Теоретически можно сделать и многопоточную, но я пока не вижу этому применения. Что у нас новенького появилось? Всего-то две функции (общим весом в 157 байт): инициализация группы полей, да выполнение двух потоков (шаблон и данные). Инициализация, кстати, идет уже и через строку методов. Ах, да - завел еще один глобальный объект b(BODY) для хранения указателей на текущие объекты (т.е. для повышения универсальности кода).

Многострочные переменные, кажись, не работают. Для генератора это по фигу, а ручками писать создает некоторые неудобства. Регистр переменных важен - это неплохо. С кавычками еще морока будет... Господа, а какие еще есть кавычки (кроме двойной и одинарной). Мне бы еще пару-тройку. Чтобы в теле строки можно было использовать кавычки, а сами строки "обувать" во что-то иное.

Теперь - классы. В первую очередь - для юзера: окна, палитры, выпадающие списки и прочая хрень. Делаем минимальный набор по классам и их атрибутам, по мере необходимости пополняем. В первую очередь - окно броузера (или фрейм). Конструктор, стало быть - строка методов для его прорисовки. Пока все. Ах, да - список дочерних фреймов плюс родитель, да еще уровень иерархии (для организации доступа). Еще не помешает имя, и список событий (для обработчиков).

Конструктор окна - это в первом приближении: HEAD (TITLE, META, STYLE, SCRIPT) + BODY. Пущай будут пока атрибутами, как и сам конструктор или палитра. Впрочем, нет: палитра - вполне себе класс.

Итак, класс "фрейм" (окно, страница):
- имя класса
- имя родительского фрейма
- список имен дочерних фреймов (массив)
- уровень иерархии в группе фреймов
- используемые события (массив)
- конструктор класса (у самого класса - по умолчанию)
- палитра
Что-то коряво получается. Начнем-ка лучше с палитры - проще.

Класс "палитра":
- имя класса
- конструктор класса (видимо, только у класса - у объектов не нужен)
- цвет фона (в терминах HTML - BGCOLOR)
- цвет обычного текста (TEXT)
- цвет выделенного текста (LINK)
- цвет особо выделенного текста (ALINK)
- цвет "заблокированного" текста (VLINK)
Видимо, в BODY нужно держать ссылку на текущую палитру (в DATA - на палитру по умолчанию). Коструктор будет выглядеть примерно так (шаблон для сопрограммы):
var I='Q
w
"#"Q';
Иначе говоря, предназначен пока для выдачи по document.write, обрамляет цвет кавычками, и пришпиливает впереди знак '#'(
- разделитель параметров,  - код перехода к сопрограмме).

Создание класса (забавно, но имена атрибутов в классе вроде как и не нужны):
var I=`i
c,"p",m.o()
i
c.p,"c",'Q
w
"#"Q'`;

Ну вот и приплыли: обратный апостроф на кавычку не тянет . Впрочем, не поможет - еще и разделитель параметров, код передачи сопрограмме... Значит, делать будем в два приема. Примерно так:
var J='Q
w
"#"Q';
var I='i
c,"p",m.o()
i
c.p,"c",J';
Это - работает.

Итак, класс (в первом приближении) заведен. Теперь инициализация объекта палитры. Ух ты! Даже не ожидал. Переменной pal в коде нет (заводится динамически, в строке методов), но... взгляните на код:
Первый alert генерит ошибку, и прекращает выполнение программы - дескать, "не определен объект pal". Если же его убрать - второй прекрасно работает, т.е. видит не только саму переменную, но и ее поля "внутре" (в данном случае выдает цвет фона). Отлично!

Хм. А на хрена нам вообще этот объект? Пущай все палитры в классе и сидят как массив. Не, это уж совсем неприлично. Да и неудобно с индексами. Положим-ка мы их в DATA, а то там окромя разделителей ни хрена нет. Штучки три - с белым, черным и синим фоном. И в BODY по умолчанию - с белым.

Упс! Парсер написан неправильно. Точнее, рекурсивный вызов работает, сопрограммы без рекурсии - тоже, а вот вместе... Ладно, не горит. Опосля как-нить, устал я что-то.

Продолжение следует...

Так я что-то не понял: здесь вообще живые люди есть? Программисты, в смысле? Или только эти... распальцованные? Способные лишь на советы типа "использовать библиотеки" - потрясающая мудрость! Али тема неинтересна? Смешно - это и есть тема всей конфы. Ладно, подождем еще малек - вдруг чудо...

Продолжаю "поток сознания":

Нет, так дело не пойдет - неудобства с вызовом будут только нарастать. Нужно разобраться с парсером и сопрограммами раз и навсегда. А, понятно - я же использую программный стек, а каждая из сопрограмм должна работать на своем собственном. Значицца, две функции требуют серьезной переделки... Ух, и неохота! Да и жалко однопоточный парсер, честно говоря. Программный стек, опять же, "на самообслуживании"...

От программного стека, разумеется, придется отказаться - безнадежно, это мы уже проходили. А вот парсер, кажись, можно сохранить. Только ему вместо "сопрограммного" перехода нужно научиться управлять стеками. Блин, что ни делаешь - все равно пулемет получается, то бишь SINT. Значит, нам нужно: рекурсия внутри одного потока (call/return), переключение управления между потоками (сопрограммы) - при этом первый поток всегда управление (шаблон), второй - данные, требующиеся этому шаблону. Заодно неплохо бы сделать "двупоточную рекурсию" - второй поток становится первым, а вторым ему подсовываются его "персональные" данные - тогда виртуальное число потоков может быть любым (при двух стеках). Ну что же, попробуем...

Вначале промоделируем мысленно управление потоками (чтобы потом не было мучительно больно). Итак, генерация страницы. Первый поток - шаблон, второй - данные (для простоты - из двух частей, скажем, содержимое тега TITLE, а затем - BODY). Все оформление страницы, допустим, лежит на шаблоне. Тот начинает:
<HTML><HEAD... Нет, HEAD пущай будет самостоятельной строкой методов (в терминологии SINT - очередь). Тогда - ныряем в стек очередей первого потока.
<HEAD><TITLE... ныряем еще раз.
<TITLE> а теперь прыгаем на второй поток:
TEST и снова на первый
</TITLE> - данные закончились, "выныриваем".
<META...<STYLE...</STYLE><SCRIPT...src=" Ага! Нужны данные из потока, но НЕ ТЕ. Стало быть, SCRIPT - это тоже отдельная очередь. И не просто очередь, а очередь со своими собственными данными. Значит, ныряем в оба стека: сначала переустанавливаем стек данных (второго потока), затем по обычной технологии ныряем в первый стек.
PUSH (строка с именем(ами) включаемых файлов)
<SCRIPT language="JavaScript" src=" - прыг!
test.js - скок!
" type="text/JavaScript">
POP - восстанавливаем стек данных
</SCRIPT> - вынырнули
</HEAD> - еще раз вынырнули
<BODY BGCOLOR=... стоять! Выдача палитры должна быть еще хитрее. Ныряем:
PUSH (очередь метода выдачи палитры)
BGCOLOR="

А теперь смертельный номер: метод выдачи цвета - это шаблон (т.е. ПЕРВЫЙ поток), но лежит он в данных (во ВТОРОМ потоке). Значит...

Надо же! Ничего "смертельного" чтой-то не просматривается - обычная рекурсия.
w
"BGCOLOR="
_
c.p.cw
" TEXT="
_
c.p.cw
" VLINK=... - шаблон
w
b.p.bw
b.p.tw
b.p.v... - данные. Неужто так просто?!

Да уж, "просто"! Ручками написать такое - 5 секунд, а я уже второй день маюсь. Да и "смертельный номер" наверняка в будущем понадобится. Что же в награду? А в награду - возможность выдачи страниц каждому юзеру в "его собственной" палитре. Не так уж и мало! Не говоря уже про "бесплатное приложение" в виде базовых функций и методов инициализации. Если, конечно, все это вообще работает. Попробуем запрограммировать... goto убрали, козлы!

А ну, господа, поделитесь, как там "с использованием библиотек" полагается менять палитру на странице? Вот смеху будет, если хваленые библиотеки даже этого не умеют. А ведь не умеют - зуб даю! Впрочем, я пока что тоже не умею.

Продолжение следует...

Vladimir Rybinkin
Извините, Владимир, но я почитал-почитал... и ничего не понял.. Вы чего хотите то?
В одном предложении, пожалуйста.

О! Провокация на ответ удалась.

Sioln
В одном предложении... А разве это будет легче понять? Пожалуйста: хочу инструментарий на JS/IE3, позволяющий с максимальными удобствами реализовывать все, что нужно конечному пользователю (в идеале - пользователю СУБД). Ну и первый тест подоспел - можно посмотреть...

Продолжаю "поток сознания":

Значит, нам понадобится массив стеков на BODY (вдруг больше двух потребуется), каждый из которых тоже массив, но уже строк. Там же индекс текущего стека для ориентировки, где находимся. Инициализируем стек шаблонов стартовой очередью, и вперед (второй стек уже в парсере и изготовим).

Во дела! Никак не думал, что так легко пойдет. Шарахнул контекстной заменой, и всего-то пара ошибок по невнимательности. Так защищаться можно!

Так, понятно - не хвались, едучи на рать... Чо-то я ваще ни хрена не понимаю: если я завожу элемент массива с индексом, равным его длине, то длина, как и положено увеличивается на 1. А если я этот элемент УДАЛЯЮ, то длина НЕ МЕНЯЕТСЯ! При этом элемент становится undefined, а следующему за ним хоть бы хны! Оба-на! А если внаглую length--, то все путем?! Я хренею, дорогая редакция! Ну... допустим - бум надеяться, что это хозяйство работает ПРАВИЛЬНО. Хотя дырявые массивы смотрятся несколько странно.

А вот за goto я не только руки, но и ноги бы повыдергивал. Пижоны! Из-за этого (и невозможности удаления объектов по указателю) приходится код дублировать. Ладно, особого сопровождения не предвидится - потерпим. А куда ж ты на фиг денешься!

Еще раз формулируем технологию. Вначале - инициализация "морды". Минимально необходимая - функцией по onLoad, затем - строкой методов. Функция на текущий момент - это (260 байт все удовольствие):

var r="parent.";function _(){var x,y,z="bcdm";for(x=0;x<z.length;x++)
{y=z.charAt(x);eval(r+y+"=new Object");eval(y+"="+r+y);}m.e=eval;
z="afios_";for(x=0;x<z.length;x++){y=z.charAt(x);m.e("m."+y+"="+r+y);}
b.s=m.a();b.s[0]=m.a();b.i=0;d.D="
";b.s[0[0]]=I;m._();}

Лана, дам уж комментарии от генератора, а то и свихнуться недолго.
Таким образом, все глобальные объекты заведены, все тексты (неизменяемых) функций морды переведены в методы. Теперь инициализация в парсере: создаем стек данных, код перехода на сопрограмму (коды разделителей на всякий случай хранятся как данные - вдруг динамическая замена потребуется). Затем инициализация необходимых встроенных функций (типа alert или document.write). Затем наполнение объектов CLASSES и DATA, установка текущих параметров на BODY, и... все - перерисовка на рабочий кадр. Приступим.

Стек данных завели... встроенные методы тоже... палитру (класс) с конструктором... шаблоны страницы, HEAD и TITLE... указатели на них из BODY... двухпоточный запуск... псевдо-рекурсия... переход на сопрограмму... псевдо-return... Работает!

Честно говоря, думал, что быстрее получится. Старею. Но и отладчик "классный" - то "работает" (точнее, ни фига не делает, но и не ругается - типа, "выполнено"), то прикалывается (неопределенная ошибка), то лепит горбатого ("ожидается наличие объекта" - не там, и не по делу - "универсальная" диагностика на целый спектр различных ошибок). Впрочем, это все мелочи, главное - имеем (принципиально) любую динамику по данным и переменную толщину клиента. Ах, да - если существует второй фрейм... доступ к данным через лишний parent... работает! А запись в родителя (то бишь удаление второго фрейма из третьего)... аналогично переопределяем document.write/close... работает! На этот раз обе проверки прошли с первого тыка. Не зря возился!

Уф! Готов первый тест для броузера. Кому интересно - в аттаче. Еще бы теперь научиться выполнять document.open/read, и тогда нам сам черт не брат! Так хто там бочку катил на JS/IE3?!

Продолжение следует...

Vladimir Rybinkin
хочу инструментарий на JS/IE3, позволяющий с максимальными удобствами реализовывать все, что нужно конечному пользователю (в идеале - пользователю СУБД).
Эм... т.е. проверку прав тоже на клиенте делать будем?
Или Вам не инструментарий, а GUI надо?

Добавление от 03.08.2009 16:16:

Перечитываю и ещё больше не понимаю.. Вам IDE на JS хочется?

Добавление от 03.08.2009 16:17:

Запустил ваш "тест"