En esta segunda edición del #DuaneMx2011 Duane impartio un workshop de desarrollo de apps para móviles usando Flash Builder Burritov(el cual ya fue liberado) donde aprendimos a usar las características mas importantes de un dispositivo movil, que ahora, podemos darle salida para móviles o tabletas. Duane aprovechó también para grabar un capítulo de su show, Duane's World, en Adobe TV en el cual es muy probable que salgas si es que asististe al evento y que somos los primero en repetir .

Les dejamos fotos del evento acompañada de "509" de 22nd Century y el resumen de las charlas que antecedieron al workshop.

La agenda del día estuvo de la siguiente manera:

Primero Israel Gaytan @isragaytan con High Performance RIA Teams nos platicó sobre los pormenores y formas de trabajo en equipos dedicados al desarrollo de RIA's así como también nos dio unos cuantos tips para la administración y gestión de proyectos con metodologías como SCRUM, dejando muy en claro que algo tan básico como la comunicación es determinante en el éxito o fracaso de un proyecto. Aquí la presentación que dio.

Después Pedro Jimenez @creativepete nos mostró la fuerza que puede tener Flash Media Server con su charla "Improve your Flash-based RIA with VoIP". En ella hizo una interesante perspectiva al plantear como serian los sitios web si tuvieran implementados accesos VoIp y como estos mejorarían la experiencia del usuario al visitar estos sitios. Entre ejemplos y estadísticas Pedro nos dejo la cosquillita de la importancia y relevancia de la VoIp en las RIA's y como la VoIp a pesar de ser un concepto algo añejo puede seguir revolucionando el área del desarrollo de software. Aquí la presentación de Pedro y el código usado.

En la penúltima charla Claudio Nebbia @claudionebbia y David Rojas @rojasazules nos impresionaron con las capacidades que puede alcanzar Flash al integrarlo con Arduino en su charla "Arduino and Flash, making things move, shine and feel". Pudimos presenciar algo que habíamos visto en youtube o leido en algunos blogs sobre la potencia de arduino y lo simple y sencillo que es integrarlo con la Flash Platform y poder desarrollar RIA's interactuando la realidad física con la virtual. Aqui su presentación, el código usado y un post donde describen detalladamente el proceso usado para replicar el demo de su charla.

Esperamos que este evento les allá sido muy útil y estén pendientes al twitter de @riactive y el site en Facebook para mas noticias y nuevos eventos!

Saludos y Happy Coding!!!
by Sergio Brito aka @yacaFx

Eso no es todo!!!!!!! este Martes, SI este Martes 5 Abril tenemos una charla informal con Duane

Donde:   Hacker Room (a una cuadra del Angel de la Independencia)
Hora:      16:00 hrs
Posibles Temas: HTML5, Flash and AJAX to the Year 2020 , SEO Tips and Tricks, Music,Mobile Development, Technology and Culture.
Registro:  Secrets from Technoracle

Happy networking!!!!

Comandos

La clase command es una clase que permite ejecutar codigo mediante la sobre escritura del metodo execute. El verdadero poder de los comandos radica en que estos responden no a inyecciones, sino a llamadas de eventos.

Los comandos son definidos en el contexto de la siguiente manera:

y a lo largo del tiempo de ejecución de nuestra aplicación cualquier actor del framework que dispare el evento asociado mandara ejecutar el método excecute de nuestro comando.

Al principio es complicado entender la razón de estos, ya que en múltiples ocasiones tenemos un mundo de comandos y no haremos una clase para cada uno ¿verdad?. Pero la razón radica en que los comandos serán utilizados en ocasiones especificas para realizar tareas complejas o de muchas inyecciones de dependencias. Recordemos que las inyecciones de dependencias tienen un costo en memoria, puede o no ser alto pero una manera para controlar ese costo es que un solo objeto tenga las inyecciones como una comando que tiene inyección de 3 servicios con 5 modelos por ejemplo. Entonces de esta manera no tendremos múltiples mediadores que inyecten 8 componentes y así solo tenemos a uno, un comando.

