Los handler son subrutinas "auxiliares", que realizan operaciones "básicas" y devuelven un resultado (si así lo determinamos). Esta es la teoría, aunque en la práctica uno utiliza los handler para lo que le venga en gana. (revisado el 21/03/2003))
Los handler son guay, porque admiten parámetros y porque devuelven resultados.
Veamos unos ejemplos.
display dialog “Hola, cara de bola”
end Saludar
on Saludar_Al(pibe)
display dialog “Hola, ” & pibe
end Saludar_A
on Sumar_Cifras(cifra1, cifra2)
set la_suma to cifra1 + cifra
end Sumar_Cifras
on Comparar_Cifras(cifra1, cifra2)
if cifra1 > cifra2 then
return “La cifra ” & cifra1 & ” es mayor que ” & cifra2
else if cifra1 < cifra2 then
return “La cifra ” & cifra1 & ” es menor que ” & cifra2
else
return “La cifra ” & cifra1 & ” es igual que ” & cifra2
end if
end Comparar_Cifras
Para utilizar un handler, sólo hay que rellenar los huequecitos. En el primer ejemplo, no hay nada que rellenar, así que simplemente invocaremos al handler por su nombre:
En el segundo ejemplo, tenemos que rellenar el parámetro "pibe":
En el tercero, lo mismo, pero pasando números:
display dialog la_suma
Aquí tendremos nuestro primer handler devolviendo un resultado útil. Por defecto, un handler devuelve siempre un resultado, que es el de la última operación realizada. En el caso de los dos primeros ejemplos, nos devuelve el resultado del diálogo (que, en principio, a mí no me es útil, porque sólo quería
saludar).
En este tercer ejemplo, nos devolverá el resultado de la operación. O sea:
Por último, como podemos ver en el último ejemplo, podemos "romper" el handler cuando nos venga en gana con el statement return. Cuando se le invoque, el handler parará y devolverá lo que indique el "return". Por ejemplo, si añadimos estas líneas al handler del tercer ejemplo:
— no devuelve nada
return la_suma
— devuelve el valor de sumar cifra1 y cifra2
En este caso, "return la_suma" no conduce a ninguna parte, ya que "la_suma" es la última operación
del handler y, por tanto, el resultado que devuelve.
Por supuesto, podemos enviar como parámetros lo que nos dé la gana. Variables (que ya tengan un valor definido), texto, números, listas, records… Y para que funcione bien, deben corresponderse los parámetros que envío con los que acepta el handler. Veamos, por último, este ejemplo autoexplicativo:
set parametro_2 to “El Rey Arturo”
set parametro_3 to “la Corona sueca”
set x to my Calcular_Deuda(parametro_1, parametro_2, parametro_3)
display dialog x
on Calcular_Deuda(factura, moroso, acreedor)
set total to 0
repeat with x from 1 to count items of factura
set total to total + (factura’s item x)
end repeat
return moroso & ” adeuda ” & total & ” escudos de oro a ” & acreedor
end Calcular_Deuda
— esto devolverá “El Rey Arturo adeuda 1262 escudos de oro a la Corona sueca”
Así visto parece una tontería, pero imaginemos que somos la Corona sueca y que tenemos 500 morosos. Este mismo handler “Calcular_Deuda” nos sirve para todos. Tan sólo tenemos que cambiar el nombre del acreedor y la pasta que nos debe.
Así pues, la mayor utilidad que se le atribuye a los handler es la de ser “subrutinas”. O sea, pequeñas (o grandes) operaciones que vamos a necesitar muchas veces a lo largo de nuestro script, o que nos viene bien poner por separado para organizarnos mejor.
Lo que hemos visto es la manera habitual de construir un handler, aunque soporta más variaciones, como:
…
— a este handler habría que invocarle igual que él es:
Calcular_Deuda given parametros:{parametro1, parametro2, parametro3}
También se pueden utilizar construcciones con la preposición with para valores tipo "boolean" (verdadero o falso), into, from, etc.
Además, se puede utilizar to, en vez de on, para comenzar la construcción del handler, se pueden concatenar diversas preposiciones, y hacer cabriolas sobre las olas, aunque creo que se trata más bien de utilidades innecesarias (o al menos así lo considero). A esto lo llaman "parámetros etiquetados", pero yo no veo que se utilicen demasiado por ahí. Por ejemplo:
set lo_de_ayer to “Cerveza”
set x to 1.5
Quien_me_debe_pasta of lista_de_amigos by lo_de_ayer given me_faltan_pelas:x
to Quien_me_debe_pasta of lista_de_amigos by lo_de_ayer given me_faltan_pelas:x
set los_productos to {“Cerveza”, “Café”, “cocacola”}
set los_valores to {1.5, 1.12, 1.8}
repeat with z from 1 to 3
if lo_de_ayer is in contents of (los_productos’s item z) then
set el_valor to los_valores’s item z
set el_capullo to lista_de_amigos’s item z
exit repeat
end if
end repeat
if x > el_valor then
set el_comentario to “Creo que me han robado, porque sólo me faltan ” & x & ” euros.”
else
set el_comentario to “Creo que le voy a matar.”
end if
display dialog “El capullo de ” & el_capullo & ” me debe ” & el_valor & ” euros porque se ha tomado una ” & lo_de_ayer & “.” & return & return & el_comentario with icon 1
end Quien_me_debe_pasta
Los handler son verdaderos comandos que nosotros construimos, y que utiliza nuestra aplicación (nuestro script). Por eso, si estamos trabajando dentro de un tell block (o sea, que estamos mandando comandos a una aplicación), debemos invocar al handler con las palabras my o of me, para que AppleScript nos mande el comando a nosotros (al script), y no a la presente aplicación. Por ejemplo:
set lista_de_deudas to item 1 of the selection
my Procesar_Lista(lista_de_deudas)
— o si no, “Procesar_Lista(lista_de_deudas) of me”
end tell
on Procesar_Lista(lista_de_deudas)
…
Si no, el Finder se sentiría terriblemente confuso al tener que responder a un comando para el que no está preparado: “Procesar_Lista”.
Muchas veces, por comodidad, funcionalidad o necesidad, deberemos hacer scripts que se compongan únicamente de handlers, a los cuales invocaremos desde otros scripts. Es lo que popularmente llamamos “bibliotecas”, y lo veremos en otro capítulo.
Los restantes artículos sobe AppleScript se pueden encontrar en la categoría de Tutorial
