Cómo parchear el Framework de Flex


Alguna vez te has encontrado en la situación de tener que modificar todos los controles que usa tu aplicación por un bug en la clase UIComponent? Si es así, estás en el sitio correcto para aprender cómo corregir el framework de Flex y así solucionar de raiz el problema.

Antes de empezar, he de advertir que, además de las ventajas que pueda aportar el corregir un bug concreto, tendremos efectos colaterales no tan beneficiosos pero, a veces, aceptables; todo dependerá básicamente de evaluar el ratio beneficio/desventaja para un escenario concreto.


Tenemos el source del Framework de Flex

Si alguna vez habéis inspeccionado el plugin de Flex para Eclipse, habréis podido notar que, dentro de la carpeta de instalación de mismo, normalmente en C:\Archivos de Programa\Adobe\Flex Builder 2.X Plug-in, podréis encontrar una carpeta llamada

Flex SDK 2\frameworks\source

Pues bien, dentro de esa carpeta está todo el source del SDK de Flex; esto es un detallazo por parte de Adobe, no sólo porque nos va a permitir generarnos nuestro propio framework parcheado sino porque supone un resource documental bestial a la hora de entender el framework, su arquitectura de componentes, etc.

Tenemos el script de ANT para compilar el framework!

Dentro de la carpeta raíz de instalación del plugin podréis encontrar diferentes ficheros. Entre ellos, uno llamado build_framework.xml que corresponde a un script ANT para la compilación del framework como muestra el siguiente screenshot:

framework_files.png

Ahora que tenemos localizado todos los elementos necesarios para generar nuestra propia versión del framework, vamos a hacer un pequeño cambio ( a modo de ejemplo ) y, seguidamente, vamos a pasar a regenerar el framework y a ver cómo se utiliza en nuestro proyecto Flex.

Modificar el Framework, con cuidado!

No sé si lo he apuntado antes pero la modificación de cualquier clase del framework de Flex exige un cierto conocimiento de lo que se está haciendo porque, de lo contrario, la modificación puede acarrear consecuencias impredecibles dentro del funcionamiento de nuestra aplicación.

A modo de ejemplo, voy a hacer un minúsculo cambio en la clase UIComponent que afectará, directamente, a todos los componentes visuales del framework, ya que todos ellos utilizan UIComponent como clase base.

En la última versión oficial de Flex, en la próxima tengo entendido que está corregido, si defines un errorString=”” ( en ciertas circumstacias ) para cualquier control, aparece un borde negro bastante molesto a la vista. Para solucionar esto, vamos a añadir 1 sóla linea, que ni voy a comentar, al código fuente de UIComponent y vamos a arreglar el problema.

Definimos un proyecto Flex básico nuevo que va a tener todo el código del framework, quedaría algo así:

framework_project.png

Editamos el fichero UIComponent.as que se encuentra en la ruta:

\mx\core\UIComponent.as

Localizamos la función que dibuja el borde al definir un errorString dado, en este caso se llama “setBorderColorForErrorString()”
Nos estudiamos un poco el código, localizamos que existe un problema en las primeras lineas y lo corregimos:

Versión original:

[ftf w=”450″ h=”200″]
….
if (!_errorString || _errorString.length == 0 )
{
setStyle(“borderColor”, origBorderColor);
saveBorderColor = true;
}

[/ftf]

Versión modificada:

[ftf w=”450″ h=”200″]
….
if (!_errorString || _errorString.length == 0 )
{
if ( !isNaN( origBorderColor ) ) {
setStyle(“borderColor”, origBorderColor);
}

saveBorderColor = true;
}


[/ftf]

Recompilar el Framework

Ahora localizamos, dentro del proyecto del framework, el script ANT de compilación y lo ejecutamos como ANT build:

framework_build.png

En la pantalla siguiente, seleccionaremos sólo el target build-framework:

framework_target.png

Seguidamente lo ejecutaremos y, después de unos segundos, obtendremos nuestra versión del framework ( framework.swc ) en el directorio de salida, por defecto el:

\frameworks\libs\framework.swc

Utilizar el nuevo Framework

Ahora únicamente nos queda sobreescibir el framework original por el nuestro y ya está!

Para eso, copiamos el nuevo framework.swc en la carpeta donde lo va a buscar Eclipse, por defecto en:

C:\Archivos de Programa\Adobe\Flex Builder 2.X Plug-in\Flex SDK 2\frameworks\libs

Resultado

Aquí tenemos 2 aplicaciones Flex: una generada usando el framework original y la segunda utilizando nuestro framework modificado.

En la primera, al hacer clic sobre el botón, el control muestra un border negro.

Aplicación con el framework original

En la segunda, este problema esta solventado gracias a nuestro “parche”.

Aplicación con el framework modificado

