Con la disponibilidad de Xojo 2020r1 llega la nueva versión 2.0 de nuestro framework web. Si bien en lo fundamental no ha cambiado el modo en el que puedes crear tus aplicaciones web, esta nueva versión significa una re-escritura desde los cimientos y utiliza la API 2.0 para mejorar en gran medida la consistencia.

El proceso de conversión bien valdrá el esfuerzo dado que las aplicaciones creadas sobre el Framework Web 2.0 serán más robustas, capaces de soportar a más usuarios, más ágiles y también tendrán un aspecto y manejo más modernos. Por ejemplo, compara este diseño de la app demo Eddie Electronics creado con el Framework Web 1.0 con el mismo diseño creado con el Framework Web 2.0:

Comentarios de usuarios sobre la conversión:
Tras la prueba inicial rápidamente reconocí el gran aumento de rendimiento aportado por Xojo Web 2.0 a nuestra aplicación. La transición a Web 2.0 fue más sencillo de lo esperado. El código del backend pudo haberse dejado prácticamente tal cual sin cambios y se rediseñó la interfaz de usuario utilizando los nuevos controles. El aumento de rendimiento, especialmente en lo tocante a múltiples sesiones concurrentes, es enorme y permite una experiencia de usuario más fluida, con un aspecto y manejo realmente moderno.
Andreas Reichmann de inoxision GmbH

Deberías convertir tu Proyecto

Hay dos motivos por los que tendría sentido no convertir un proyecto ahora. El primero sería que se tratase de un proyecto de gran tamaño y una solución a corto plazo. Si no ves que vaya a seguir utilizándose en 5 años, entonces puede que tenga sentido continuar manteniéndolo en 2019r3. El segundo motivo podría ser que tu proyecto necesita de alguna función disponible en el Framework 1.0 y que no está presente en el Framework Web 2.0. Por ejemplo, este podría ser el caso de los eventos de ratón para Label, Canvas, MapViewer e ImageViewer. Si tu app depende de los eventos de ratón en estos controles, entonces espera a una siguiente revisión.

¿Cuánto trabajo supondrá?

He convertido personalmente la app demo de Eddie Electronics desde el Framework 1.0 al 2.0. El resultado final ha sido un proyecto con 9 diseños y poco más de 400 errores de compilación. He podido solucionar los errores, actualizar los diseños (modernizando un poco el diseño principal en el proceso), y también actualizar el código no web a la API 2.0. El archivo del proyecto Eddie es de 11,6 MB y todo el proceso me llevó en torno a un día entero para finalizarlo.

Controles Personalizados

Si tienes en tus diseños controles personalizados basados en el WebSDK, entonces deberías de quitarlos en primer lugar dado que no se convertirán. Pronto llegará un nuevo WebSDK y los autores de estos controles tendrán que actualizarlos para que funcionen sobre el Framework Web 2.0.

Trabaja con una Copia de Seguridad

Lo primero y más importante, asegúrate de que tienes una copia de seguridad de tu proyecto antes de comenzar con el proceso de conversión. Querrás mantener tus proyectos web basados en el Framework 1.0 mientras que completas el proceso de conversión. Puede que sea breve o más largo, depende de cuan grande sea tu proyecto y de lo que utilice.

El proceso de conversión en líneas generales

El mejor orden para realizar la conversión es el siguiente:

• Convierte los Container Control
• Convierte el código del Framework Web
• Convierte los Diseños
• Convierte el código de la API 1.0 a la API 2.0

Echemos un vistazo a cada uno de los pasos en orden.

No tengas miedo

Cuando abres inicialmente tu proyecto en Xojo 2020r1 (o posterior), probablemente veas un diálogo similar a este:

Este simplemente te indica que estás utilizando un control, evento o propiedad que ya no está presente en el Framework Web 2.0. Una vez que guardes tu proyecto, se eliminarán estos elementos incompatibles. Sin embargo, no tengas miedo, dado que estás trabajando sobre tu copia del proyecto de modo que siempre puedes volver a tu proyecto original basado en el Framework web 1.0 en el caso de que tengas la necesidad de hacerlo.

Convertir Container Controls

Si tu proyecto utiliza Container Controls, ábrelo en Xojo 2020r1, guárdalo de inmediato y vuelve a abrirlo. Esta acción convertirá correctamente tus Container Controls para que se rendericen correctamente en el Editor de Diseño (Layout Editor).

Convertir Eventos

Si bien muchos nombres de eventos han cambiado, sólo unos pocos lo han hecho de forma ostensible. La mayoría han cambiado para que sea más claro cuándo tienen lugar. Por ejemplo, WebPage.Open es ahora Opening para reflejar el hecho de que la página está en el proceso de abrirse y que aun no está abierta. WebPage.Close, por otra parte, ha cambiado su nombre a Closed porque en el momento en el que se dispara el evento, la página ya se ha cerrado.