Ademas una de sus cualidades es que podemos definir que este comando se ejecute una sola vez en la vida del contexto. Esto funciona muchas veces para obtener datos pesados y asegurarnos de que ningún otro objeto va a hacer esa petición en algún lado de la aplicación.

En nuestro ejemplo colocaremos un código simple que nos mostrara como ejecutar la inyección del evento y la inyección de un servicio.

Servicios.

Los servicios en Robotlegs son la extensión del patrón MVC, es la razón por la cual el modelo se vuelve mas simple y las peticiones foráneas se hacen aquí.

Las clases servicios extienden a la clase Actor (al igual que los modelos) pero tienen una particularidad, estos son invocados a través de una interfaz. Si, en efecto necesitamos crear una interfaz para que sea esta la que inyectemos en los otros actores del framework.

Robotolegs, promueve el trabajo con interfaces porque es mas fácil y seguro conocer los métodos que las clases implementan, sin conocer la forma de su implementación. Por lo tanto lo que nosotros podemos realizar es una sola interfaz e implementarla en varias clases que se dediquen a realizar servicios de datos.

En nuestro ejemplo crearemos una implementación del patrón de diseño de interfaz DAO

Y lo implementaremos en nuestra clase RecetasDAOImp

Y aqui el metodo obtenerTodosResult que es parte de la clase RecetarioDAOImp:

Lo único que tenemos que realizar en el contexto es decir que cuando alguien pregunte por DAO le entregaremos un RecetasDAOImp.

Aquí hay algo importante, y es que la inyección realizara un singleton en toda la aplicación. Por lo tanto cada que alguien invoque a RecetasDAOImp se entregara el mismo objeto. Esto es muy importante por si quieres saber el estado del servicio ejecutado.

Modelo.

Les tenemos una buena noticia, ya no trabajaran con Fat’s Models. Ahora que separamos los servicios del modelo podremos tener modelos mas estilizadas

Al igual que los servicios los modelos también extienden la Clase Actor, ya que esta clase es capaz de distribuir eventos. Y funciona muy buen para un guardado de datos en toda la aplicación. Así podemos tener en cualquier momento ciertos datos que requerimos en la solución.

Inyectando esta clase, nosotros realmente hacemos un singleton y con un buen uso nos podremos ahorrar muchos dolores de cabeza al ir por datos. Y esto nos asegura que solamente tendremos un arrayCollection con un tipo de dato.

En nuestro ejemplo construiremos una clase llamada Recetario y una variable recetasModelo que guardara los resultados de todas las recetas en nuestra BD y distribuiremos un evento que contenga al modelo cuando acabemos de llenarlo.

Comunicación con Mediadores.

Recuerden que el caso de usar este framework es que no importa quien ejecuta las peticiones del comando, servicio o modelo solo importa que eventos estamos distribuyendo. Por lo tanto debemos tener un evento que guarde los datos que vamos a transmitir durante el evento.

Por lo tanto cuando nosotros queramos estar al pendiente de algún evento que va a escuchar el contexto necesitaremos registrarlo en nuestro método onRegister del mediador.

Escribiremos lo siguiente en nuestro mediador para estar al pendiente de nuestro evento que distribuye la clase Recetario cuando acaba de llenar la variable recetas.

Este seria el código final de nuestro contexto de aplicación.

Conclusiones.

Con Robotlegs tenemos un poderoso framework que implementa Inversión de Control bajo Inyección de dependencias y un patrón extendido que nos permitirá un flujo mas separado de código. Incluso si ustedes desean pueden separar algunas funciones, dedicando algunas funciones a distintas personas, solo recuerden que hay que tener integraciones continuas y frecuentes.

Mis proyectos con Robotlegs han sido de gran agrado, no he tenido que parchar código y es cada vez mas fácil encontrar en donde se encuentran métodos que hay que modificar.

Tal vez al principio piensen “Es mucho trabajo para un hola mundo”, pero la realidad es que este framework esta preparado para trabajar con muchas inyecciones y miles de componentes. Imaginen 30 servicios con 3 interfaces, o múltiples componentes con miles de lineas de código, realmente creen que seria fácil encontrar y modificar el código? Hagan algo de tamaño medio para iniciar y verán que Robotlegs es un gran amigo que pueden llevar en el coche y que maneje por ustedes =)

