Pull to refresh

Comments 9

Может я чего не понимаю, но почему вместо
jsIncludeGear = new ActiveXObject("JScriptIncludeGear"); 	
eval(jsIncludeGear.getSourceCode());

не сделать
var jsImport = new ActiveXObject("JScriptIncludeGear");

Есть какие то причины делать eval именно в пользовательском скрипте?
Да причины есть, основная из которых выражена в весьма ограниченном функционале Windows Script Components по выворачиванию наружу методов и свойств. А также в разделении [scope] вызывающего скрипта и экземпляра компоненты. Например, чтобы заставить в компоненте wsc работать глобальный WScript надо подпирать это уверенными костылями передавая его в публичное свойство из вызывающего скрипта, вобщем как ни крути одной строкой кода не отмажешься, было решено, что проще сделать один eval
Потому что иногда пишут скрипты администрирования винды именно на JS.
Честно говоря, я просто не понял из поста изначальную цель написания вашего решения.
Надеюсь Вы не против — я объясню:
Перед Вами «внезапно» встала задача, администрирования, а именно автоматизации этого самого администрирования, конечно каждая платформа предлагает Вам свои собственные решения, они как правило обособлены, нигде более не применимы, при этом требуют все же изучения. В случае с Windows вам на выбор предлагается:
1) Изучить технологию пакетных файлов BAT/CMD весьма специфический и не очевидный синтаксис, со своими граблями и ограниченными возможностями
2) PowerShell — и опять же это свой синтаксис, ну и так сказать это не решение «из коробки»
3) AutoIt — стороне решение, весьма мощное и удобное, но опять же это самобытный BASIC-подобный процедурный язык программирования, и еще парочка сопутствующих технологий. (хотя он безусловно крут, в отношении автоматизации в Windows, неоспоримый плюс возможность прикручивания простого но полнофункционального GUI)
4) И как-то в тени вышесказанного, особнячком, тусуется такое решение как WSH — это скрипты автоматизации которые можно писать на двух языках это, боже упаси VBscript, и слава тебе Господи JScript (который JavaScript по сути, т.е. реализация ECMA 262), причем для них в системе предусмотрена «изкоробочная инфраструктура» — ActiveX/COM/OLE интерфейсы на все случаи жизни: работа с ФС, сетью, FTP, почта и т.д.
А самое главное, если вы ранее работали с JavaScript (ну за кем сейчас нет греха-то а? :))
то Вам не надо изучать какой-то новый синтаксис, или еще что-то… А если Вам необходимо GUI — то пожалуйста к Вашим услугам HTM аппы, а это фактически HTML.
И все так заманчиво, но вот лично меня постигло одно НО… решение к которому я и разработал :)
Ваше решение довольно интересное — нативные средства это хорошо, но честно говоря, если бы передо мной встала задача автоматизации, я бы выбрал какое-то решение, наиболее абстрагировано работающее с администрируемым сервером. Через RPC как-то, наверное.
Если присмотреться, то Windows нашпигован возможностями по использования таких скриптов, есть средства вызывающие скрипты на исполнение удаленно, Group Policy и Group Policy Preferences позволяют вешать выполнение скриптов на множество событий и условий, они могут быть исполнены через назначенные задания, да и вообще через любой шел. Так что если не основной инструмент, то как хорошее подспорье сгодится :)
А самое главное простота разработки, и ее скорость…
Знание JavaScript и в бой, приблизительное понимание принципов ActiveX/OLE/COM, дока по Системным ActiveX/OLE/COM объектам/интерфейсам.

Плюс опять же есть альтернативные способы автоматизации, но из них кроме как AutoIt модульную систему не позволяет сделать ни одно. Я изначально возжелал не переделывать проделанную работу, по ходу работы дописывай себе модули, старайся делать их как можно универсальнее, завязвай их друг на друга как хочешь, распостраняй, и вот оно счастье :)
Sign up to leave a comment.

Articles