Ante todo, buenos días. Ahora mismo estamos a punto de entrar en el terreno de lo surrealista así que, si cree vd. que no está preparado, vaya a esparragar a otra sección distinta. Empezamos. Un script object es una cosa muy extraña que podríamos definir como «el terreno por donde se desenvuelve nuestro código».
AppleScript en sí mismo es el script object número 1. Por ejemplo, yo puedo compilar las siguientes expresiones:
count x
Estoy utilizando «comandos» de AppleScript, y puedo hacerlo desde cualquier sitio. El valor de la variable «x» es una «string», y puedo establecerla y contarla (en este caso, me contará el número de caracteres: 7).
Por tanto, y nos metemos ya en el asunto del parent, creo que, sin yo saberlo, el «parent» de cualquier script (a no ser que se establezca algo distinto), es AppleScript, dado que yo siempre puedo utilizar comandos y «classes» pertenecientes a AppleScript.
Ahora viene lo que comúnmente llamamos script object (dado que, por defecto, el » script objet» es AppleScript). A saber, cuando, con o sin ayuda de AppleScript, establecemos un contexto especial válido para todo el área de influencia de este «script object». Un ejemplillo:
script Script_Object
property x : «Coña»
end script
x
x of Script_Object
Pues bien. Si vemos el resultado de este script en un editor, queda claro que cuando decimos «x», nos estamos refiriendo a la «property x» del nivel más alto (que hemos dicho que, por defecto, es el propio nivel de AppleScript) y, por tanto, devuelve «Cáspita».
Sin embargo, la línea «x of Script_Object» se está refiriendo a una propiedad de un script objet distinto del primero. Se está refiriendo al script objet que hemos llamado «Script_Object», y devuelve, por consiguiente, «Coña».
Con la propiedad «x» hemos definido una propiedad aplicable al contexto «AppleScript» y, por tanto, puedo acceder a ella desde otro sitio distinto. Vamos a ver un ejemplo con las mismas características:
script Script_Object
property parent : AppleScript
property x : «Coña»
end script
x –> «Cáspita»
x of Script_Object –> «Coña»
x of (parent of Script_Object) –> «Cáspita»
Las líneas «x» y «x of Script_Object» devuelven el mismo resultado que anteriormente devolvían. Ahora bien, la línea «x of (parent of Script_Object)», que hace referencia al «parent» de «Script Object» (o sea, el mismo AppleScript), devuelve una referencia a «Cáspita», que viene a ser una propiedad que habíamos «incorporado» temporalmente a AppleScript.
Podríamos traducir parent como «padre». Y, por tanto, basándonos en el ejemplo anterior, podríamos decir que el script objet llamado «Script_Object» es un child del «parent» (un hijo) y que adquiere las propiedades del padre. Vamos a verlo con otro ejemplo:
property y : «Capullo»
end script
script Hijo
property parent : Padre
on parent_y()
return my y
end parent_y
end script
Aquí vemos cómo el script objet «Hijo» ha heredado la propiedad «y» del «Padre». Notemos que para devolver esta propiedad hemos utilizado la palabra my, que lo que hace es llamar al parent. Si utilizásemos simplemente «return y» nos daría error, ya que el script «Hijo», por sí mismo, no posee la propiedad «y».
Con esta palabreja, my, que podría traducirse como «mi», logramos que el script «Hijo» busque dentro de sí mismo la propiedad «y». Si no la encuentra, le trasladará la responsabilidad a su parent, siempre que éste exista. Siguiendo el mismo ejemplo:
property y : «Capullo»
end script
script Hijo
property parent : Padre
property y : «Pellejo»
on parent_y()
return my y
end parent_y
end script
parent_y() of Hijo
Aquí obtenemos un resultado distinto. Dado que sí existe la propiedad «y» dentro del «Hijo», nos la devuelve.
Esto devuelve el mismo resultado, como es lógico. De manera expresa, estamos pidiendo la propiedad «y» del «Hijo».
Y esta sería la manera de acceder a la propiedad «y» del parent del script «Hijo».
Y así hasta el infinito.
property y : «Abuelo»
end script
script Padre
property parent : Abuelo
property y : «Padre»
end script
script Hijo
property parent : Padre
property y : «Hijo»
end script
y of Hijo
y of parent of Hijo
y of parent of parent of Hijo
Aquí hemos accedido a las propiedades «y» de los scripts «Abuelo», «Padre» e «Hijo». Al final, todo queda en familia.
Vaya, pues al final no era tan surrealista. Es bien fácil. La regla fundamental para acceder de unos sitios a otros es tener en cuenta los «nombres» de las propiedades. Suponiendo que mi script tenga una propiedad de nombre «x», entonces puedo invocarla tanto con «x» como con «my x» (o «x of me»). Si quisiera acceder a una propiedad del mismo nombre del padre de mi script, entonces tendría que decirlo expresamente: «x of parent of me» (o «x of my parent»).
En resumen, es conveniente utilizar la palabra «my …», lo que provoca que el script busque desesperadamente el objeto en cuestión. Si no existe dentro del mismo nivel, lo buscará en su parent (siempre y cuando esté definido).
Uso extendido del «parent»
Hemos dicho que el parent es el padre de un script objet y que, por sí mismo, contiene un contexto propio. Si es un script objet basado en AppleScript, puede contener propiedades, handlers, etc.
Pero también podemos definir como parent otros contextos distintos, como los propios de las aplicaciones. Un ejemplo muy sencillito:
count items
Acabamos de heredar los objetos pertenecientes a la aplicación «Finder». Es por eso que al «comandar» la expresión «count items» obtenemos el número de ítems que se encuentran en el Escritorio. Si el «Finder» no fuese el parent de nuestro script, entonces el resultado del comando «count» no tendría nada que ver con el Finder. El script trataría de contar «cada ítem del script», lo cual no tiene ningún sentido y acabaría en un error.
Una de las utilidades que emana de la utilización del parent cuando éste es una aplicación, es que no tenemos ninguna necesidad de utilizar sus comandos dentro de un tell block. O sea, que no tenemos que invocar a la aplicación con un tell antes de utilizar sus comandos ya que, por defecto, estaríamos dentro de ella y, de una manera más o menos psíquica, seríamos ella misma, más nuestras propiedades.
Sin embargo, no podríamos utilizar sus comandos de manera normal, por su nombre («Finder, cariño, vacíame la basura»), sino que tendríamos que hacerlo mediante «raw code» (apple events en forma pura, a lo makarra).
Para ilustrar esta verborrea:
« event fndrempt»
Este apple-eventillo, «fndrempt», es el correspondiente a «empty» o «empty trash». Vemos la identidad de la Suite («fndr», de Finder) y la del comando («empt», de empty).
Codificar asín es un poco incómodo. Así que, algunos señores han inventado una técnica auxiliar, gracias a la cual podemos utilizar los comandos en su manera original (sólo para codificar, cuando habramos de nuevo el script, veremos los comandos en su forma makarra). Script Debugger utiliza el «default target application» (bajo el menú «Script > Options» y Smile el «tell…» (menú «Script»). Estas aplicaciones nos harán de puente o traductor, y podremos utilizar los comandos con sus nombres normales, y ellas harán la traducción a la hora de guardar el script.
Muy majos Mark Alldritt y Emmanuel Levy, sí señor…
Hay otras maneras de hacerlo, pero teniendo estas dos magníficas aplicaciones, no veo por qué habría de explicarlas…
Los restantes artículos sobe AppleScript se pueden encontrar en la categoría de Tutorial
