Sioln
Продолжаю "поток сознания":
Что-то все-таки не то. Даже сформулировать не могу. Периодически происходит нечто странное: выскакивают ошибки типа "неопределенная ошибка" (детектировать, стало быть, можно, а понять, чего именно поймал - ну никак низзя!) или "неожиданный вызов функции" (раз двадцать вызывалась без проблем, а потом бац - и глаза на лоб). При этом дальнейшая работа то абсолютно правильная, как будто никакой ошибки и не было, то аварийная остановка. Такое ощущение, что всякие генерируемые теги script начинают жить своей жизнью (интерпретироваться раньше времени). Впрочем, не уверен. Но раздражает. Текстов-то с гулькин нос, интерпретируй не хочу - чего выеживаться?
Что же нам делать с document.read? Не видать чтой-то такого сервиса. А чего у него вообще есть? Вот зараза, не показывает! А window? Этот - пожалуйста, со всей душой. Так...
Ух ты! clipboardData="[object]" это что за зверюга такая? dropEffect... effectAllowed... Ни хрена не понял!
document="[object]" - Ну?! А этот "object" покажешь? Ах ты гнида! А почему?! А, ну конечно - "неопределенная ошибка" - куды уж тебе разобраться...
Чо только не придумают! onbeforeprint, onbeforeunload...
Вау! window.body - пустота, а на window.document.body... Ой, скоко ж тут дерьма-то всякого понавалено... canHaveChildren... и как они сами-то в таком кошмаре разбираются? Ага! innerHTML, innerText - это уже интересно... Но не совсем то... nodeName="BODY" - О! Верно! Теплее, теплее... outerHTML, parentElement, parentNode, readyState="complete" - одуреть! Так, стоп! А почему ошибки на этот раз нет?! Ага, зараза! От нас не скроешься!
О, Господи! Очередная порция, так сказать, параметров. Длиной в километр. activeElement, applets, childNodes, documentElement, protocol, scripts, security... Господа, тону! Кто здесь плавал - помогите! Теперь я понимаю броузер - где ж тут определиться с ошибкой - сам черт ногу сломит!
Тем не менее, доступ к телу (BODY) в виде HTML и в виде текста получен - ура! Теперь бы еще к HEAD. Ну, к TITLE - понятно...
Впрочем, чего я страдаю? С HEAD как-нить на досуге разберемся. А все остальное принципиально имеется - все, что и хотелось: переписывать кадр умеем, с полями объектов проблем особых нет, ссылки худо-бедно эмулирем, обмен данными между фреймами моделировали, доступ к телу "вражьей" страницы обозначился... С событиями еще не работали, но особо пока и не требуется. Теперь остается техника - как именно лучше всего реализовать текущие требования. Ау, господа - навалимся гурьбой?
Для полного счастья нужно: обсудить и отладить структуру паспортов для выдачи таблиц, списков и разных прочих промптов, методы обмена данными (в т.ч. с Инетом), оформления страниц, разных полезных вкусностей. В этих моих "учебных" примерах приводится какая-то абсолютная хрень - прыгает чего-то, мельтешит... А какой внешний (оформительский) инструментарий НА САМОМ ДЕЛЕ нужен? Идеальный, для ПОЛНОГО счастья, поскольку принципиальных ограничений по возможностям лично я УЖЕ не вижу (кто знает - вэлкам, тоже важно). Так какая для этого нужна БИБЛИОТЕКА?
Поток сознания закончился. Теперь - техника.
Во-первых, а не зря ли я программный стек отменил? Вызов-то удобнее. Да и какое дело прикладнику до стеков (тем более, до стеков очередей)? В SINT у меня сделано хитрее... Ладно, попробуем:
Имеем: системный объект (с паспортом), стеки очередей и парсер, по ним ползающий. Из прикладного уровня не вызываемый (не в смысле недоступный, а по соглашению). Вызывается же он из прикладного парсера, либо из двухпоточной зарядки, либо из строки методов. Тогда стартовая инициализация должна выглядеть примерно так:
Во-первых, морда. Предположим, что на сайте допускается сразу два типа обслуживания: с постоянной (скажем, index.htm) и переменной (index.html) толщиной клиента. Оба входа предназначены исключительно для хранения глобальных объектов, методов и текстов глобальных функций. Во втором случае предполагается промежуточный дочерний фрейм для хранения текстов функций переменного состава. Сын же index.htm (или внук index.html) - это уже головной рабочий кадр. Если и он фреймообразующий, рабочими становятся уже внуки (правнуки). Дальше в "генеалогию" лезть как будто незачем.
Поскольку инициализация (да и работа) по любому входу во многом совпадает, инициализацию запустим по общему алгоритму, при этом тип обслуживания будет определяться по идентифицирующей переменной на морде (по самому факту ее существования) - см. аттач. Загрузочный фрейм (всегда сын) создает и инициализирует объекты на морде, после чего переписывает себя либо на рабочий кадр, либо на кадр хранения текстов переменного состава. В последнем случае... нет, что-то лень мне заниматься тем, что может вообще не понадобиться. Короче, ответвление обозначено, реализация - в случае возникновения потребности, принципиальная возможность имеется - проверено.
Рабочий кадр любого уровня иерархии получает доступ к данным и методам через единственное определение r="parent.[parent.][parent.]..."; В остальном тексты кадров разных уровней неотличимы (если, конечно, выполняют ту же работу). Обмен данными между фреймами либо непосредственно по имени, либо через кого-то из родителей (уж морда-то всякому родитель).
Перечень основных функций (аттач, файл a.j) неизменен, приложение к морде. Это по определению наиболее важные (оптимизированные, отлаженные) функции, посему просьба критиковать и состав, и содержимое.
Начальная загрузка (файл a.h -> b.j): создание объектов и методов (той самой пресловутой "библиотеки"), загрузка начального рабочего кадра (то бишь "настоящего" index.htm, предназначенного для посетителя сайта), и обеспечение доступа к этой библиотеке создателю странички (прикладнику). Никакого контроля за деятельностью прикладника не проводим (не транслятор, чай), считаем, что он и сам соображать должен (тем более, что "прикладник" - это я и есть). Инструментарий должен обеспечивать максимально комфортную реализацию всего того, что взбредет в голову прикладнику и, если тот позволит - конечному пользователю. Господа прикладники, изложите, плиз, что же вашей душе угодно? Каких возможностей не хватает при разработке? При сопровождении? Чего не хватает юзеру? Чем его можно заинтересовать, чтобы он, придя на ваш сайт, отправился дальше именно в ваших "доспехах"? Или даже собирал бы себе клиента с "разных" сайтов. Во игрушка-то, а? Кстати, разобрался с "неожиданным вызовом" - переопределяю m.e=eval; - неожиданности заканчиваются. . Остальным встроенным функциям (типа alert) - по барабану. Ну и гадюшник!
Для затравки: я тут грозился arsa сотворить клиента для google (сервис для уточнения запросов). Попробуем, что ли?
Снова прошу перечень ваших (обсуждаемых в этой конфе) проблем. А то у меня появляется нехорошее ощущение, что я уже умею все, что душе угодно.
Продолжение следует...
Эм... т.е. проверку прав тоже на клиенте делать будем?
Почему на клиенте? Какие вообще проблемы с проверкой прав? Или Вам не инструментарий, а GUI надо?
Инструментарий. В том числе для GUI.Вам IDE на JS хочется?
А что такое IDE? Запустил ваш "тест"
Из архива, что ли? У меня прекрасно запускается... Или у MSIE 8.0 (у меня 5 или 6 - не помню) какие-то навороты? Или NT 6.0 (98) чего-то надо? Или настройки чего-то не позволяют? Там же (в тесте) НУ НИЧЕГО нет!Продолжаю "поток сознания":
Что-то все-таки не то. Даже сформулировать не могу. Периодически происходит нечто странное: выскакивают ошибки типа "неопределенная ошибка" (детектировать, стало быть, можно, а понять, чего именно поймал - ну никак низзя!) или "неожиданный вызов функции" (раз двадцать вызывалась без проблем, а потом бац - и глаза на лоб). При этом дальнейшая работа то абсолютно правильная, как будто никакой ошибки и не было, то аварийная остановка. Такое ощущение, что всякие генерируемые теги script начинают жить своей жизнью (интерпретироваться раньше времени). Впрочем, не уверен. Но раздражает. Текстов-то с гулькин нос, интерпретируй не хочу - чего выеживаться?
Что же нам делать с document.read? Не видать чтой-то такого сервиса. А чего у него вообще есть? Вот зараза, не показывает!
А window? Этот - пожалуйста, со всей душой. Так...Ух ты! clipboardData="[object]" это что за зверюга такая? dropEffect... effectAllowed... Ни хрена не понял!
document="[object]" - Ну?! А этот "object" покажешь? Ах ты гнида! А почему?! А, ну конечно - "неопределенная ошибка" - куды уж тебе разобраться...
Чо только не придумают! onbeforeprint, onbeforeunload...
Вау! window.body - пустота, а на window.document.body... Ой, скоко ж тут дерьма-то всякого понавалено... canHaveChildren... и как они сами-то в таком кошмаре разбираются? Ага! innerHTML, innerText - это уже интересно... Но не совсем то... nodeName="BODY" - О! Верно! Теплее, теплее... outerHTML, parentElement, parentNode, readyState="complete" - одуреть! Так, стоп! А почему ошибки на этот раз нет?! Ага, зараза! От нас не скроешься!
О, Господи! Очередная порция, так сказать, параметров. Длиной в километр. activeElement, applets, childNodes, documentElement, protocol, scripts, security... Господа, тону! Кто здесь плавал - помогите! Теперь я понимаю броузер - где ж тут определиться с ошибкой - сам черт ногу сломит!
Тем не менее, доступ к телу (BODY) в виде HTML и в виде текста получен - ура! Теперь бы еще к HEAD. Ну, к TITLE - понятно...
Впрочем, чего я страдаю? С HEAD как-нить на досуге разберемся. А все остальное принципиально имеется - все, что и хотелось: переписывать кадр умеем, с полями объектов проблем особых нет, ссылки худо-бедно эмулирем, обмен данными между фреймами моделировали, доступ к телу "вражьей" страницы обозначился... С событиями еще не работали, но особо пока и не требуется. Теперь остается техника - как именно лучше всего реализовать текущие требования. Ау, господа - навалимся гурьбой?
Для полного счастья нужно: обсудить и отладить структуру паспортов для выдачи таблиц, списков и разных прочих промптов, методы обмена данными (в т.ч. с Инетом), оформления страниц, разных полезных вкусностей. В этих моих "учебных" примерах приводится какая-то абсолютная хрень - прыгает чего-то, мельтешит... А какой внешний (оформительский) инструментарий НА САМОМ ДЕЛЕ нужен? Идеальный, для ПОЛНОГО счастья, поскольку принципиальных ограничений по возможностям лично я УЖЕ не вижу (кто знает - вэлкам, тоже важно). Так какая для этого нужна БИБЛИОТЕКА?
Поток сознания закончился. Теперь - техника.
Во-первых, а не зря ли я программный стек отменил? Вызов-то удобнее. Да и какое дело прикладнику до стеков (тем более, до стеков очередей)? В SINT у меня сделано хитрее... Ладно, попробуем:
Имеем: системный объект (с паспортом), стеки очередей и парсер, по ним ползающий. Из прикладного уровня не вызываемый (не в смысле недоступный, а по соглашению). Вызывается же он из прикладного парсера, либо из двухпоточной зарядки, либо из строки методов. Тогда стартовая инициализация должна выглядеть примерно так:
Во-первых, морда. Предположим, что на сайте допускается сразу два типа обслуживания: с постоянной (скажем, index.htm) и переменной (index.html) толщиной клиента. Оба входа предназначены исключительно для хранения глобальных объектов, методов и текстов глобальных функций. Во втором случае предполагается промежуточный дочерний фрейм для хранения текстов функций переменного состава. Сын же index.htm (или внук index.html) - это уже головной рабочий кадр. Если и он фреймообразующий, рабочими становятся уже внуки (правнуки). Дальше в "генеалогию" лезть как будто незачем.
Поскольку инициализация (да и работа) по любому входу во многом совпадает, инициализацию запустим по общему алгоритму, при этом тип обслуживания будет определяться по идентифицирующей переменной на морде (по самому факту ее существования) - см. аттач. Загрузочный фрейм (всегда сын) создает и инициализирует объекты на морде, после чего переписывает себя либо на рабочий кадр, либо на кадр хранения текстов переменного состава. В последнем случае... нет, что-то лень мне заниматься тем, что может вообще не понадобиться. Короче, ответвление обозначено, реализация - в случае возникновения потребности, принципиальная возможность имеется - проверено.
Рабочий кадр любого уровня иерархии получает доступ к данным и методам через единственное определение r="parent.[parent.][parent.]..."; В остальном тексты кадров разных уровней неотличимы (если, конечно, выполняют ту же работу). Обмен данными между фреймами либо непосредственно по имени, либо через кого-то из родителей (уж морда-то всякому родитель).
Перечень основных функций (аттач, файл a.j) неизменен, приложение к морде. Это по определению наиболее важные (оптимизированные, отлаженные) функции, посему просьба критиковать и состав, и содержимое.
Начальная загрузка (файл a.h -> b.j): создание объектов и методов (той самой пресловутой "библиотеки"), загрузка начального рабочего кадра (то бишь "настоящего" index.htm, предназначенного для посетителя сайта), и обеспечение доступа к этой библиотеке создателю странички (прикладнику). Никакого контроля за деятельностью прикладника не проводим (не транслятор, чай), считаем, что он и сам соображать должен (тем более, что "прикладник" - это я и есть
). Инструментарий должен обеспечивать максимально комфортную реализацию всего того, что взбредет в голову прикладнику и, если тот позволит - конечному пользователю. Господа прикладники, изложите, плиз, что же вашей душе угодно? Каких возможностей не хватает при разработке? При сопровождении? Чего не хватает юзеру? Чем его можно заинтересовать, чтобы он, придя на ваш сайт, отправился дальше именно в ваших "доспехах"? Или даже собирал бы себе клиента с "разных" сайтов. Во игрушка-то, а? Кстати, разобрался с "неожиданным вызовом" - переопределяю m.e=eval; - неожиданности заканчиваются. . Остальным встроенным функциям (типа alert) - по барабану. Ну и гадюшник!Для затравки: я тут грозился arsa сотворить клиента для google (сервис для уточнения запросов). Попробуем, что ли?
Снова прошу перечень ваших (обсуждаемых в этой конфе) проблем. А то у меня появляется нехорошее ощущение, что я уже умею все, что душе угодно.
Продолжение следует...
К сообщению приложены файлы:
). Я просто балдею - сам же, дубина, интерпретируешь! Не видишь, что ли, что страница ТА ЖЕ САМАЯ?! Ну и лепит то, что по дурости своей считает "предыдущей страницей" (точнее, страницАМИ)... Все, естественно, перестает работать.