Como ultima aportación, dejare aquí los links de algunos tutoriales en ingles y uno en español para mas información, junto con algunas listas de twitter que contienen a desarrolladores que ya usan Robotlegs en su trabajo. También les dejare el código en github que contiene el proyecto generado.

Tutoriales

• Articulo en MIF
• Consejos de buenas practicas con RL
• JHooks tutorial
• JHooks TDD & RL

Listas de twitter

• http://twitter.com/stray_and_ruby/robotlegs
• http://twitter.com/robpenner/robotlegs-contributors
• http://twitter.com/eldervaz/robotlegs-es

Mi proyecto Robotlegs 101 RIActive en GitHub

Y como un pequeño plus, hay algo que siempre me molestaba al crear un proyecto en Robotlegs y era que no tenia como crear todos los paquetes de un solo golpe. Asi que me di a la tarea de hacer un pequeño script en bash para que les ayude a crear todos los paquetes que puede ser que ustedes implementen. Sientan la libertad de hacer un fork, modificarlo y actualizar el proyecto.

Proyecto en Robotlegs Package Creator en GitHub

Con esto me despido no sin antes recordarles que en RIActive queremos contar con su opinion y  unos consejos en los comentarios serán bienvenidos. Les mando un abrazo y que tengan un buen coding!

Esta es la segunda entrega de la serie de artículos Robotlegs 101, en la anterior parte revisamos una Introducción a la tecnología y en esta aprenderemos los fundamentos: cómo configurar el contexto y manejar vistas y mediadores para poder separar el código de la vista.

Listos? startup...

Primero necesitamos que nuestra aplicación sea configurada por una clase que herede propiedades de la clase Context. Entonces el primer paso es crear una clase llamada MainContext.as

En esta clase replantearemos (override) el método startup adentro del cual haremos el mapeo de objetos. Esto quiere decir que aquí colocaremos todas las definiciones de vistas, clases, singletons, servicios, comandos y mediadores que existen en nuestra aplicación.

Para mapear objetos en el contexto solo hay que definir que tipo de mapeo haremos. Existen varios tipos, nosotros utilizaremos los 3 mas ocupados.

• Para mapear los datos de Modelos y de Servicios utilizaremos injector
• Para los componentes visuales y sus mediadores utilizaremos viewMap
• Y por ultimo para registrar eventos con comandos se harán con commandMap.

Para avanzar en este tutorial solamente necesitamos mapear el la vista y el mediador, mas adelante mapearemos un comando, a un modelo y a un servicio.

Una vez lista nuestra clase que extiende el Context [nota: puede haber varios contextos] ahora solo hay que iniciarla adentro de nuestra aplicación flex o flash.

Ya que creamos la clase MainContext la podemos iniciar desde nuestra aplicación de lpa siguiente manera.

La vista

Adentro de RL, la vista se separa en 2 componentes. La clase MXML y la clase Mediadora. Esto quiere decir que toda la implementación del diseño quedara adentro del paquete components con extensión mxml y la lógica de comportamiento de ese componente quedara guardada en el mediador.

¿Por que? la razón es por que así desacoplamos mas los cambios. El programador puede refactorizar un componente en cuanto a su diseño sin tener que afectar el comportamiento de este.

Adentro de la vista podemos acoplar los comportamientos de efectos, estilos, y skins. Meras cuestiones visuales podrán ser modificadas sin tener que modificar nuestra clase que actuara de mediador.

En nuestra aplicación, lo único que tenemos que hacer es un componente para guardar los datos recibidos en un Datagrid de paso aqui la sintaxis para el Spark y un boton que se llamara obtenerButton que sera el encargado de ejecutar el script en el mediador.

Mediadores

Son opcionales, pero los mediadores en el framework es una practica que te hará mejor amante... bueno no tanto así, pero si te dará mas tiempo para practicar ; )

Están basados en un patrón, y su función es comunicación con los otros actores del framework (Modelos, Servicios y Comandos) y tus componentes (vistas, clases mxml, renderers y módulos, clases visuales en AS). Estos tienen la capacidad de inyectar como propiedades otras clases (en ocasiones ya iniciadas por el framework) como servicios y/o modelos y también registrar eventos/señales de nuestras vistas para un trabajo con los actores del framework, haciendo un flujo de trabajo mas separado y fácil de configurar.

