Java FX Script, primeros pasos – Parte 4

Posted on Agosto 27th, 2008 by admin

Cuando Sun presentó JavaFX en JavaOne 2007, JFX Script era aún un lenguaje interpretado. Sin embargo, desde un primer momento se aclaró que esto era sólo temporal, mientras el lenguaje pasaba de ser el resultado de la investigación personal (F3, de Chris Oliver) a un producto a ser introducido en el mercado. Es así como, después de un lapso de tiempo, JFX Script pasó de ser un lenguaje interpretado, a un lenguaje compilado, principalmente porque uno de las características principales que Sun pretende para las aplicaciones escritas en este lenguaje es un nivel de performance mayor que aquellas escritas en Javascript o ActionScript (de hecho, en los benchmarks realizados por Chris Oliver, el rendimiento de JFX Script fue 12 veces mayor que el de ActionScript.

Al cambio de categoría del lenguaje se sumaron algunos cambios en la sintaxis, los cuales revisaremos hoy, siguiendo la guia de migración de Planet JFX (simplemente porque fue una de las más completas que conseguí), como para dar por terminada esta parte, y comenzar luego con ejemplos algo más complejos y aggiornados.

Operaciones

Antes: el lenguaje diferenciaba entre funciones y operaciones.

class Foo {
      function times2(x) { return x * 2; }
      operation print(s) { System.out.println(s); }
  }

Ahora: La sintaxis actual fusiona los dos conceptos en uno único: el de función, y utiliza la palabra reservada “function” para declararlas. Es decir,  el único cambio que debemos realizar es el de renombrar las operaciones a funciones.

 class Foo {
      function times2(x) { return x * 2; }
      function print(s)  { System.out.println(s); }
  }

Inicialización de atributos

Antes: los valores iniciales de los atributos debían declararse fuera del cuerpo de la clase.

class Foo {
      attribute bar: Boolean;
  }

  attribute Foo.bar = true;

Ahora: esto se hace igual que en Java, es decir, dentro de la clase.

 class Foo {
      attribute bar: Boolean = true;
  }

Triggers de reemplazo

Antes: los triggers de reemplazo se definían fuera de la clase, utilizando la sintaxis “trigger on atributo = valor”

Sin inicialización:

class Foo {
      attribute bar: Boolean;
  }

  trigger on Foo.bar = value {
      if (bar == true) {
          beep();
      }
  }

Con inicialización:

class Foo {
      attribute bar: Boolean = true;
  }

  trigger on Foo.bar = value {
      if (bar == true) {
          beep();
      }
  }

Ahora: se definen dentro de la clase, como parte de la declaración del atributo, utilizando la sintaxis “on replace”

Sin inicialización:

class Foo {
      attribute bar: Boolean on replace {
          if (bar == true) {
              beep();
          }
      };
  }

Con inicialización:

 class Foo {
      attribute bar: Boolean = true on replace {
          if (bar == true) {
              beep();
          }
      };
  }

Cardinalidad

Antes: el operador de cardinalidad era el asterisco (‘*’).

class Foo {
  attribute names :String*;
}

attribute names = ["Monica", "Rachel", "Phoebe"];

Ahora: se utilizan en lugar del asterisco, los corchetes (“[]“).

class Foo {
  attribute names :String[] = ["Monica", "Rachel", "Phoebe"];
}

Literales objeto sin atributos

Antes: podíamos referirnos a literales objeto sin atributos utilizando solo el nombre de su clase.

Frame {
  title: "Show MenuSeparator"
  height: 180
  width: 320
  menubar: MenuBar {
    menus: Menu {
      text: "File"
      items: [MenuItem {
        text: "New"
      }, MenuItem {
        text: "Open"
      }, MenuItem {
        text: "Save"
      }, MenuSeparator, MenuItem {
        text: "Import"
      }]
    }
  }
  visible: true
}

Ahora: adicionalmente, debemos utilizar llaves (“{}”).

Frame {
  title: "Show MenuSeparator"
  height: 180
  width: 320
  menubar: MenuBar {
    menus: Menu {
      text: "File"
      items: [MenuItem {
        text: "New"
      }, MenuItem {
        text: "Open"
      }, MenuItem {
        text: "Save"
      }, MenuSeparator {
      }, MenuItem {
        text: "Import"
      }]
    }
  }
  visible: true
}

Instancias con nombre

Antes: era posible utilizar algunas instancias con nombre, que representaban constantes predefinidas.

Frame {
  title: "White Frame"
  background: white
  ...
}

Ahora: es necesario utilizar las constantes predefinidas, o literales objeto.

Frame {
  title: "White Frame"
  background: Color.WHITE
  ...
}

O también:

Frame {
  title: "White Frame"
  background: Color {
    red: 1
    green: 1
    blue: 1
    opacity: 1
  }
  ...
}

Literales objeto anónimo

Antes: podíamos utilizar literales anónimos y dejar que el interprete infiriese el tipo de ese bloque de código.

...
    accelerator: {
      modifier: CTRL
      keyStroke: O
    }
....

Ahora: ante la ausencia de interprete, es obligatorio declarar el tipo de cada bloque.

...
    accelerator: Accelerator {
      modifier: KeyModifier.CTRL
      keyStroke: KeyStroke.O
    }
...

Sobreescribir funciones

Antes: podíamos sobreescribir funciones sin necesidad de colocar el tipo de retorno en la declaración de las mismas.

class MyWidget extends CompositeNode {
  ...
  function composeNode() {
    ...
  }
}

Ahora: es obligatorio escribirlo.

class MyWidget extends CompositeNode {
  ...
  function composeNode() :Node {
    ...
  }
}

Binding bidireccional

Antes: bastaba con colocar la palabra reservada “bind“.

...
  TextField {
    value: bind model.firstName
  }
...

Ahora: la sintaxis de JFX Script compilado requiere del uso de la clausula “with inverse“.

...
  TextField {
    value: bind model.firstName with inverse
  }
...

Casting de Number a Integer

Antes: el casting era automático.

...
var real :Number;
num = 6.42;
var integer :Integer;
integer = real;
...

Ahora: para evitar perdida de precisión en la compilación, debe utilizarse la función “intValue“.

...
var real :Number;
num = 6.42;
var integer :Integer = real.intValue();
...

Herencia

Al menos hasta la versión del compilador de JavaFX de marzo de 2008, puede que sea necesario utilizar la palabra reservada “as” para evitar algunos problemas de herencia. Es decir, lo que antes hubiesemos hecho de esta forma:

class Foo extends Rectangle {
  ...
}

...

...
  content: Canvas {
    content: Foo {
      ...
    }
    ...
  }
  ...
}