Cuando abres tu proyecto en 2020r1, todo el código de los eventos se mueve automáticamente a los nuevos eventos. Sin embargo, probablemente tengas algún código en eventos que no se pueden convertir automáticamente porque aun no existe un evento similar. Tendrás que mover este código manualmente. En el caso de que no exista un nuevo evento evidente, guarda este código en alguna parte hasta que hayas finalizado con el resto del proceso y puedas decidir donde debería de ir. Entonces podrás borrar el evento o eventos que no se puedan convertir.

En el caso de Eddie Electronics, el proyecto contaba con 107 eventos, 7 de los cuales no podían convertirse automáticamente.

Convertir código del Framework Web

Una vez que hayas gestionado cualquiera de los eventos que no se pueden convertir automáticamente, el siguiente paso consiste en solucionar los errores de compilación como resultado de los cambios de las API entre la versión 1.0 y 2.0 del Framework Web. El Framework Web 2.0 utiliza la API 2.0 exclusivamente.

La API 2.0 ha sido diseñada para que sea extremadamente consistente. Inicialmente puede resultarte extraña dado que estás acostumbrado al framework original. La mayoría se acostumbran a las nuevas API razonablemente rápido y aprecian la consistencia dado que facilita el encontrar la API que estás buscando y, por tanto, se desarrolla más rápido.

Desafortunadamente, en el caso del framework Web no resulta práctico mantener las nuevas API y las antiguas, de modo que esto significa que tendrás que hacer algunos cambios en tu código antes de que se compile tu proyecto web. Lo más fácil consiste en pulsar el botón Run y dejar que el compilador te indique las partes que no entiende. Te proporcionará una lista de errores, la mayoría de los cuales pueden solucionarse simplemente sustituyendo la antigua API por la nueva. El cambio más común será que la propiedad que contiene el valor principal de un control (en la mayoría de los casos) se llama Value.

Por ejemplo, TextField1.Text pasa a ser TextField1.Value. Estos son rápidos de cambiar. El único código que deberás actualizar es el código asociado con el framework Web. Mientras que el código no específico con el framework web puede generar advertencias de que debería de actualizarse a la API 2.0, esto no es en absolutamente algo obligatorio a la hora de convertir el proyecto y ejecutarlo. En función de cuál sea el tamaño de tu proyecto, puedes optar por realizar dicha conversión en una fecha posterior.

Volviendo al proyecto interno que mencionaba anteriormente, tras tratar con 7 eventos que no pudieron convertirse automáticamente y al hacer clic nuevamente sobre Run, los resultados fueron de algo más de 400 errores de compilación. Esto puede parecer como una tarea desalentadora, pero no es tan malo como parece. Prácticamente la mitad de estos errores se corresponden con cosas que pueden solucionarse con un simple buscar/sustituir. Por ejemplo:

También hay muchos otros que pueden convertirse mediante buscar y sustituir.

Nota sobre Buscar/Sustituir: Cuando se sustituyen miembros de clase, siempre empieza con un punto y para los métodos con un paréntesis abierto para reducir el hecho de que puedas sustituir algo que sea una coincidencia pero que no sea un miembro de la clase o bien que sea un miembro de la clase equivocada.