En nuestro ejemplo vamos a realizar la inyección de nuestro componente visual a través de un metatag personalizado llamado [Inject] y declarando una variable publica (vital que sea publica) y colocando el nombre de su clase para saber que actor de nuestro framework vamos a inyectar. Esta variable NO la vamos a iniciar ya que Robotlegs se encargara de ese trabajo y lo hará una vez por cada evento startup que sea distribuido.

Inmediatamente después vamos a iniciar el trabajo del mediador con su componente visual. Esto lo haremos mediante la sobre escritura del método onRegister y adentro podremos colocar los eventos que nuestro componente gráfico (o sus elementos) despachara(n).

El ultimo articulo podremos ver como integrar a los mediadores con comandos, servicios y modelos. Este articulo lo encontraras disponible dentro de poco aquí en RIActive.

Como programadores Flex, será útil aprender este tipo de técnicas acerca de este marco de trabajo que me ha hecho no ensuciar mi código a la hora de arreglar esos bugs (muchas veces cambios del cliente)  U_U

Este es el primer articulo de 3 que te enseñaran a usar este framework. Puedes esperar el siguiente (Robotlegs 102) muy pronto.

• RL 101 (Introducción)
• RL 102 (Contexto, vista y mediadores)
• RL 103 (Comandos, servicios y modeos)

¿Robotlegs?

Desde octubre del año pasado se leían algunos comentarios de Robotlegs (RL), la cuestión que todo mundo admiraba eran 2 cosas, la capacidad de separar código (haciendo referencia al patrón MVCS) y la inversión de control (basada en inyección de dependencias con swfsuspenders)

Robotlegs, es un framework muy estable y con una gran capacidad de crecimiento. Una de sus grandes ventajas es que no extiende el Flex Framework, por lo tanto puede ser usado en aplicaciones Flex o en aplicaciones/animaciones con Flash. La gran capacidad que tiene de integración y lo fácil de su configuración es lo que llama la atención a la mayoría cuando lo conocen.

Modelo Vista Controlador +S

El modelo MVC es muy conocido en el mundo de desarrollo, es una buena practica en el momento de arreglar aplicaciones viejas o darle el soporte a las grandes. Si no me creen vean la siguiente imagen de SeanTheFlexGuy.

Como experiencia les puedo compartir que en un proyecto en donde los cambios son inesperados, la separación del modelo y los servicios es algo mágico, ya que el modelo se encarga solamente de manipular los datos con los que ya contamos, y los servicios y cualquier configuración quedan afuera de esa clase. Es realmente genial que el tratamiento de conexiones/datos queden desacoplados ya que como buena práctica, ellos solo emitirán eventos (o señales) a los demás actores del framework sin tener que saber en donde se encuentran los componentes que están a la escucha de estos eventos.

Este framework esta desacoplando al nivel de colocar los servicios a en un paquete aparte de tus clases. En las mejores prácticas te explican que es una clase muy parecida al comportamiento de los modelos, pero estos en especial no guardan datos, solo hacen conexiones al mundo exterior u ofrecen servicios para la aplicación como parseo de datos, generación de imágenes o algún otro tratamiento a datos que se pudiera dar adentro de la aplicación.

Aquí el diagrama oficial de Robotlegs

Fue difícil entenderlo, (por que no lo aclara ¬_¬’) pero (si no me equivoco) las lineas punteadas son los eventos/señales (emisión y recepción) y las lineas continuas son inyecciones de dependencias. Lo demás queda claro con el flujo y las leyendas.

• Cuando: 12 de Mayo 2010.
• Donde: http://experts.na3.acrobat.com/springio/.
• Hora: 7 pm hora de México D.F, 2:00 am de España.