Ahora debemos hacerlo así:

class Foo extends Rectangle {
  ...
}

var foo :Foo = Foo {
  ...
};

...
  content: Canvas {
    content: foo as Node
    ...
  }
  ...
}

Bucles

Antes: existían dos bucles, “for” y “foreach“.

...

  for (Integer i = 0; i < element.length; i++) {
    System.out.println(element);
  }

  ...

  foreach (element in group) {
       System.out.println(element);
  }
...

Ahora: al igual que con las funciones y operaciones, estos dos conceptos se fusionaron en uno solo que utiliza la palabra reservada “for” en su declaración. Este puede ser utilizado tanto como el “for” de Java así como el “foreach” de JFX Script.

...

  for (Integer i = 0; i < element.length; i++) {
    System.out.println({element});
  }

  ...

  for (element in group where element.length() < 4) {
    System.out.println({element});
  }
...

Si bien esto no fue más que una traducción de la guía de conversión a JFX Script compilado, bastará para que, junto con las partes anteriores de la guía, tengamos una lista mas o menos completa de la sintaxis del lenguaje. A partir de ahora, comenzaremos crear algunas aplicaciones sencillas, para comprender el funcionamiento de las funciones gráficas básicas. Como siempre, les dejo algunos sitios recomendados para visitar mientras voy dándole forma a las próximas partes de este tutorial:

Nos vemos en la próxima entrega.

Posted at 03:48PM ago 26, 2008 by Ezequiel Aranda in Java |  Comentarios[1]

Caso de éxito de sun rays en universidades: Sydney Businees and Travel Academy

La Sydney Business & Travel Academy (SBTA) se encuentra en la ciudad de Sydney, Australia, y ofrece un variado rango de títulos y carreras. Establecido en 1985, entre 2,500 y 3,000 estudiantes se enrolan  cada año para distintos cursos de entrenamiento, en los rubros de economía y negocios y turismo.

Problemas de negocio

Estos fueron algunos de los problemas que esta institución tuvo que solucionar:

  • Reducir costos de imantenimiento de infraestructura
  • Reducir el costo total de propiead (total cost of ownership o TCO)
  • Mantenimiento de un ambiente computacional familiar para los estudiantes.
  • Incrementar el control y el monitoreo

La Solución

Para asegurarle a los alumnos un ambiente moderno de computación, SBTA actualizó su ambiente existente de clientes delgados a Sun Ray 2 virtual display clients accedidos mediante Sun Java Card technology. Los terminales delgado corren Solaris 10 mediante servidores Sun, obteniendo un bajo esfuerzo de mantenimiento, y una solución de bajo costo, ideal para un ámbito académico.

Resultados de Negocio

  • Se obtuvo muy buen feedback de los alumnos
  • Se ahorran AU$31,000 por año en gasto de mantenimiento
  • Se redujo el costo total de propiedad a lo largo de la vida útil extensa de la infraestructura
  • Se mejoró el control y el monitoreo de las computadoras

Productos/Servicios/Soluciones

La historia, en detalle

