Des idées sur la structure VBS pour permettre un code commun

Question

Pour tous les VBS Gurus là-bas ...

J'ai écrit une suite de scripts VB (pour automatiser des installations, si vous devez savoir) qui utilisent un ensemble de fonctions communes pour quelque chose comme la journalisation, le démarrage/l'arrêt des services, etc.

J'ai créé un design qui utilise un script qui contient les fonctions communes dans une classe. Il déclare et instancie également une variable du type de classe.
J'ai aussi un script 'loader' qui vérifie si l'objet de classe existe et si ce n'est pas le cas, exécute le script de classe.

Chaque script que j'écris inclut un appel au chargeur, puis je peux appeler des méthodes de la classe instanciée.

C'est une solution assez sympa (à mon humble avis) mais je me demandais si quelqu'un avait d'autres/meilleurs moyens d'atteindre la même chose?

- Pete

Note: Ceci ne concerne que les scripts VB dans les fichiers .vbs

Answer 1

Nous avons obtenu la même chose dans VB5. Dans notre application, les scripts VB ont été utilisés pour personnaliser les règles métier et même l'interface utilisateur. Il y avait une structure de fichier appropriée, par exemple les classes de base étaient dans base \ folder. Lorsque l'application VB était en cours d'exécution, nous utilisions le contrôle MSScript pour exécuter des scripts. L'étape d'initialisation consistait à charger les noms des fichiers VBS et à créer en mémoire une arborescence d'association. Puis quand VB besoin d'appeler certains scripts, par exemple CreateNewCustomer(), un moteur a été informé qu'il devrait charger dans les fichiers MSScript 2: CreateNewCustomer.vbs et base \ CreateNewCustomer.vbs

Dans ce cas, nous avons mis en place quelque chose qui nous permet utiliser l'héritage dans VBScripts.

De plus, une référence à notre classe COM, VBScriptEngine, a également été transmise au contrôle MSScript. Ainsi, dans une VBScript nous avons pu appeler VBScriptEngine.ExecuteScript (« CreateNewCustomer », params) et il peut encore exécuter une autre VBScript

Quel était le défi dans cette tâche est que nous ne voulons pas créer et initialiser trop de cas du contrôle MSScript, mais le contrôle MSScript ne peut pas exécuter un autre script lorsque le script en cours n'est pas terminé. Donc, dans notre VBScriptEngine, nous avons une pile d'exécution de script. Si n'importe quel VBScript doit appeler un autre VBScript, nous devons créer un nouveau contrôle MSScript et le placer dans la pile. Parfois, nous avons des appels imbriqués qui nécessitent 3 contrôles MSScript ou plus simultanément

Oui, tout cela semble très étrange de nos jours quand des langages dynamiques ou des assemblages dynamiques dans .NET pourraient être utilisés pour obtenir de meilleurs résultats avec moins d'efforts.

Answer 2

En 2006, je suis venu avec la solution suivante en utilisant "Exécuter" et "OpenTextFile":

Execute library("lib-util-1.0.4.vbs") 

    '---BEGIN-------------------------------------- 
    logger left(getScriptName(),len(getScriptName())-4)&".log" : msgLog "" '-- blank line 
    msgLog "Running... ("&getScriptName()&")" 

    '<YOUR SCRIPT GOES HERE> 

    '-- fini 
    ExitProcess Null, 0 
    '---END---------------------------------------- 


    '-- Import library into memory (2006.07.21/1.0.0/RRR) 
    Function library(ByVal libname) 
     dim libf:set libf=CreateObject("Scripting.FileSystemObject"):if not libf.fileExists(libname) then wscript.stdOut.write " Error: Could not locate library: "&libname:WScript.Quit(1) 
     library=libf.OpenTextFile(libname,1).ReadAll() 
    End Function 

D'autres exemples sont situés ici: http://github.com/randollr/LVA