Por ejemplo: .Cell(

Convertir Diseños

La mayoría de los controles en el Framework Web 2.0 son más grandes que sus equivalentes de la 1.0. Esto significa que tendrás que redimensionarlos y que, en muchos casos, cambiar también su posición. En el caso los controles que tienen una altura estándar, como puedan ser Label, TextField, Button, PopupMenu, CheckBox, SegmentedButton, es recomendable que ajustes su tamaño inicialmente al nuevo estándar de 38. Puedes hacer esto, todo a la vez, para un mismo diseño. Sólo has de hacer Shift + Clic sobre varios controles y cambiar su propiedad Height en conjunto a 38.

Ejemplo de Controles en 2019r3

Ahora que tienes todos los controles con la altura correcta, puedes comenzar a cambiar su posición. Sin embargo, antes de hacerlo, querrás cambiar el diseño propiamente dicho de modo que añadas espacio para que quepan las versiones de mayor tamaño de tus controles. Antes de ello, echa un vistazo a los controles ListBox, ImageViewer, TextArea y MapViewer para ver si sus propiedades de bloqueo están definidas de modo que varíen sus tamaños cuando cambies el tamaño de la página. Si lo están, desactívalos por ahora de modo que puedas crear más espacio con mayor facilidad.

Ahora estás listo para ampliar tu diseño de modo que se acomode a los controles de mayor tamaño. Los controles más populares (Label, TextField, Button, Checkbox, Popupmenu y otros) son un 42% más grandes. Para saber cuanto has de ampliar tu diseño, mide la altura del área con los controles que se han ampliado (un Rectangle funciona como una buena herramienta de medición) y añade a continuación un 42%. Por ejemplo, en el proyecto de ejemplo interno que hemos estado usando, el área del diseño CustomerDetailsPage que incluye los campos de nombre y dirección tiene 158 píxeles de altura en la versión original. 158 * 1,42 = 224 píxeles. La diferencia es de 66. Por lo tanto, ampliando el diseño en 66 píxeles crea el espacio adicional suficiente para los diversos controles en sus actuales alturas.

Si sigues estas indicaciones, verás que las páginas web, contenedores y diálogos web pueden actualizarse muy rápidamente. El ejemplo sólo llevó 5 minutos para actualizarlo.

Controles de Ejemplo en 2020r1

Este es un vídeo que muestra el proceso:

En resumen:

1. Desactiva LockTop para todos los controles que deban cambiar su tamaño y activa LockBottom para esos mismos controles de modo que cuando amplíes el tamaño del diseño dichos controles se muevan hacia abajo.
2. Mide el área de dichos controles para saber cuánto requieren, multiplica dicho valor por 1,42 y resta la altura original. Esto arrojará el número de píxeles que has de añadir a la altura del diseño en el Inspector para añadir espacio de modo que quepan los controles que ahora son más largos.
3. Selecciona todas las Label, TextField, Button, CheckBoxes, PopupMenus y SegmentedButtons. En el Inspector, ajusta su altura a 38.
4. Empezando con los controles ya redimensionados más próximos a la parte inferior del diseño, muévelos hacia abajo y continúa con los que se encuentren sobre ellos.
5. Vuelve a activar las propiedades de bloqueo que hubieses desactivado en el primer paso.

Nota sobre las Toolbar: Si bien se está trabajando en un nuevo editor visual, este no está disponible en 2020r1. Las Toolbar están soportadas en el framework, de modo que puedes crearlas en código. Consulta WebToolbar en la referencia del lenguaje para ver un ejemplo.

Nota sobre Separator: Ya no existe el control Separator. Cuando se importe el proyecto, los separadores se convierten a Rectangles haciéndolos más finos para que realicen la misma función.

Nota sobre WebAnimator: Ya no existe esta clase. Sin embargo, puedes consultar la clase WebStyle para obtener detalles sobre como añadir transiciones animadas.

Nota sobre WebStyles: Dado que el Framework Web 2.0 se basa fuertemente en el uso de temas frente a la aplicación de estilos sobre cada uno de los controles, ya no hay un editor de estilos web visual. Sin embargo, puedes utilizar la clase WebStyle para aplicar estilo de forma individual sobre los controles. También puedes crear tu propio tema Bootstrap que se aplicará sobre todos los controles en todos los diseños.

Probar la conversión inicial

En este punto ya estás listo para probar la conversión inicial de tu proyecto. Haz clic en Run y prueba toda la funcionalidad. Puede que aun necesites hacer algunos cambios adicionales para afinar el comportamiento.

Paso Extra: Convertir el código restante a la API 2.0

Ahora que has convertido tu app, es probable que quieras considerar la conversión del código restante a la API 2.0 dado que es la API en la que centraremos nuestra atención en adelante. También es la API compartida con desktop y que compartiremos con nuestro soporte para dispositivos móviles en breve.

Ahora probablemente te estés preguntado, “Espera un momento, ¿no he convertido ya mi código a la API 2.0 cuando he corregido todos esos errores de compilación?” Lo hiciste pero sólo para el Framework Web 2.0 propiamente dicho.

Es probable que tu app utilice partes del framework de consola encargado de gestionar cuestiones como la lectura/escritura de archivos, la conectividad de red, conexión a bases de datos, y más. Este código no se ha convertido automáticamente a la API 2.0, pero deberías planear hacerlo en algún momento.

Cuando decidas hacerlo, selecciona Project > Analysis Warnings. Cuando aparezca el diálogo, asegúrate de activar las dos primeras casillas de verificación. Estas son las responsables de informarte sobre las advertencias de deprecados. Selecciona ahora Project > Analyze Project. El panel Warnings and Error te mostrará un listado de las ubicaciones donde estás usando una clase, método o propiedad que ha sido reemplazada y te ofrecerá la opción que lo sustituye. En este punto sólo precisas ir error por error haciendo los cambios indicados. La API 2.0 y la API 1.0 comparten gran parte de la implementación bajo el capó, de modo que probablemente pase un tiempo antes de que realmente necesites hacer el cambio. También puedes optar por hacerlo poco a poco, o simplemente cuando encuentres un bug en algo de la API 1.0 que haya sido corregido en la versión 2.0 de la API, por ejemplo.

Comprobarás que estas conversiones son fáciles de hacer y muchas pueden gestionarse con buscar y sustituir. Me ha gustado especialmente la conversión de los PreparedStatements de las bases de datos, dado que estas pasan de cuatro o cinco líneas de código a sólo una.

Conclusión

Cuanto más grande sea tu proyecto, más trabajo te llevará realizar la conversión. Afortunadamente, esto es algo que sólo debes hacer una vez. El proceso sugerido anteriormente te ahorrará tiempo durante el proceso de conversión.