... dans le nouveau Service Browser accessible par le répértoire 'browser', il est désormais possible d'appeler les méthodes directement dans le navigateur, plus besoin de créer un fla en deux minutes, créer un service puis appeler la méthode distante, on développe notre service distant puis on se rend dans le service browser et on teste !

Ce système ressemble fortement au mode de fonctionnement de services web (WebService) développés en .NET où Visual Studio génère un formulaire de test ce qui permet au développeur d'appeler la méthode et de voir ce qu'elle renvoit directement dans le navigateur. En cliquant sur le service voulu dans le service browser, on obtient un listing des méthodes disponibles, la possibilité de générer du code pour ARP d'Aral Balkan.

Une autre fonctionnalité améliorée dans cette version conçerne la propriété methodTable, tout le monde se rend compte qu'il est très pénible de développer son service avec cette propriété methodTable, où il convient de définir toutes les méthodes presentes dans le service, cette propriété sert à renseigner les attributs des méthodes autrement dit à signer vos méthodes. C'est ici que vous régissez les droit d'accès, le type de retour etc, désormais à partir du service Browser vous pouvez générer un fichier PHP contenant votre 'methodTable', il suffira d'ajouter : 

include ("InvitesManager.methodTable.php");
dans le constructeur du service pour l'utiliser. Ainsi lorsque vous ajoutez une méthode dans votre service, il suffit de se rendre dans le Service Browser regénerez le fichier PHP 'methodTable" et c'est tout :) Cette fonctionnalité été presente dans la version 1.1 mais était moins simple à utiliser.

Pour ceux qui ne connaissent donc pas ce système de fichier methodTable généré dynamiquement, comment allez vous signer vos méthodes desormais ? Et bien à la javadoc en rajoutant au dessus de chaque méthode un bloc de commentaire contenant chaque attribut : 

    *  @desc
    * @access (set to remote to export a class)
    * @roles (comma-separated)
    * @instance
    * @returns
    * @pagesize

En production, il faudra copier le code methodTable généré par le Service Browser et le coller en dur dans le constructeur pour des questions de performances.

Le poids du dossier amf-core a été réduit de 40%, et Patrick Mineault a amélioré le fonctionnement de la debuggateway une nouvelle passerelle à utiliser en phase de développement permettant de renvoyer les erreurs fatales PHP au sein de l'évènement onStatus de votre PendingCall, ah je ne vous ai pas parlé de cela ?

Avant AMFPHP 1.1 lorsque vous aviez une erreur dans votre service, par exemple un oubli de définition de méthodes dans la methodTable ou bien une erreur au niveau du nombre de paramètres passés, l'évènement onStatus était déclenché et vous renvoyait l'erreur, mais que se passait il lorsqu'une erreur fatale côté PHP survenait ?

Et bien votre service était incapable de répondre à Flash et du coup plus aucun retour, dans le meilleur des cas un NetConnection.Call.BadVersion s'affichait dans votre NetConnectionDebugger, ce qui laissait penser à une erreur de parse.

Cela fait partie du passé car en pointant non pas sur la 'gateway.php' mais sur la 'debuggateway.php' et bien les erreurs fatales déclencheront l'évènement onStatus et vous pourrez voir sans problème à quel endroit vous avez fait une erreur dans le service PHP au sein de votre appli Flash, très utile donc en phase de debug, il ne faudra pas oublier de repasser sur la gateway par défaut en production là encore pour des questions de performances. Je vais poster le prochain tutoriel Remoting traitant du débuggage avec AMFPHP 1.2 la semaine prochaine, j'attendais cette version pour pouvoir parler du Service Browser et de la debuggateway vos nouveaux amis niveau debugging :)

C'est ici que ça passe