Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > JavaScript: Общие вопросы > ограничения JSCRIPT

Автор: JSman 25.8.2006, 00:41

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

Автор: Sardar 25.8.2006, 01:09

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

Автор: JSman 25.8.2006, 03:01

целью разработчиков является создание функциональных, быстрых, хорошо оформленных приложений. разумеется будем говорить о дополнениях к JSCRIPT. я хотел бы посвятить топик использованию альтернатив к стандартным подходам к реализации какой-либо функции на JSCRIPT. рационально ли использование COM объектов? по моему мнению они очень медлительны и от них стоит отказаться - один FSO чего стоит - медленный. помню папка system32 секунд 8 считывалась. мне кажется, когда мы используем объект, и его свойства по большому счету не очень нужны, то рациональна альтернатива использования операций над файлами, например, через простые программы, к которым обращаются через командную  строку. говоря об ограничениях JSCRIPT, то он отвратительно работает с реестром в силу своей архитектуры (есть 1 целый тип определенного размера). ведь каждый ключ имеет определенную длину, и  некоторые из них могут вызвать ошибку при записи в них числа, так как формат чисел JSCRIPT > формата хранения данных ключа. (взято с WDH+) решением проблемы, я считаю - создание reg файла. а запуск reg файлов опять же через внешнюю программу...  и многое другое... когда мы кладем слишком большие полномочия на JSCRIPT он может не справится со поставленной задачей. медлительность, ошибки майкрософт... каково ваше мнения о рамках использования JSCRIPT? Добавлено @ 03:03  допустим, что я решил создать красивое, быстрое приложение. как пойти дальше от этого?

Автор: Sardar 25.8.2006, 12:11

Так, значит JScript в виндовых административных скриптах, так бы и начал с этого. Ты извращенец   это во первых, во вторых попользовав bash + coreutils в линухе, ты сам это поймёшь. JScript не удобен потому, как не умеет сам ничего, только пользует готовые обьекты, только вот пользование их не выходит в одну строчку, отсюда даже самый простой скрипт получаеться раздутым. Всё, больше JS ничем не ограничен. Просто нужно выбирать скрипты под задачу, JS это клей/скриптовый интерфейс в неком сложном окружении с массой обьектов (API окружения). Без каких либо ограничений или стандартов на это окружение, т.е. JS можно внедрить куда угодно. Цитата(JSman @  25.8.2006,  02:01 ) допустим, что я решил создать красивое, быстрое приложение. как пойти дальше от этого?  Ну вот будет XAML под виндой, сможешь создать нормальное приложени по виду. По функционалу окружение будет скорее всего новым, ибо даже FSO глючит (не любит пробелы), что уже давно не "детские болезни" и порядком поднадоело. M$ это понимает и это хорошо. Сейчас же лучше писать на Python/Ruby/TCL + QT/GTK или на Java.

Автор: JSman 25.8.2006, 19:57

Цитата(Sardar @  25.8.2006,  12:11 ) Так, значит JScript в виндовых административных скриптах, так бы и начал с этого. все чаще и чаще разрабатываются приложения с Web-интерфейсом. JSCRIPT - "клей" между (во многих случаях) DOM и внешними приложениями. но все эти напридуманные дополнительные объекты (типа FSO) лишь тормозят систему. итак, мы сталкиваемся с рамками использования скрипта.. следовательно, я настаиваю на отказе от объектов ActiveXObject.  идея HTA мне очень понравилась. но попользовавшись, начинаешь  понимать, что инструментария для создания проги нет. с XALMoм будет такая же проблема.

Автор: JSman 25.8.2006, 20:19

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

Автор: Sardar 25.8.2006, 21:06

Цитата(JSman @  25.8.2006,  19:19 )  XALM  - медлительное существо.  заранее знаем, что это для новичков. Э... ты успел уже всё потестить? Вообще знаешь что есть http://en.wikipedia.org/wiki/XAML, Windows Presentation Foundation и т.д.? То что GUI и графические примочки могут быть скриптовыми доказали маки с их десктопными апплетами, в KDE по моему они тоже есть. Сейчас в мозилле есть XUL для разметки вида и JS для активного кода, не сказать что летает, но красиво, удобно, терпимо. Цитата(JSman @  25.8.2006,  19:19 ) какова доля участия JSCRIPT там? ведь мы знаем, что функции можно описывать не только в скрипте, но и в коде проги. Так, всё, собери мысли в кучу и точно поясни что ты спросил. Перечитай свой вопрос по новой. Где там? JScript фишка мелкософта, почти не отличаеься от стандартного ECMA-262. Если иметь нормальное мощное окружение, то JS хватит за глаза (и даже будет черезвычайно удобно) что бы писать проги. Именно логику проги, а не низкоуровневые операции, т.к. GUI, визарды, разного рода use-case это всё скриптовые (делай это, делай то) вещи, вот и держать их лучше в скриптовом виде. P.S. вижу начинаеться вырисовываться картинка, отвечу сразу: у JS нет ограничений, есть ограниченное окружение куда JS помещён. Освободи сознание, зри в корень.

