4 votos

¿Cuáles son las ventajas o desventajas de llamar a los Handlers desde una Biblioteca script con "use Statements" frente al comando "Load script"?

En el primer escenario, tengo un script que contiene todos mis manejadores y fragmentos. El nombre de este script es "Jimz_Handlerz.scpt" y se encuentra aquí /Users/Smokestack/Library/script Librerías.

Llamar al manejador desde un nuevo archivo AppleScript requiere que declare mi biblioteca script (línea 1) y luego puedo llamar al manejador en cualquier momento que quiera con la segunda línea. Así:

use myHandlerz : script "Jimz_Handlerz.scpt"

myHandlerz's get_fileExtensions()

En el siguiente escenario, estoy utilizando el comando "load script" para cargar exactamente el mismo archivo que el primer ejemplo, pero este archivo se encuentra en el escritorio

property jimzHandlerz : load script ¬
    (alias "Macintosh HD:Users:Smokestack:Desktop:Jimz_Handlerz.scpt")

jimzHandlerz's get_fileExtensions()

Este es el manejador real que contiene el comando que estoy llamando desde ambos escenarios diferentes..

on get_fileExtensions()
    tell application "Finder"
        set theDownloadsfolder to (path to downloads folder)
        set theFiles to the name extension of every file of theDownloadsfolder
    end tell
    AST copy list theFiles without keeping duplicates -- Needs AppleScript Toolbox 2_0_8.osax Scripting Addition in /Users/"Name"/Library/ScriptingAdditions
end get_fileExtensions

Así que supongo que mi pregunta es, ¿hay situaciones en las que preferiría utilizar el escenario uno y otras en las que el escenario dos sería mejor?

Actualización:

Aquí hay una pequeña información interesante: Usando el escenario de llamar a los manejadores de una biblioteca script script o archivo de paquete script como en el primer ejemplo de mi pregunta original.. Si el script actual, que estamos llamando a un script externo desde una librería, es un bundle script e incluimos una carpeta dentro de la carpeta "Resources" llamada "script Libraries" que contiene el bundle script o script desde el que estamos llamando a nuestros manejadores externos, si el archivo en la carpeta del sistema "script Librerías" no puede ser encontrado, entonces este script no arrojará un error porque busca en la carpeta de recursos también las bibliotecas script.

enter image description here

1 votos

Voy a +1 sólo porque una respuesta autorizada estaría bien.

2 votos

Personalmente, guardo un par de archivos con mucho código que reutilizo, vía copiar y pegar, sin embargo, cada script/app que escribo prefiero que sea lo más autocontenido posible. En mi opinión, es mucho más fácil de mantener cuando está autocontenido y no necesito añadir código adicional para asegurarme de que las fuentes externas están disponibles, etc. Tampoco estoy escribiendo nada de tamaño donde veré un beneficio para que sea un escenario de varios archivos más allá de los archivos por defecto creados y un archivo .icns personalizado. Si escribo algo que dependa de un ejecutable de terceros, por ejemplo clic-clic, una copia del mismo va a la carpeta Resources.

0 votos

Creo que estoy de acuerdo con lo de copiar y pegar. Me estoy dando cuenta de que si ha pasado un tiempo desde que he mirado el script y llama a los manejadores de otro archivo, no tengo ni idea de cuáles son los comandos a menos que abra el segundo script para ver qué comando estoy llamando.

1voto

wch1zpink Puntos 11

He añadido un "script logger" al principio de cada uno de mis script, que básicamente escribe en el archivo . El nombre del script y la hora y fecha en que se ejecutó por última vez.

Todos los comandos para el registro, residen en un objeto script ubicado en un archivo separado "Jimz_Handlerz.scptd" utilizado como una biblioteca script que se encuentra en mi carpeta de bibliotecas script.


El siguiente código, que se encuentra en el archivo "Jimz_Handlerz.scptd", es el objeto script que gestiona el registro

script scriptRunLog2
    try
        writeToFile()
    end try

    on writeToFile()
        set currentDate to (current date) as string
        -- The "." At The Beginning Of The Filename In The Next Line
        -- Makes That File A "Hidden" File
        set theFile to (path to desktop as text) & ".script_run_log.txt" 
        set theFile to POSIX path of theFile
        set myName to name of (info for (path to me))
        set theText to myName & " was last run on " & currentDate
        try
            set writeToFile to open for access theFile with write permission
            write theText & linefeed to writeToFile as text starting at eof
            close access theFile
        on error errMsg number errNum
            close access theFile
            set writeToFile to open for access theFile with write permission
            write theText & linefeed to writeToFile starting at eof
            close access theFile
        end try
    end writeToFile
end script

Hay dos formas de ejecutar los comandos dentro de ese objeto script, desde cualquier otro archivo script.

OPCIÓN 1 Utilizando la opción "load script" insertada al principio de cualquier otro archivo script

property theLibrary : (path to home folder as text) & "Library:Script Libraries:Jimz_Handlerz.scptd"
property jimzHandlerz : load script alias theLibrary
run jimzHandlerz's scriptRunLog2

OPCIÓN 2 Usando la opción "use" insertada en la parte superior de cualquier otro archivo script. Como "Jimz_Handlerz.scptd" se encuentra en mi carpeta de bibliotecas script, no necesito definir su ubicación

use jimzHandlerz : script "Jimz_Handlerz.scptd"
run jimzHandlerz's scriptRunLog2

En cuanto a la pregunta de mi post original

si uso la opción 1, el logger script registrará qué script he ejecutado junto con la hora y la fecha.

Sin embargo, si uso la opción 2, el logger script registrará "Jimz_Handlerz.scptd" como el script que ejecuta el código.

En resumen, en este escenario, sería mejor utilizar la opción 1

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X