Voici un tutoriel qui va être découpé en plusieurs parties pour comprendre le développement d'un RIA. Je ne dis pas détenir la vérité, mais je vous fais part de mon approche et de ma façon de travailler lors de développements de grosses applications.

 

En ce qui concerne les choix des technologies, nous allons utiliser PHP (car c'est le langage le plus couramment utilisé) pour l'interaction avec le serveur en se servant du Zend FrameworkFlex 3 pour le côté client (interface), et MySQL pour la base de données.

 

Vous allez me dire, pourquoi utiliser Flex 3 et non pas Flex 4 (qui vient tout juste de sortir). Alors ma réponse est toute simple, Flex 4 vient tout juste de pointer le bout de son nez, les applications développées avec le sdk de Flex 3 sont nombreuses et les entreprises ne sont pas encore prête à tout changer, Flex 3 à encore quelques années devant lui. Bien entendu nous reviendrons sur le dernier sdk dans un prochain tuto.

 

Dans un premier temps, nous allons voir comment découper et organiser notre application coté Flex, utilisation du modèle MVC, pour ensuite voir comment déployer le Zend Framework pour qu'il puisse accueillir notre application Flash, et nous terminerons par les interactions entre les différentes parties.

 

Rappel sur le MVC

Avant d'aller plus loin, il est bon de se faire un petit rappel. Sans s'étaler sur le sujet (de nombreux articles sur le web en parlent), le MVC (ou modèle-vue-contrôleur) est une architecture permettant de développer plus facilement et plus proprement une application, tout en la rendant réutilisable.

 

Le modèle

Les modèles sont tout simplement les données. Ces classes ne comportent que les déclarations de celles-ci et les accesseurs. Bien entendu nos modèles doivent tous être Bindable pour qu'un changement sur une des valeurs soient directement repercuté sur les vues.

package com.mvc {
    import flash.events.EventDispatcher;
    import flash.events.IEventDispatcher;
    [Bindable]
    public class Model extends EventDispatcher {
	
        public function Model(target:IEventDispatcher=null) {
            super(target);
        }
    }
}

 

Comme tous nos modèles doivent avoir la même structure, nous allons créer une classe Model dont devra étendre tous les modèles de notre application. Celle-ci doit étendre de la classe EventDispatcher pour pouvoir bien évidement distribuer des évènements.

 

Le contrôleur

Le contrôleur est en fait le chef d'orchestre. C'est lui qui va demander les informations au modèle (ou attendre la propagation d'évènements) pour les envoyer à la vue et traiter les données si besoin est. Pour ce faire, le contrôleur doit obligatoirement connaître sa vue et son modèle. Nous avons donc deux attributs dans notre classe Controller.

 

Notre classe disposera d'une méthode _creationCompleteHandler() qui pourra être surchargé si besoin, et qui sera appelée lors de l'évènement creationComplete de notre vue. Bien entendu, tous nos contrôleur devront entendre de celle-ci.

 

Par la suite dans nos contrôleurs, toutes les méthodes pouvant être appelées par la vue devront bien évidement être en publics, et les autres en privées. Si une donnée doit être accédée depuis la vue (pour un dataProvider par exemple) la vue devra appeller les accesseurs présent dans le contrôleur, qui eux se chargeront de récupérer (voir de traiter) les données présent dans le modèle. Car la vue ne doit jamais directement appeler le modèle. C'est le contrôleur qui se charge de tout réguler.

 

La méthode la plus propre consiste à utiliser des évènements, qui vont permettre, lors de la distribution de l'un d'eux par le modèle, de rafraichir la vue. Nous verrons cela plus en détails lorsque nous verrons les interactions entre Flash et PHP.

package com.mvc {
    import com.mvc.Model;
    import flash.events.Event;
    import mx.events.FlexEvent;

    public class Controller {
		
        [Bindable]
	public var view : Object;
		
        [Bindable]
	protected var _model : Object;
		
	public function Controller() {}
		
	public function _creationCompleteHandler(event:FlexEvent):void { }

    }
}

 

La vue

La vue, quand à elle, ne s'occupe vraiment que de la partie affichage. Elle dispose tout de même d'une référence vers une instance d'un contrôleur.

 

Je souhaite également faire une classe View pour des besoins futurs comme par exemple si nous avons besoin d'utiliser SWFAddress, des méthodes sont nécessaires pour toutes nos vues. Il est donc préférable de passer par un classe Model, même si cela n'est pas primordiale.

 

J'ai volontairement laissé la méta donnée ResourceBundle qui va permettre d'utiliser la gestion des langues plus tard dans l'application. La classe hérite de la classe Box, mais celle-ci pourrait très bien être la classe Canvas, ou tout autre.

package com.mvc {
    import mx.containers.Box;

    [ResourceBundle("i18n")]
    public class View extends Box {
	
	public function View() {
   	    super();
        }

    }
}

 

Et voici à quoi devrait ressembler une des vues de l'application

< ?xml version="1.0" encoding="utf-8"?>
< mvc:View xmlns:mx="http://www.adobe.com/2006/mxml" 
	xmlns:controllers="fr.controllers.*" 
	xmlns:mvc="com.mvc.*"
	creationComplete="controller._creationCompleteHandler(event)" >
		
	< controllers:NewsController id="controller" view="{this}"/>
	
	...

 

Conclusion

Cette première partie est là pour poser les fondations de l'application. On a pu voir les différentes classes d'abstraction qui seront utilisées.

Dans la prochaine partie, nous verrons comment déployer le Zend Framework pour qu'il puisse accueillir une application Flash, en utilisant zend_amf pour les différentes interactions.