JScriptInclude Gear v 0.1.0 — механизм каскадного импорта скриптов/библиотек. (Реванш)

[lahmatiy]

Может я чего не понимаю, но почему вместо

jsIncludeGear = new ActiveXObject("JScriptIncludeGear"); 	
eval(jsIncludeGear.getSourceCode());

не сделать

var jsImport = new ActiveXObject("JScriptIncludeGear");

Есть какие то причины делать eval именно в пользовательском скрипте?

[RUVATA]

Да причины есть, основная из которых выражена в весьма ограниченном функционале Windows Script Components по выворачиванию наружу методов и свойств. А также в разделении [scope] вызывающего скрипта и экземпляра компоненты. Например, чтобы заставить в компоненте wsc работать глобальный WScript надо подпирать это уверенными костылями передавая его в публичное свойство из вызывающего скрипта, вобщем как ни крути одной строкой кода не отмажешься, было решено, что проще сделать один eval

[leshaogonkov]

А почему именно через Windows Scripting? (интересно)

[k12th]

Потому что иногда пишут скрипты администрирования винды именно на JS.

[RUVATA]

Альтернативы?

[leshaogonkov]

Честно говоря, я просто не понял из поста изначальную цель написания вашего решения.

[RUVATA]

Надеюсь Вы не против — я объясню:
Перед Вами «внезапно» встала задача, администрирования, а именно автоматизации этого самого администрирования, конечно каждая платформа предлагает Вам свои собственные решения, они как правило обособлены, нигде более не применимы, при этом требуют все же изучения. В случае с 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.
И все так заманчиво, но вот лично меня постигло одно НО… решение к которому я и разработал :)

[leshaogonkov]

Ваше решение довольно интересное — нативные средства это хорошо, но честно говоря, если бы передо мной встала задача автоматизации, я бы выбрал какое-то решение, наиболее абстрагировано работающее с администрируемым сервером. Через RPC как-то, наверное.

[RUVATA]

Если присмотреться, то Windows нашпигован возможностями по использования таких скриптов, есть средства вызывающие скрипты на исполнение удаленно, Group Policy и Group Policy Preferences позволяют вешать выполнение скриптов на множество событий и условий, они могут быть исполнены через назначенные задания, да и вообще через любой шел. Так что если не основной инструмент, то как хорошее подспорье сгодится :)
А самое главное простота разработки, и ее скорость…
Знание JavaScript и в бой, приблизительное понимание принципов ActiveX/OLE/COM, дока по Системным ActiveX/OLE/COM объектам/интерфейсам.

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