Algunos de los tópicos que se cubrirán en el evento son:
• New Features in Adobe® Flash® Builder™ 4
• Building Multi-Screen Applications with the Adobe® Flash® Platform
• Adobe® Flash® Catalyst™ for Developers
• What's New in Adobe® Flash® Builder™ 4 for Java Developers
• What's New in Adobe® Flash® Builder™ 4 for PHP Developers
• Adobe® Flash® Builder™ 4 and Adobe® ColdFusion® 9
• Creating Sexy Applications with the Adobe® Flash® Platform: Designer-Developer Workflow
• Adobe® Flash® Builder™ 4 for Adobe® Dreamweaver® Users
• Building Desktop Applications with Adobe® AIR® 2.0
• Advanced Features in Adobe® Flex®

El registro al evento no está abierto aun, pero puedes dejar tu correo electrónico en el sitio para que te notifiquen en cuanto las inscripciones estén abiertas.

Creo que esté será un muy buen evento tanto para conocer la tecnología como para aprender las nuevas características de productos nuevos.

Nos vemos en el Adobe Developer Week y... Happy Coding!!!

Sergio Brito AKA @yacaFx

Este tutorial está pensado para seguirse como receta de cocina y que en pocos pasos estén divirtiéndose trabajando con esta poderosa forma de conectar Flex con PHP.

Requisitos:

• Tener ZEND Framework en su última versión y completo. La razón de tenerlo completo radica en que cuando yo quise instalarlo y solo baje el paquete de ZEND_AMF me arrojaba constantemente errores de librerías requeridas. Para evitarnos eso vamos a conseguir toda la librería de Zend para no tener problemas. http://framework.zend.com/download/overview
• Un editor de texto plano o una IDE para PHP. http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/galileo/SR1/eclipse-php-galileo-SR1-win32.zip
• Adobe Flex Builder 3. http://www.adobe.com/products/flex/
• Un servidor http que tenga el motor de ejecución PHP compatible con la versión de  Zend (Yo use wamp). http://www.wampserver.com/en/download.php

Contenido:

1. Organizar es buena idea: Preparando a Zend.
2. MiClasePHP.php: Creando una clase personalizada de PHP
3. El marco de la puerta: Creando a Zend_AMF_Server
4. La perilla de la puerta: Configurando Flex
5. Con quien voy a hablar?: RemoteObject y la configuraciones.
6. @Flex: “¿Donde estas @PHP?”. @PHP: “Aquiiiiii!!”

Introducción

Necesitas hacer llamada de una función que se encuentra en una clase PHP desde Flex y te preguntas ¿Cómo logro eso? Una de las diversas respuestas es: Zend_AMF

Zend_AMF es un paquete con el cual lograras hacer llamadas desde Flex a PHP. Zend es un framework para PHP muy potente, por lo tanto cuando el uso de los datos es extremo, esta es la mejor solución.

Preparando a Zend

Ok, ahora vamos con el primer paso operativo de esta receta.

En una carpeta del servidor http, colocaremos la carpeta llamada “Zend” la cual contendrá todo el framework que hemos bajado. Dentro del server colocaremos una carpeta que llamaremos “lib” la cual contendrá todas nuestras clases personalizadas.

Y por ultimo crearemos un archivo “zend_amf_server.php” que será el Zend_AMF_Server.

Creando una clase personalizada de PHP

Adentro de la carpeta “lib” crearemos una clase de PHP llamada “ClasePersonal” que tenga un método llamado “holaMundo” al cual se le pueda pasar un argumento de tipo string para ejecutar el ejemplo.

<?php
class ClasePersonal{
public function holaMundo($mensaje = 'Hi'){
$date = getdate();
return 'Hola desde PHP, Flex dijo: '. $mensaje .' el dia '. $date["seconds"];
}
}
?>

Como pueden observar es una clase cualquiera, no tiene alguna implementación especial o algo por el estilo.

Creando a Zend_AMF_Server

En lo personal ésta fue la parte más angustiante de todas, ya que por más que hacia copy-paste de código que obtenía en el sitio de Zend_AMF y de otros tutoriales que encontré, no salía correctamente y era porque a todos o les faltaba alguna línea u otros tenían una entrega del server distinta. La última línea de código de este PHP es la más importante de todas.

“zend_amf_server.php” será el equivalente a “gateway.php” que utiliza AMFPHP. Es la puerta de acceso al server de Zend_AMF.

