привет! была тема о недостатках JSCRIPT. но чаще всего в последнее время я начал сталкиваться с такой проблемой как ограничение использования JSCRIPT не только в страницах, но в приложениях HTA. в каких случаях дизайнер/разработчик может применить JSCRIPT, а в каких нет? 

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

Это сообщение отредактировал(а) JSman - 25.8.2006, 00:44

Конкретней опиши идею. Разработчик в 90% случаев будет юзать JS, специфичные для JScript вещи это new ActiveXObject, Dictionary и API поддерживаемое IE. Сам язык от эталона (ECMA-262) по моему не отличаеться вовсе.

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

рационально ли использование COM объектов? по моему мнению они очень медлительны и от них стоит отказаться - один FSO чего стоит - медленный. помню папка system32 секунд 8 считывалась.

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

говоря об ограничениях JSCRIPT, то он отвратительно работает с реестром в силу своей архитектуры (есть 1 целый тип определенного размера). ведь каждый ключ имеет определенную длину, и  некоторые из них могут вызвать ошибку при записи в них числа, так как формат чисел JSCRIPT > формата хранения данных ключа. (взято с WDH+)

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

и многое другое...

когда мы кладем слишком большие полномочия на JSCRIPT он может не справится со поставленной задачей. медлительность, ошибки майкрософт... каково ваше мнения о рамках использования JSCRIPT?

Добавлено @ 03:03 
допустим, что я решил создать красивое, быстрое приложение. как пойти дальше от этого?

Так, значит JScript в виндовых административных скриптах, так бы и начал с этого.

Ты извращенец   это во первых, во вторых попользовав bash + coreutils в линухе, ты сам это поймёшь.
JScript не удобен потому, как не умеет сам ничего, только пользует готовые обьекты, только вот пользование их не выходит в одну строчку, отсюда даже самый простой скрипт получаеться раздутым.

Всё, больше JS ничем не ограничен. Просто нужно выбирать скрипты под задачу, JS это клей/скриптовый интерфейс в неком сложном окружении с массой обьектов (API окружения). Без каких либо ограничений или стандартов на это окружение, т.е. JS можно внедрить куда угодно.


Ну вот будет XAML под виндой, сможешь создать нормальное приложени по виду. По функционалу окружение будет скорее всего новым, ибо даже FSO глючит (не любит пробелы), что уже давно не "детские болезни" и порядком поднадоело. M$ это понимает и это хорошо. Сейчас же лучше писать на Python/Ruby/TCL + QT/GTK или на Java.

все чаще и чаще разрабатываются приложения с Web-интерфейсом. JSCRIPT - "клей" между (во многих случаях) DOM и внешними приложениями. но все эти напридуманные дополнительные объекты (типа FSO) лишь тормозят систему. итак, мы сталкиваемся с рамками использования скрипта.. следовательно, я настаиваю на отказе от объектов ActiveXObject. 

идея HTA мне очень понравилась. но попользовавшись, начинаешь  понимать, что инструментария для создания проги нет. с XALMoм будет такая же проблема.



 

  со стандартным функционалом далеко не уйдешь.
 XALM  - медлительное существо.  заранее знаем, что это для новичков.

каков алгоритм создания "красивого, быстрого" приложения?
какова доля участия JSCRIPT там? ведь мы знаем, что функции можно описывать не только в скрипте, но и в коде проги.

много мыслей на этот счет. хочу собрать воедино.

Э... ты успел уже всё потестить? Вообще знаешь что есть XAML, Windows Presentation Foundation и т.д.? То что GUI и графические примочки могут быть скриптовыми доказали маки с их десктопными апплетами, в KDE по моему они тоже есть. Сейчас в мозилле есть XUL для разметки вида и JS для активного кода, не сказать что летает, но красиво, удобно, терпимо.


Так, всё, собери мысли в кучу и точно поясни что ты спросил. Перечитай свой вопрос по новой. Где там? JScript фишка мелкософта, почти не отличаеься от стандартного ECMA-262. Если иметь нормальное мощное окружение, то JS хватит за глаза (и даже будет черезвычайно удобно) что бы писать проги. Именно логику проги, а не низкоуровневые операции, т.к. GUI, визарды, разного рода use-case это всё скриптовые (делай это, делай то) вещи, вот и держать их лучше в скриптовом виде.