Автор: JSman 26.8.2006, 00:42

ясно   технологии, которые появляются,  я к ним отношусь скептически.. да и ждать как ламо.. говоря о создании самих приложений, основанных на HTML, что можно посоветовать? типа: взять делфю, кинуть веб-браузер, разрешить привилегии,  контент должен иметь поменьше динамики, чтобы уменьшить утечку памяти кинуть сурс в ресурсы длл скрипты, кодить при работе с окном, а не при тяжких подсчетах  поменьше активИкс и тд у меня было задание. имеется база данных. через строку поиска извлекаются данные ввиде таблицы. но сложности задания были в чем.. таблица результатов поиска должна была быть редактируемой как в ворде, а при вводе текста в поле ввода или в любую другую редактируемую область документа должен был появляться умный горячий список... и все должно быть красиво и сохранять отчеты... как бы ты подошел к этой проблеме? имеет ли место JS? в чем? прога должна быть на стороне клиента. работать у всех Добавлено @ 00:43  кстати, я стал Шустрым )))

Автор: Sardar 26.8.2006, 19:04

Цитата(JSman @  25.8.2006,  23:42 ) технологии, которые появляются,  я к ним отношусь скептически.. А зря, главное время найти на изучение, оно потом опытом и скоростью разработки отблагодарит  Цитата(JSman @  25.8.2006,  23:42 ) взять делфю, кинуть веб-браузер, разрешить привилегии,  контент должен иметь поменьше динамики, чтобы уменьшить утечку памяти HTA приложение это по сути документ, запускаеться виндовым стартером двумя кликами как обычная прога, писать свой "загрузчик/просмотрщик" не нужно. Утечки памяти только в IE и только при связи DOM нод с JS обьектами (например функциями). Обойти можно, но оно претит рассудку    НО! помимо IE есть ещё вполне здоровый XUL, глянь на http://http://xulplanet.com/, не всё задокументировано, но хватает что бы накидать окошки своего плагина. Не только плагин к браузеру, но и полноценное приложение можно написать, естественно от Gecko движка ты будешь зависеть. Цитата(JSman @  25.8.2006,  23:42 ) у меня было задание. Обычный документ/шкурка к инфо-системе. Генерим таблицу сразу на сервере, хотя можно загрузить аяксом (не люблю первую пустую страничку...). На редактируемых ячейках ловим клик мыши, для любителей клавы можем обернуть ячейку в ссылку, будет доступна по tab'у. По клику сменяем содержимое ячейки на input:text или какой собственный редактор. В момент редактирования посылаем запросы аяксом для подсказок и вариантов. Как закончили, аяксом отсылаем изменения в ячейке, редактор замещаем полученным вводом/текстом. Потребуеться: знание DOM знание XmlHttpRequest или обёрток знание XPath если ответы в XML и не хочеться работать с DOM напрямую Естественно JS и верстать со стилями ты должен уметь. Работа примерно на неделю с нуля. Примеры с клик->замена ячейки на input:text и отправка изменений (правда в форме, не аяксом) был0 на форуме где то пол года назад.

Автор: JSman 26.8.2006, 23:31

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

Автор: bems 1.1.2007, 07:28

Пока весь топик не читал, сори... Есть необходимость разобрать некоторые из методов, которые использует Осел в своих внутренних страницах (протокол res://). Где почитать на тему  Цитата(Sardar @  25.8.2006,  01:09 ) new ActiveXObject, Dictionary и API поддерживаемое IE ? (Применение ограничено только Ослом)

Автор: AKS 1.1.2007, 13:23

bems Цитата Где почитать на тему... Боже мой, ну конечно же в http://msdn.microsoft.com/library/default.asp!

Автор: JSman 4.1.2007, 03:28

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

Автор: JSman 5.1.2007, 12:07

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

Автор: bems 5.1.2007, 17:23

Цитата(JSman @  5.1.2007,  12:07 ) протокол res еще не разработан до конца. существует большое количество багов, особенно при наличии ресурсов, используемых ActiveX объектами, например Adobe Flash.. в Висте многие ошибки исправили, но несовместимость осталась..  Цитата(JSman @  5.1.2007,  12:07 )  уж слишком он глюченный Какие например баги? По мне, все работает хорошо. И с ActiveX что не так? Цитата(JSman @  5.1.2007,  12:07 ) в этом как раз еще одно ограничение использования JScript.. На эту тему поподробнее, если можно... И вообще какие отличия в поведении от версии к версии?

Автор: JSman 5.1.2007, 22:19

например в dll flash засунуть. у меня XP SP2 и в html ничего не отображается.  такие же проблемы с использованием объекта treeview.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)