Observaciones

  • Al estar modificando el framework original, cada vez que Adobe saque un nuevo release tendremos que repasar todos nuestros cambios. Esto supone un mantenimiento extra asociado.
  • Hay que invertir tiempo en entender como funcionan las clases que estamos tocando.
  • Quizás haya gente que se anime a utilizar esta técnica ahora que Adobe ha anunciado que liberaliza el SDK.

    7 Comentarios

    1. Javier Alconada

      Me pregunto que tan buena idea es cambiar el Framework directamente. Como mencionas en tus Observaciones, no es lo recomendable porque por cada nueva version que libere Adobe no podras usarla inmediatemente sino hasta que tambien le hagas las mimas modificaciones. Que hay de simplemente extender el componente original y sobreescribir el metodo deseado?

    2. Xavi Beumala

      Hola Javier,

      el motivo de parchear los componentes y no extenderlos es que hay puntos en los que por ejemplo el error o cambios que se quiere hacer está en un método privado y para cambiarlo se tendría que sobreescribir la mitad de la clase.

      Por otro lado también está el tema de las dependencias y la transparencia de uso. Si un componente usa alguna utilityClass y es la que tu quieres cambiar, se tiene que cambiar el componente que la utiliza y la utility class y esto puede ser de una forma recursiva.

    3. Edgar Rivera

      Excelente Alberto, eso de andar revolviendo las tripas del Framework, aunque como tu dices tiene el inconveniente de que con cada nueva actualización toca revisar todo de nuevo.

      Lo interesante será cuando esté totalmente operativo el equipo encargado de mantener y ordenar el SDK (openSource) esto permitirá que cambios pequeños como este se incorporen rápidamente.

      Un saludo,

      Edgar Rivera

    4. Alberto Albericio

      Hola Javier,

      Te respondo y complemento un poco lo que ha comentado Xavi. En la aplicación de ejemplo que he puesto he usado sólo 2 componentes visuales y quizás podrías pensar que es más fácil crear tus propios componentes y solucionarlo así PERO eso no es del todo cierto, déjame que te enumere alguna de las razones por las que yo no lo haría:

      1) Es 1 linea de código. Es muy facilmente mantenible de un release a otro. En este caso no hará falta porque es un bug que ya han cerrado.

      2) En cualquier aplicación seguro que estarás usando mas de 20 componentes visuales diferentes: Listas, Botones, Labels, etc, etc El solucionar el problema con 1 linea de código es mucho más eficiente que crearte 20 componentes propios. Crear estos 20 componentes podría llevarle a un desarrollador standard unas 1-2 horas?

      3) Con casi toda seguridad, el resultado de utilizar 20 componentes va a resultar en un mayor tamaño del swf generado sin entrar en detalle de otros aspectos de compilación.

      4) Para solucionar problemas de esta índole, es una best practice atacar la clase base de los componentes que no parchear cada componente que la extiende. La arquitectura del framework así lo promueve.

      5) La solución más fácil que funciona siempre es la mejor solución 🙂

      Hay más puntos pero esta claro que, en este escenario, está más que justificado aplicar la técnica descrita.

      Un saludo,

      Alberto

    5. Javier Alconada

      Tal vez tu ejemplo no justifique el ‘parchar’ el Framework. Claro que las aplicaciones tienen muchos componentes visuales, pero en tu ejemplo tu corriges el problema cuando se usa el errorString=””, el cual es usado para validaciones. La pregunta es cuantos de esos elementos visuales usaras para validacion? Regularmente es uno, el textInput. Te has encontrado con otro caso real en tus proyectos donde hayas tenido que parchar el Framework, y que te fuera productivo? Uno de los usos avanzados del Framework es precisamente el ser capaz de extender y sobreescribir sus controles usando override.

    6. Alberto Albericio

      Javier,

      Quizás éste sería el único caso en que me he “lanzado” a parchear el Framework puesto que me hacía un efecto realmente feo en la aplicación.

      No estoy contigo en que el errorString se tenga que utilizar sólo vinculado a los validadores. De hecho, en el ejemplo no lo está; puedes utilizar esta feature para otras cosas y puedes cambiar incluso el color global del toolTip de errorString.

      Tampoco estoy contigo en que sólo se deba usar validación en controles TextInput. De hecho, personalmente, si pongo validación, la pongo en todos los controles: ComboBoxes, RadioButtons, etc, etc… En el último form compuesto que hice creo que los controles accedían a unos 50; con lo que, al validar todos, me encontraba con una fiesta de color negro intolerable 🙂

      Otro caso en el que se podría parchear el Framework sería?

      “Creo que ahora cuando deshabilitas un control y tiene asociado un errorString, el errorString y el sistema de toolTip para este error siguen mostrándose aun con el control deshabilitado. Creo que añadiría una propiedad a UIComponent, llamémosla enabledToolTip, que pudiera deshabilitar y habilitar cuando a mi me diera la gana; en este caso, iría vinculada, en el tag del control, a su propiedad enabled.Algo así:

      Así podría habiltar/deshabilitar el mostrar el toolTip de error/validación/otros cuando me diera la gana.”

      Y respondiendo ya a tu última frase, es cierto que una de las virtudes del Framework es su capacidad para ser extendido PERO hay que saber distinguir en qué casos es mejor parchear y en qué casos es mejor extender. Tanto en el ejemplo de artículo como en el ejemplo que te he dado en este comentario, creo que está justificado el parche.

      Alberto

    Deja un comentario

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

    Acerca de Made In Flex

    Made In Flex es una comunidad de desarrolladores de Apache Flex creada en 2006.

    Apache Flex, anteriormente conocido como Adobe Flex, es un SDK (kit de desarrollo de software) para crear aplicaciones enriquecidas - multiplataforma basadas en Adobe Flash donado por Adobe a la fundación Apache in 2011 y promocionado a proyecto de primer nivel en Diciembre de 2012.

    Actualmente estamos cambiando muchos aspectos del sitio web para ofrecer un sitio útil para toda la comunidad que tenga en cuenta las necesidades actuales.

    Últimas Fotos

    Instalador de Apache Flex

    Entrar o Registrase