Re: Script Debugger

"Benoît L." <benoit@leraillez.com.invalid> wrote:

Puisque je vise le développement d'une appli*, ne serait-il pas
intéressant, à terme, de faire un script par routine ?
 
Je pose la question parce que dans ce cas on a un script principal
« léger » facile à lire et pas des « tonnes » de lignes au milieu
desquelles on se promène à la recherche de l'erreur.

L'idée que tu émets de structurer une "appli" en différents scripts qui
seront appelés en cas de besoin par le handler principal s'applique déjà
et en premier au handler maître.

Quand tu as une succession de lignes de commandes, effectuant une action
ou retournant une valeur, susceptible de constituer une routine à part
entière, crée-la en lui donnant un nom et des paramètres, ce qui permet
ensuite de l'appeler depuis n'importe où, et autant de fois que
nécessaire, depuis le handler maître.
D'ailleurs, de la même manière cette routine pourra appeler une ou
plusieurs sous-routines construites sur le même principe. (toutefois,
attention de ne pas trop saucissonner les routines, pour ne pas les
rendre incompréhensibles à leur tour).

En quelque sorte le script contient le handler maître ET sa propre
bibliothèque de routines et sous-routines au même niveau, ce qui les
rend très facilement accessibles (à déboguer) et allègera la lisibilité
du handler maître, qui apparaîtra en quelque sorte l'architecte de
l'application au lieu de le noyer dans l'exécution de tâches
"subalternes".

Au niveau de la modestie (sans offense de ma part) en terme de volume de
lignes de code du projet auquel tu t'attaques, nul besoin d'enregistrer
une sous-routine dans un script indépendant qu'il faudra aller
positionner dans un dossier "Libraries" du dossier "Resources" de
l'application.*

Par commodité de lecture, en général on sépare le handler maître des
sous-routines positionnées en dessous par une barre de commentaire.
Mais c'est purement conventionnel et selon l'idée que l'on se fait du
pratique de la chose.

Le recours à des "script-objects" (dans le jargon) mis à disposition
dans le /Libraries des /Resources du bundle ne se justifie que s'ils
sont eux-mêmes de très grosses entités et définitivement stabilisés.
L'exemple en est justement les Dialog Tool kit Plus, si tu vas regarder
comment cette application (ou scptd, je ne me rappelle plus) est
organisé.


*Néanmoins, si tu y tiens essentiellement, une explication de la méthode
ici.
<https://developer.apple.com/library/archive/documentation/LanguagesUtilities/Conceptual/MacAutomationScriptingGuide/UseScriptLibraries.html>

ou cette série d'articles, qui bien qu'à but de vulgarisation, me paraît
plus "confusionnante"
<https://macosxautomation.com/mavericks/libraries/index.html>
et une mise en exemple
<https://macosxautomation.com/mavericks/libraries/simple.html>

--
J. B.