Esto, viniendo de Adobe y sus componentes hay que tomarlo con una sonrisa como poco. Todas y cada una de las versiones de los componentes era el día de su presentación “muy fácil de skinnear, no como la versión anterior”.

Es sonrojante el tiempo que le está llevando a Adobe sacar un juego decente y sin bugs de componentes. A mi por lo menos me lo parece.

Yo ya he dicho que para mi deberían estar integrados en el mismo player y automáticamente disponibles para todo el mundo, lo mismo que la clase Math o cualquiera de las otras.

Ya, ya sé que entonces arreglar bugs se complicaría mucho, pero yo *nunca jamas* he oido que un navegador tenga un bug de funcionamiento en un RadioButton, un CheckBox o un TextArea. Y si Mozilla, Opera e incluso hasta IE6! llegaron a ese nivel, no me puedo creer que Adobe no.

Y ya, también sé que no piensas lo mismo Joan : P

Dale un vistazo al nuevo framework Gumbo, te recomiendo el video de Ely. Creo que Gumbo comparado con Halo, que es lo que venimos viendo desde los tiempos de Flaash MX 2004, es realmente un avance en ese aspecto.

En cuanto al tema que comentas de distribución con el Flash Player, ahora tienes el cacheo de RSLs…es un punto intermedio entre ambas posiciones no?.

Un saludo!!

El cacheo de los componentes no me parece la solución, me parece que complica la cosa y mucho. Quicir, suponiendo que la implementación del cacheo en el player sea *perfecta* a la primera (y es mucho suponer), ahora hay que explicarle a los desarrolladores todo el lío y cómo va el proceso. Que si cacheo, versiónes, sandbox de seguridad, crossdomains… MUCHO LIO para un problema TAN sencillo.

Todo mi razonamiento viene de aquí: Los componentes son BÁSICOS, tan básicos como la clase Math o DisplayObject y por eso deberían estar en el player.

Es más, todo el tema del skinning no estoy ni siquiera seguro de que sea correcto desde el punto de vista de la usabilidad. Un usuario de HTML sabe perfectamente qué es un radio y qué no, qué es un combo y qué no.

Pero es que además lo que yo propongo no sería excluyente. Es decir, los componentes básicos estarían disponibles para todos, quien quiera utilizar unos propios ADELANTE, exactamente igual que ahora.

Explícale a uno de HTML que tiene que cachear los radios, los combos y los textareas…. no cuela.

Que alguien me explique por qué todo el tema del cacheo tiene sentido para Flash y no para HTML. Una buena razón y me callo : )

Salud!

@zarate: la solución del cacheo no tiene implicaciones demasiado complejas y es equivalente en funcionalidad a lo que propones, simplemente se trata de una cache interna del player exclusiva para determinados contenidos signados por Adobe como por ejemplo las distintas versiones del sdk de flex y en el futuro puede que incluso otras librerías de terceros. Gran parte del proceso es automático y sencillo de llevar a cabo.

Que un set de componentes sea algo básico es una opinión muy personal, pero los desarrolladores de juegos dirán que algo básico es soporte completo para 3D y que los componentes no los quieren para nada, otros dirán que más codecs de vídeo, otros que más soporte para audio, etc… lo realmente básico en última instancia son las herramientas que nos ofrecen las APIs del player, que nos ofrecen una funcionalidad base suficiente para que nosotros podamos construir sobre ella las librerías que creamos convenientes.

Todo lo que sea buscar soluciones para evitar cargar el player y mantener su tamaño al mínimo necesario es a mi parecer bueno, y el sistema de cacheado creo que es una buen ejemplo de ello.
Es mi opinión personal

En mi caso, la razón para oponerme es justamente la contraria a la tuya: los componentes son algo muy específico. Entiendo que para un desarrollador Flex los componentes son algo prioritario, pero el Flash Player no es sólo de los “Flexeros”. Por ejemplo, en mi caso, en los últimos casi 3 años no he utilizado ningún componente (a excepción de un picker, para ser sinceros). Sólo hay que mirar sitios como el FWA para ver que los componentes no son algo intrínseco del Player…

Saludos!