Este será un pequeño archivo PHP que dará el acceso a Flex. En 6 puntos a seguir estará configurado.

Primero incluimos la librería Zend.

require_once 'Zend/Amf/Server.php';

Segundo incluimos a nuestra clase personalizada.

require_once 'lib/ClasePersonal.php';

Tercero instanciamos al Zend server.

$server = new Zend_Amf_Server();

Cuarto le enviamos a nuestro nuevo server la clase personalizada.

$server->setClass('ClasePersonal');

Quinto establecemos el método de entrega del server.

echo $server->handle();

Y como producto obtendremos un “zend_amf_server.php” con las siguientes líneas de código:

<?php
require_once 'Zend/Amf/Server.php';
require_once 'lib/ClasePersonal.php';
$server = new Zend_Amf_Server();
$server-&gt;setClass('ClasePersonal');
echo $server-&gt;handle();
?>

<mx:Nota>Sí tienen muchas clases de PHP y no tienen deseos de incluirlas al script de PHP y luego enviarlas a Zend. Pueden eliminar el segundo punto y además modifican el quinto por la siguiente línea de código antes del método de entrega del server.

$server->addDirectory('include/services/');

</mx:Nota>

Configurando a Flex

Para empezar debemos tener un proyecto de Flex abierto y crear un nuevo archivo con extensión XML adentro de la carpeta “src”.

Al siguiente archivo lo llamaremos “services-config.xml” (sin comillas) y será el encargado de decirle a Flex en donde se encuentra nuestro “zend_amf_server.php”

Este archivo es un documento en formato XML, dentro del cual colocaremos dos cosas importantes: La ruta del “zend_amf_server.php” y el nombre asignado a este canal.

En mi caso el XML contendrá lo siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<services-config>
<services>
<service id="zend-service" messageTypes="flex.messaging.messages.RemotingMessage">
<destination id="zend">
<channels>
<channel ref="zend-endpoint"/>
</channels>
<properties>
<source>*</source>
</properties>
</destination>
</service>
</services>
<channels>
<channel-definition id="zend-endpoint">
<endpoint uri="http://localhost/zend_amf_server.php"/>
</channel-definition>
</channels>
</services-config>

Como podrán ver, el XML tiene 2 puntos críticos que son los nodos “endpoint” y “destination” dentro de los cuales se especifica la ruta del zend_amf_server y el nombre que se le asignara para identificarlo dentro de Flex.

Una vez creado y guardado el XML nos vamos a nuestro proyecto y damos clic derecho>propiedades>Flex Compiler y en donde dice “Aditional compiler arguments” (Argumentos de compilación adicionales) le agregamos el texto  -services "services-config.xml" (con los guiones y las comillas) y aceptamos los cambios con el botón Ok.

RemoteObject y las configuraciones.

Ahora sí, le daremos un nombre a cada clase que necesitemos. Claro esto también se puede hacer en AS pero aquí les va el ejemplo en MXML.

Primero crearemos la etiqueta RemoteObject.

<mx:RemoteObject id="ClasePersonal" destination="zend" source="ClasePersonal" showBusyCursor="true" fault="onConexError(event)">

Aquí una pequeña lista de los atributos que necesitan y para qué sirven:

Id: El identificador con el que llamaran a la clase.

Source: El nombre de la clase PHP que vamos a llamar.

Fault: La función que arrojara para todos los métodos de esa clase, cuando exista algún error.

ShowBusyCursor: Es para que se muestre ocupado el mouse cuando está haciendo la llamada a los servicios PHP hasta que retorne algún valor/error.

Destination: Recuerdan que en el XML llamado “services-config.xml” tenía un nodo llamado destination, pues el valor del atributo de ese nodo es el que va aquí y sirve para indicarle a este RemoteObject a donde hay que enviar todas las consultas.

Una vez que ya colocamos la instancia de RemoteObject por clase PHP, pasaremos a indicar cuáles son los métodos de la clase PHP y como los llamaremos en Flex.

<mx:method name="holaMundo" result="onResultHolaMundo(event)"/>

Atributos de la etiqueta Methods:

Id: El nombre del método de la clase PHP.

Result: la función de Flex, la cual será llamada cuando exista regreso en un método de la clase PHP

