Comentarios en: Cómo parchear el Framework de Flex http://www.madeinflex.com/2007/05/16/como-parchear-el-framework-de-flex/ Creando Soluciones RIA... Fri, 29 Aug 2008 04:20:24 +0000 http://wordpress.org/?v=2.1.3 By: Israel Gaytan http://www.madeinflex.com/2007/05/16/como-parchear-el-framework-de-flex/#comment-2379 Israel Gaytan Wed, 16 May 2007 15:05:31 +0000 http://www.madeinflex.com/2007/05/16/como-parchear-el-framework-de-flex/#comment-2379 Vaya que excelente artículo Alberto!!!! Felicidades súper súper útil! Vaya que excelente artículo Alberto!!!!

Felicidades súper súper útil!

]]> By: Javier Alconada http://www.madeinflex.com/2007/05/16/como-parchear-el-framework-de-flex/#comment-2380 Javier Alconada Wed, 16 May 2007 17:14:56 +0000 http://www.madeinflex.com/2007/05/16/como-parchear-el-framework-de-flex/#comment-2380 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? 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?

]]> By: Xavi Beumala http://www.madeinflex.com/2007/05/16/como-parchear-el-framework-de-flex/#comment-2389 Xavi Beumala Thu, 17 May 2007 05:53:32 +0000 http://www.madeinflex.com/2007/05/16/como-parchear-el-framework-de-flex/#comment-2389 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. 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.

]]> By: Edgar Rivera http://www.madeinflex.com/2007/05/16/como-parchear-el-framework-de-flex/#comment-2390 Edgar Rivera Thu, 17 May 2007 08:34:16 +0000 http://www.madeinflex.com/2007/05/16/como-parchear-el-framework-de-flex/#comment-2390 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 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

]]> By: Alberto Albericio http://www.madeinflex.com/2007/05/16/como-parchear-el-framework-de-flex/#comment-2391 Alberto Albericio Thu, 17 May 2007 08:37:07 +0000 http://www.madeinflex.com/2007/05/16/como-parchear-el-framework-de-flex/#comment-2391 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 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

]]> By: Javier Alconada http://www.madeinflex.com/2007/05/16/como-parchear-el-framework-de-flex/#comment-2394 Javier Alconada Thu, 17 May 2007 18:36:19 +0000 http://www.madeinflex.com/2007/05/16/como-parchear-el-framework-de-flex/#comment-2394 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. 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.

]]> By: Alberto Albericio http://www.madeinflex.com/2007/05/16/como-parchear-el-framework-de-flex/#comment-2408 Alberto Albericio Fri, 18 May 2007 06:57:23 +0000 http://www.madeinflex.com/2007/05/16/como-parchear-el-framework-de-flex/#comment-2408 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í: <mx:TextInput enabled="{ model.enabledMode }" enabledToolTip="{ model.enabledMode }" /> 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 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í:

enabled="{ model.enabledMode }"
enabledToolTip="{ model.enabledMode }"
/>

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

]]>