Je vais essayer de répondre à ma propre question en m'appuyant sur la documentation pertinente. 1 fourni par @user3439894 dans un commentaire sur ma question.
D'où le code AppleScript tire-t-il ces variables ?
input :
Le site input contient (dans la plupart des cas) la sortie de l'action précédente dans le flux de travail .
Le type de données de input es list .
Pour afficher le contenu de input dans la section correspondante d'Automator "Résultats" pour cette action spécifique, il suffit de l'utiliser :
return input
parameters :
Le site parameters contient le paramètre les réglages effectués dans l'interface utilisateur de l'action .
Le type de données de parameters es reco (c'est-à-dire un record objet).
Voici un aperçu de la reco type 2 :
Ce type est utilisé comme type de l'élément properties pour la propriété item et le type de la classe with properties paramètres de la duplicate et make des commandes.
Pour afficher le contenu de parameters dans la section correspondante d'Automator "Résultats" pour cette action spécifique, il suffit de l'utiliser :
return parameters
Qu'est-ce que, spécifiquement, fait parameters contiennent ?
J'étais curieux de savoir ce que l'on entendait exactement par, "les réglages effectués dans l'interface utilisateur de l'action," alors j'ai jeté un coup d'oeil au contenu de parameters . J'ai appris que, contrairement input , parameters ne contient que des informations sur cette action spécifique, et aucune information sur l'action précédente.
En utilisant la ligne de code suivante,
display dialog length of parameters
J'ai également découvert que le nombre de propriétés dans parameters pour un "Exécuter AppleScript" dans Automator est de trois.
Ils le sont :
|temporary items path|:
donde |temporary items path| est suivi du chemin d'accès au dossier temporaire créé pour stocker les données temporaires qui peuvent être créées par le programme en cours d'exécution. "Exécuter AppleScript" action. Ce dossier est nécessairement créé à l'exécution, même si le code ne crée pas de données temporaires. Après l'exécution de l "Exécuter AppleScript" est terminée, ce dossier et son dossier parent sont immédiatement supprimés.
donde ignoresInput est soit vrai o faux selon que le "Ignorer l'entrée de cette action" qui se trouve dans le Options sous cette action dans Automator est cochée ou décochée.
source:
donde source contient le code AppleScript non abrégé de ce "Exécuter AppleScript" action.
Comment peut-on lire le contenu de parameters dans un AppleScript ?
Puisque le type de parameters n'est pas list on ne peut pas simplement :
set firstParameter to item 1 of parameters
car cela produira une erreur. Mais vous pouvez convertir parameters à un list objet :
set parametersInListFormat to (parameters as list)
Ensuite, vous serez en mesure d'exécuter quelque chose comme ça :
set individualItemFrom_parametersInListFormat to ""
repeat with individualItemFrom_parametersInListFormat in parametersInListFormat
display dialog individualItemFrom_parametersInListFormat
end repeat
Alternativement, vous pouvez sauter la conversion en un fichier de type list et lire le contenu de parameters simplement comme ça 1 :
set item1 to |temporary items path| of parameters
set item2 to |ignoresInput| of parameters
set item3 to source of parameters
Où exactement l'AppleScript return le site input à ?
Le site input de l'action en cours est envoyée à l'action suivante en tant qu'action input .
Plus d'informations sur le return déclaration 3 :
A return quitte un gestionnaire et renvoie éventuellement une valeur spécifiée. L'exécution continue à l'endroit du script où le gestionnaire a été appelé.
Si un gestionnaire n'inclut pas un return AppleScript renvoie la valeur renvoyée par la dernière instruction. Si la dernière instruction ne renvoie pas de valeur, AppleScript ne renvoie rien.
Lorsqu'AppleScript a terminé l'exécution d'un gestionnaire (c'est-à-dire lorsqu'il exécute une commande return ou la dernière instruction du gestionnaire), il passe le contrôle à l'endroit du script situé immédiatement après l'endroit où le gestionnaire a été appelé. Si l'appel d'un gestionnaire fait partie d'une expression, AppleScript utilise la valeur renvoyée par le gestionnaire pour évaluer l'expression.
Comment ces variables pourraient-elles être idéalement utilisées dans une application/service AppleScript ?
Maintenant que je comprends mieux les paramètres de positionnement de input et parameters il m'est plus facile d'imaginer leur valeur pratique.
input :
La valeur de input est manifeste et les possibilités de mise en œuvre sont incommensurables.
Une application très basique serait de transmettre une chaîne de texte qu'un utilisateur saisit dans une boîte de dialogue via un fichier de type "Demandez un texte" à l'action suivante, une "Exécuter AppleScript" action qui écrit cette chaîne dans le fichier. Voici à quoi cela pourrait ressembler :
![Sample Automator Workflow]()
parameters :
Étant donné que parameters est limitée à cette action spécifique et ne contient aucune donnée provenant d'actions précédentes, et les données qu'elle contient ne sont pas nécessairement pertinentes, elle est beaucoup moins utile et flexible que input . Je peux visualiser le besoin de |temporary items path| mais je n'y parviens pas pour les deux autres propriétés.
Voici un exemple de la manière dont on pourrait avoir besoin de se référer |temporary items path| dans leur AppleScript :
-
Supposons que l'on souhaite qu'une application Automator affiche à l'utilisateur les dimensions d'une image Web.
-
L'utilisateur pourrait utiliser |temporary items path| comme emplacement pour stocker cette image, afin que le code puisse opérer sur elle. Puis, une fois l'opération terminée, puisque l'utilisateur n'a pas besoin ou ne veut pas que l'image soit sauvegardée sur le disque, l'AppleScript supprimerait automatiquement cette image (ou, plus précisément, l'AppleScript supprimerait automatiquement le dossier qui contient le dossier contenant cette image).
-
Voici comment cela pourrait être mis en œuvre :
on run {input, parameters}
set theURLofImage to "https://cdn.sstatic.net/Sites/stackoverflow/company/img/logos/se/se-logo.png"
set tempFolderThatIsAutomaticallyDeletedAfterRun to |temporary items path| of parameters
set filename to "StackExchangeLogo.png"
set fullFilepath to tempFolderThatIsAutomaticallyDeletedAfterRun & "/" & filename
-- Saving image from internet to disk.
-- From: http://stackoverflow.com/a/21491446/7138483
do shell script "curl -f " & theURLofImage & " -o " & fullFilepath
-- Figuring out the dimensions of the saved image.
-- From: https://www.macosxautomation.com/applescript/imageevents/01.html
try
tell application "Image Events"
launch
set this_image to open fullFilepath
-- Extract the properties record.
set the props_rec to the properties of this_image
-- Purge the open image data.
close this_image
-- Extract the property value from the record.
copy (dimensions of props_rec) to {x, y}
set the image_info to "Dimensions of " & filename & ": " & "" & x & " x " & y
end tell
display dialog image_info
on error error_message
display dialog error_message
end try
return input
end run
-
De plus, on pourrait vouloir surveiller la taille de la |temporary items path| pour imposer une limitation, de sorte que si sa taille dépasse une certaine valeur, une erreur est présentée à l'utilisateur.
En ce qui concerne la façon dont |ignoresInput| pourrait être utilisé, on pourrait modifier le |ignoresInput| au milieu du code, avec la ligne suivante :
set |ignoresInput| of parameters to true
On peut vouloir arranger son code de telle sorte que si la fonction input remplit ou ne remplit pas une certaine condition, alors la input doivent être ignorés. Par exemple :
if item 1 of input > 10 then
set |ignoresInput| of parameters to true
end if
Mais, même si l'on voulait s'assurer que les input n'était utilisé que si son contenu remplissait une certaine condition, on pouvait obtenir le même effet sans avoir à lire ou à modifier le fichier |ignoresInput| Au lieu de cela, on pourrait simplement déclarer sa propre valeur booléenne à cette fin. Ainsi, je continue de penser que l'applicabilité de l'approche |ignoresInput| parameter est discutable.
De même, je ne vois pas de raisons particulièrement convaincantes pour lesquelles il serait nécessaire de lire ou de modifier l'avis de la Commission européenne. source parameter de leur AppleScript pendant son exécution.
Quoi d'autre ?
Une zone de confusion pour moi existe toujours.
Je ne comprends toujours pas pourquoi Apple, dans sa documentation, conseille de ne rien retourner dans un AppleScript 1 :
Le code du modèle renvoie finalement input en tant que résultat ; votre action doit toujours retourner quelque chose en tant que résultat, même si ce qui lui est donné en entrée.
Quel est l'intérêt d'enlever le return de l'AppleScript, si l'on n'en a pas besoin ?
Si quelqu'un qui connaît la méthodologie AppleScript peut résoudre ce problème pour moi, merci de laisser un commentaire.
Il est possible que j'interprète mal la phrase.
J'interprète cette phrase comme signifiant :
"Lorsque vous écrivez votre code, vous devriez toujours vous assurer d'inclure un return quelque part dans votre code."
Mais, la phrase pourrait potentiellement signifier à la place :
"Si vous mettez un return dans votre code, que return est conçue pour toujours retourner quelque chose. Si vous n'assignez rien à input alors le code renverra simplement la même entrée qu'il a reçue."
L'ambiguïté tourne autour de l'intention originale du mot, devrait et si le devrait est censé agir comme une recommandation pour l'utilisateur qui écrit un AppleScript, ou si, en devrait ils voulaient dire sera .
Sources des passages inclus dans cette réponse :
1. <a href="https://developer.apple.com/library/content/documentation/AppleApplications/Conceptual/AutomatorConcepts/Articles/ImplementScriptAction.html#//apple_ref/doc/uid/TP40001512-97148-CJBIADBH" rel="noreferrer">Guide de programmation Automator - <em>La structure du gestionnaire de commandes en cours d'exécution</em></a>
2. <a href="https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/ScriptableCocoaApplications/SApps_about_apps/SAppsAboutApps.html" rel="noreferrer">Cocoa Scripting Guide - <em>Prise en charge intégrée des types AppleScript de base</em></a>
3. <a href="https://developer.apple.com/library/content/documentation/AppleScript/Conceptual/AppleScriptLangGuide/reference/ASLR_handlers.html" rel="noreferrer">Guide du langage AppleScript - <em>Référence du gestionnaire</em></a>