Fault: Es la función de Flex que será llamada cuando exista un error de conexión en especifico para ese método de la clase PHP. Este atributo es opcional ya que en la etiqueta RemoteObject definimos una función de error para todos los métodos de esta clase.

<mx:Nota>Estos pasos se tendrán que repetir para cada método y para cada clase de PHP.</mx:Nota>

<mx:Nota>No olviden realmente definir las funciones en AS que son los resultados de las llamadas y las que son invocadas por errores.</mx:Nota>

Llamadas a las clases y los métodos.

Bueno, con esto se ha terminado todas las configuraciones. Ahora nos enfocaremos a terminar el tutorial, con un pequeño ejemplo.

A nuestra aplicación vamos a crearle una función de nombre “init” que estará disponible para el evento creationComplete de la aplicación, está se encargara de hacer la llamada al método de la clase PHP.

private function init():void{
ClasePersonal.holaMundo("Hola PHP");
}

Como nosotros ya definimos la función de AS que será la que responda nuestra llamada al método de la clase PHP, solo haremos que en un Label nuevo, le asigne el texto que nos regreso el método de PHP y después lo instanciaremos en el escenario de Flex.

private function onResultHolaMundo(event:ResultEvent):void{
var etiqueta:Label = new Label();
etiqueta.text = event.result.toString();
this.addChild(etiqueta);
}

Con esta parte estará completo nuestro MXML. Obteniendo así el script final.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" creationComplete="init()">
<mx:Script>
<![CDATA[
import mx.controls.Alert;
import mx.rpc.events.ResultEvent;
import mx.controls.Label;
import mx.rpc.events.FaultEvent;
private function onConexError(event:FaultEvent):void{
<em>//Agregado para que arroje el error.</em>
Alert.show(event.fault.faultDetail, event.fault.faultString);
}
private function onResultHolaMundo(event:ResultEvent):void{
var etiqueta:Label = new Label();
etiqueta.text = event.result.toString();
this.addChild(etiqueta);
}
private function init():void{
ClasePersonal.holaMundo("Hola PHP");
}
]]>
</mx:Script>
<mx:RemoteObject id="ClasePersonal" destination="zend" source="ClasePersonal" showBusyCursor="true" fault="onConexError(event)">
<mx:method name="holaMundo" result="onResultHolaMundo(event)"/>
</mx:RemoteObject>
</mx:Application>

Comentarios y posibles problemas.

<mx:posibleproblema>Recuerden configurar su aplicación Flex como una aplicación de servidor PHP, ya que la seguridad de Flash Player no les permitirá acceder a un servidor http sino está corriendo bajo el mismo dominio, y si necesitan hacer llamadas entre dominios necesitaran un XML llamado “domain-config.xml” si lo requieren postéenlo y se los proporciono.</mx:posibleproblema>

<mx:comentario>Yo me he fijado que la primera vez que se hace llamada a algún método de nuestras clases, lo hace 2 veces y es porque en la primera establece la conexión y en la segunda ya hace la llamada. En la segunda llamada a algún método de la clase PHP ya no hará esto.</mx:comentario>

Asi les debe quedar la carpeta de su servidor al final. (Ahora ya tiene la version de depuracion de Flex porque lo creamos como una aplicacion de server PHP)

Lo demás lo pueden colocar con todo gusto y les apoyare con mi poca pero insistente experiencia xD

Hasta pronto, nos leemos en mi siguiente post. Byte.

Gracias a @eternalmoon_ por su participación en la corrección de este tutorial.

¿Quieres estar alli?

Solo tienes que hacer un video con la tematica ¿Y para ti que es Flash?

Dicho video no debe durar mas de 10 segundos y deberas subirlo al grupo en facebook y en You Tube etiquetandolo con el texto "latinflashtour" una vez que este arriba comparte la url a travez de twitter y claro deberas agregar el tag #latinflashtour o twitername @latinflashtour y seguirnospara que podamos ver tu video!

Los ganadores seran los 5 videos más originales y la fecha limite es este viernes!!

Solo quedan 5 lugares!!!!
So... Are you in??

Latin Flash Tour MX!!!

Latin Flash Tour