The Sydney Business & Travel Academy (SBTA) se fundó1985  y está localizada en Sydney, Australia. SBTA emplea 20 empleados administrativos, y da capacitacion a 3,000 estudiantes que se alistan cada año en distintas especializaciones como negocios, turismo y otros.

En el competitvo mundo de la educación moderna, contar con un ambiente de cómputo optimizado es crítico para atraer estudiantes. SBTA previamene ha corrido running Microsoft Windows 98 en 200 PCs localizadas en 2 salas de computación y en la academy’s Internet cafe. Con un promedio de 4 a 5 años de vida, la academia intentó extender la vida de la inversión de su infraestructura IT convirtiendo sus Pc’s en terminales “bobas”. Esto fue logrado migrando de Windows 98 a Linux Terminal Server Project (LTSP) software para crear un entorno de clientes delgados Linux. A pesar del nuevo entorno, los alumnos percibieron problemas relativos al networking, debido a la antiguedad del equipamiento.

Los estudiantes recibieron un password básico al momento de comenzar su cursada, sin embargo, muchos usuarios podían loguearse a distintas sesiones. Con un ambiente “OPEN”, no existía mecanismo en el lugar para monitorear y controlar el acceso de usuarios. Los estudiantes podían pasar sus usuarios y passwords a sus amigos que no estaban inscriptos en la universidad, y que luego podían hacer uso de los establecimientos y laboratorios del lugar.

Enfrentandose a estos problemas, SBTA quizo modernizar su infraestructura IT, manteniendo un entorno que fuera familiar a los estudiantes y que se conectara facilmente a la red. El presupuesto que manejaba la academia en mantenimiento IT era de entre AU$21,000 y AU$31,000  por año. SBTA quería reducir estos costos y bajar el costo total de propiedad (TCO) de su infraestructura IT. Reemplazar Pc’s para SBTA era aceptar un nuevo reemplazo una vez más dentro de 4-5 años

Baados en una prueba de concepto (POC) brindada por Sun y su partner Noveix, que demostró una solución de cliente virtual Sun y servidores, SBTA eligió migrar toda su plataforma de PC a 175 Sun Ray 2 virtual display clients, y definió la tecnología de Sun Java Card para que cada estudiante pudiera loguearse en forma transparente y segura.

SBTA espera que las Sun Ray 2 thin clients duren por los próximos 10 años, en oposición al reemplazo de PC’s que hubiera necesitado en 4 años. Por otro lado, SBTA confía que luego de 4 o 5 años de usar las Sun Ray thin clients el único gasto que va a requerir sera un pequeño upgrade del servidor, resultando en una fracción del costo total de mantenimiento de un entorno Windows.

Previamente a instalar white box servers para correr un entornoLinux, SBTA desplegó un Sun Fire X4200 M2 server y tres Sun Fire X2100 M2 servers corriendo Solaris 10. Además incluyó un Sun StorageTek LT03 tape drive para proveer de un rápido sistema de back up in situ en la academia para los directorios de los alumnos y del Solaris 10

Un solo Sun Fire X2100 M2 server está corriendo VMware y Linux. VMware es usado para permitir a SBTA correr distintos ambientes de escritorios virtuales. Windows Server 2003 se encuentra corriendo bajo protocolo RDP (remote desktop protocol)  siendo usado por los 20 empleados administrativos que componen el staff de la universidad. SBTA usa una imagen aparte de VMware de Windows Server 2003  para proveer a los trainers con su propio entorno desktop. LTSP es brindado a estudiantes específicos del área de turismo para permitirles correr Galileo, un software de simulación de booking de tickets aereos.

El deploying de Solaris 10 Operating System refleja la experiencia positiva para  SBTA de usar software libre. Al elegir Solaris, el costo fue solo una consideración menor. En el pasado, SBTA intentó establecer bases de trabajo con software open source buscando que esto requiera el mínimo mantenimiento posible. Según su opinion, desde la instalación de Solaris, virtualmente este no ha requerido mantenimiento para la organización.

SBTA está usando las Sun Java Card technology para la identificacion de estudiantes. Con información de los alumnos, y un código de barra impreso en cada tarjeta, los estudiantes tienen un solo acceso de usuario al sistema computacional de la organización. Cada sesión esautomáticamente guardada cuando la tarjeta es removida de la terminal y puede ser reactivada en cualquier otro puesto de trabajo.

Todo el proyecto fue montado y configurado en 4 semanas. Como resultado del deploying de los Sun Ray 2 virtual display clients, Sun Ray Software y los servidores Sun, SBTA ha recibido altos niveles de satisfacción tanto de los estudiantes como del staff, especialmente por la velocidad que ha adquirido el entorno. La academia, por otra parte a logrado liberar máquinas antes en uso administrativo, que ahora se destinan como préstamo para los estudiantes. El mantenimiento se ha reducido a tan solo 30 minutos  por semana.

Ezequiel Singer

Tags: Manuales // Add Comment »

Discussion Area - Leave a Comment




« »