P.S. вижу начинаеться вырисовываться картинка, отвечу сразу: у JS нет ограничений, есть ограниченное окружение куда JS помещён. Освободи сознание, зри в корень.

ясно  
технологии, которые появляются,  я к ним отношусь скептически.. да и ждать как ламо..

говоря о создании самих приложений, основанных на HTML, что можно посоветовать?
типа:

взять делфю, кинуть веб-браузер, разрешить привилегии, 
контент должен иметь поменьше динамики, чтобы уменьшить утечку памяти
кинуть сурс в ресурсы длл
скрипты, кодить при работе с окном, а не при тяжких подсчетах 
поменьше активИкс
и тд


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

как бы ты подошел к этой проблеме?
имеет ли место JS? в чем?
прога должна быть на стороне клиента. работать у всех

Добавлено @ 00:43 
кстати, я стал Шустрым )))

А зря, главное время найти на изучение, оно потом опытом и скоростью разработки отблагодарит 


HTA приложение это по сути документ, запускаеться виндовым стартером двумя кликами как обычная прога, писать свой "загрузчик/просмотрщик" не нужно. Утечки памяти только в IE и только при связи DOM нод с JS обьектами (например функциями). Обойти можно, но оно претит рассудку   

НО! помимо IE есть ещё вполне здоровый XUL, глянь на XULplanet.com, не всё задокументировано, но хватает что бы накидать окошки своего плагина. Не только плагин к браузеру, но и полноценное приложение можно написать, естественно от Gecko движка ты будешь зависеть.


Обычный документ/шкурка к инфо-системе. Генерим таблицу сразу на сервере, хотя можно загрузить аяксом (не люблю первую пустую страничку...). На редактируемых ячейках ловим клик мыши, для любителей клавы можем обернуть ячейку в ссылку, будет доступна по tab'у. По клику сменяем содержимое ячейки на input:text или какой собственный редактор. В момент редактирования посылаем запросы аяксом для подсказок и вариантов. Как закончили, аяксом отсылаем изменения в ячейке, редактор замещаем полученным вводом/текстом.

Потребуеться:
знание DOM
знание XmlHttpRequest или обёрток
знание XPath если ответы в XML и не хочеться работать с DOM напрямую

Естественно JS и верстать со стилями ты должен уметь. Работа примерно на неделю с нуля. Примеры с клик->замена ячейки на input:text и отправка изменений (правда в форме, не аяксом) был0 на форуме где то пол года назад.

самое интересное я это все написал давно, по-свому конечно. могу код выложить.  и не фига. 

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

подумал, что не стоит этих мучений HTA, а стоит использовать макрософт в своей оболочке.
заметим, что фатальных ошибок не было в обозревателе.

не хочу я геко. верстка на майкрософте интереснее

Пока весь топик не читал, сори... Есть необходимость разобрать некоторые из методов, которые использует Осел в своих внутренних страницах (протокол res://). Где почитать на тему 
? (Применение ограничено только Ослом)

bems

Боже мой, ну конечно же в MSDN Library!

без проблем разберем. ждем любые вопросы про протокол res.

протокол res - один из протоколов Windows. Следовательно поддерживается из браузеров только Осликом. используется тогда, когда страница ссылается на ресурсы файла типа exe, dll и другие форматы, когда есть острая необходимость скомпоновать компоненты в один файл для эстетической стороны или может быть какой-либо задумки.. протокол res еще не разработан до конца. существует большое количество багов, особенно при наличии ресурсов, используемых ActiveX объектами, например Adobe Flash.. в Висте многие ошибки исправили, но несовместимость осталась.. 

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

в этом как раз еще одно ограничение использования JScript..

Какие например баги? По мне, все работает хорошо. И с ActiveX что не так?

На эту тему поподробнее, если можно...

И вообще какие отличия в поведении от версии к версии?