Discussion :

[clem_alain]

Bonjour,
Lorsque je sélectionne un locataire, je récupère son id, je lance une requête et je récupère l'objet locataire dans lequel il y a notamment l'id_proprietaire
Voici le code du contrôleur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
angular.module('appLocations').controller('locataireCtrl', ['$scope', '$routeParams', 'LocationsRest', '$location', function ($scope, $routeParams,LocationsRest, $location) {  
        var loc = LocationsRest.getLocataire().get({id: $scope.id});
        $scope.locataire = loc; // pour la vue
        loc.$promise.then(function(data){
            $scope.LocData=data; // pour pouvoir manipuler les données retournées
            console.log(data); // pour voir si tout est OK
        });
        var idProp = locData.id_proprietaire;
        $scope.selectedOption= LocationsRest.getProprietaire().get({id: idProp});;
    }]);

Ce code ne fonctionne pas car il n'y a rien dans idProp et je ne comprends pas pourquoi !
Précisions :
1 - le getLocataire() fonctionne parfaitement, pour preuve $scope.locataire il est parfaitement visible dans la vue !
2 - lorsque je fais du débogage loc est présenté comme : Loc = (Resource)Resource, idem pour $scope.locataire

Fondamentalement je ne vois pas la différence entre mon code et celui qui est proposé dans la doc AngularJS à cette adresse :
https://docs.angularjs.org/api/ngResource/service/$resource en bas de la page.

Merci d'avance pour votre aide,
P.S. : Marco46, je sais que mon code n'est pas vraiment correct, mais pour le moment je suis en phase d'apprentissage et donc je ne peux pas me permettre une trop grand complexité ;-)

[Marco46]

La ligne qui pose problème :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var idProp = locData.id_proprietaire;

locData n'est déclaré nullepart, donc il est undefined. Donc idProp est undefined.

Je te conseille d'utiliser $http plutôt que $resource, c'est beaucoup plus clair pour apprendre. Personnellement je n'utilise pas $resource, je le trouve extrêmement fouillis à vouloir mélanger accès au données et modèle. Je préfère utiliser Restangular ou directement $http.

[clem_alain]

Bonjour,
En fait c'est un problème de recopie, la ligne réelle était :
var idProp = $scope.locData.id_proprietaire;

J'ai essayé aussi de passer par une variable locale :
var locData;
...
LocData=data;

Mais rien n'y a fait.
du coup j'ai laissé tomber $resource et jai essayé aussi cela avec $http :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
angular.module("appLocation").factory('dao', ['$http', 'Config', '$q', function ($http, Config, $q) {
        var reponse = '';
        return {
            getLocataire2: getLocataire2, // version2
            getLocataire: getLocataire, // version1
        };
        function getLocataire2(id) {
            var url = Config.urlServeur + '/getLocataire/' + id;
            $http.get(url).success(function (response) {
                reponse = response;
            });           
            return reponse;
        }
 
        function getLocataire(id) {
            var differe = $q.defer();
            var url = Config.urlServeur + '/getLocataire/' + id;
            var promise = $http.get(url);
            promise.then(success, failure);        
            return differe;
 
            function success(response) {
                differe.resolve(reponse.data);
            }
            function failure() {
                differe.resolve("erreur");
            }
        }
    }]);

Bon je suis d'accord que la v2 n'est pas très orthodoxe, mais au final c'est encore celle qui "fonctionne" à peu près !
Dans le contrôleur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
    controleurs.controller('LocataireCtrl', ['$scope', '$routeParams', 'OeuvresRest', '$location', 'dao', function ($scope, $routeParams, LocationRest, $location, dao) {
        $scope.locataire = LocationRest.getLocataire().get({id_locataire: $scope.locataire});
        var locataire =  dao.getLocataire2($routeParams.id);
        $scope.proprietaires = LocationRest.listeProprietaires().query();
        if ($scope.id_locataire)
            $scope.selectedOption = LocationRest.getProprietaire().get({id_proprietaire: locataire.id_proprietaire});
	    . . .

Cela ne fonctionne pas, enfin pas vraiment, la première fois je n'obtiens rien, mais si je relance une seconde fois c'est OK et les fois suivantes c'est OK, mais ce n'est pas satisfaisantcomme résultat.
Du coup j'ai essayé ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
    controleurs.controller('LocataireCtrl', ['$scope', '$routeParams', 'OeuvresRest', '$location', 'dao', function ($scope, $routeParams, LocationRest, $location, dao) {
        $scope.locataire = LocationRest.getLocataire().get({id_locataire: $scope.locataire});
        var locataireP =  dao.getLocataire($routeParams.id); // On récupère une promesse
	var locataire;
	locataireP.promise(function(response){locataire=response;}); // on résout la promesse et j'ai aussi essayé locataireP.promise.then(function ...
        $scope.proprietaires = LocationRest.listeProprietaires().query();
        if ($scope.id_locataire)
            $scope.selectedOption = LocationRest.getProprietaire().get({id_proprietaire: locataire.id_proprietaire});
	    . . .

Toujours rien bien que l'analyse dans le navigateur montre dans les deux cas que le serveur Rest a bien envoyé le JSON !
Je pédale dans la semoule :-(
Merci pour l'aide

[Marco46]

Faut rester simple. Résout la promesse dans ton contrôleur. Aucun intérêt de le faire dans ton service.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
function getLocataire2(id) {
    var url = Config.urlServeur + '/getLocataire/' + id;
    return $http.get(url);           
}

Tout simplement.

Et dans ton contrôleur tu résouts la promesse :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
function locataireCtrl(dao, $routeParams) {
 
    var vm = this;
 
    dao.getLocataire2($routeParams.id).then(function(data) {
        vm.data = data; // à toi de voir comment ça s'emboite, je ne connais ni le modèle renvoyé par ton WS ni les bindings de ta vue.
    });
}

L'implémentation que tu fais dans getLocataire() (la v1 donc) est bonne mais on ne fait ça que si l'on a du traitement à faire avant de renvoyer la promesse. Donc par exemple si tu as un service qui gère l'accès aux webservice, et un autre entre ce service et la vue. Dans ce service passe plat on va pouvoir exécuter des traitements permettant de modifier le modèle (par exemple) ou notifier d'autres services, etc ... dans ce cas on va résoudre la promesse, faire les traitements puis retourner une nouvelle promesse. C'est ce que tu as fait et je vois pas pourquoi ça fonctionnerait pas.

[clem_alain]

Bonjour,
Afin de mieux (tenter) de maîtriser l'outil AngularJs, je repars sur une application plus modeste (les employés et leur service) en me basant sur le célèbre employee/department d'Oracle.
J'ai suivi ton conseil de travailler avec $http, le contrôleur ci-dessous fonctionne parfaitement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
controllers.controller('employeeCtrl', ['$scope', 'EmployeesRest', '$routeParams', '$location', function ($scope, EmployeesRest, $routeParams, $location) {
        var employeeR = EmployeesRest.getEmployee($routeParams.id);
        employeeR.success(function(data){
             $scope.employee = data;
             EmployeesRest.getDepartments().success(function(data){$scope.departments = data;});
             if ($scope.employee_id)
                EmployeesRest.getDepartment($scope.employee.department_id).success(function(data){$scope.selectedOption = data;});
          });
    }]);

Et voici les services appelés :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
angular.module('app').factory('EmployeesRest', ['$http', 'Config', '$resource',
    function ($http, Config, $resource) {
        var employeesRest = {
            getEmployees: getEmployees,
            getEmployee: getEmployee,
            getDepartments: getDepartments,
            getDepartment: getDepartment
        };
        return employeesRest;
 
        function getEmployees() {
            var url = Config.urlServer + Config.urlgetEmployees;
            return $http.get(url);
        };
        function getEmployee(id) {
            var url = Config.urlServer + Config.urlgetEmployee + id;
            return $http.get(url);
        };
        function getDepartments() {
            var url = Config.urlServer + Config.urlgetDepartments;
            return $http.get(url);
        };
        function getDepartment(id) {
            var url = Config.urlServer + Config.urlgetDepartment + id;
            return $http.get(url, {id: id});
        };
    }]);

Mon problème est le suivant :
Comment arriver à manipuler des données issues d'une Promise en dehors de la fonction success ?
Avec ce que j'ai compris des promise il y a antinomie entre le traitement synchrone séquentiel classique du type : je récupère des données que j'utilise pour accéder à d'autres données et les promises qui consistent à lancer une demande qui sera résolue plus tard et pendant ce temps je continue le déroulement séquentiel de l'application.
J'en arrive à me demander si ma question a bien un sens !
Merci pour vos lumières

[Marco46]

Comment arriver à manipuler des données issues d'une Promise en dehors de la fonction success ?

Tu ne peux pas !

Le principe de la promise c'est que c'est une promesse, tu ne sais pas quand ça sera exécuté, donc tu ne sais pas si ça sera vraiment exécuté ou non. Donc il y a forcément une séparation success / error pour définir ce que tu vas exécuter si la promesse est réellement exécutée ou si il y a une erreur.

Résoudre des promesses dans les contrôleurs Angular est une pratique extrêmement courante.

[clem_alain]

Bonjour,
Ma conclusion était donc la bonne !
Cela réduit quand même considérablement le terme Application dans SPA, en effet étant donné que les promises constituent le coeur de cette technologie, la partie "métier" s'en trouve grandement affectée, en fait on serait plutôt dans une IHM rapide et efficace, mais dès qu'on veut faire des traitements plus conséquents il faut retourner côté serveur.
De plus le Single Page me paraît bien usurpé, en effet si on reste sur la même page stricto sensu, on charge beaucoup de vues qui ne sont rien d'autre que des pages html !
Au fond, on est pas loin de la technique des frames qu'on utilisait il y a quelques années, non ?
Cordialement,

[slim]

Au fond, on est pas loin de la technique des frames qu'on utilisait il y a quelques années, non ?

Rien à voir...
est ce que tu as déjà fais un "show code source" sur une page contenant des frames et sur le rendu d'une SPA ?
Fais-le et fais un diff, tu verra que c'est pas vraiment pareil...

Cela réduit quand même considérablement le terme Application dans SPA, en effet étant donné que les promises constituent le coeur de cette technologie[...]

Les promesses, c'est plutôt pour l'asynchronisme. Rien à voir avec les SPA. Tu peux tout à fait utiliser ce concept et ne pas utiliser de promesses... (mais c'est moche et c'est dommage).
Les promesses existent dans JQuery aussi... et JQuery n'est pas un framework et permet encore moins de créer des SPA.

[clem_alain]

Bonjour,
> Rien à voir...
Bien sûr ma conclusion était un peu abrupte, mais en vue externe, je ne vois pas vraiment la différence. Tout ce que j'ai pu lire jusqu'à présent sur ce concept de SPA était centré sur le fait qu'on restait sur la même page. Force est de constater que dès qu'on va un peu plus loin que les exemples rapides présentant cette technologie et qu'on met en oeuvre un début de réelle application, on passe son temps à télécharger des morceaux de pages qui peuvent vite devenir conséquentes.

> Les promesses, c'est plutôt pour l'asynchronisme. Rien à voir avec les SPA
En tout état de cause l'accès aux données situées sur un serveur RestFul se fait via l'asynchronisme et apparemment uniquement comme ça, donc le raccourci SPA => Promise n'est pas si abusif que cela, même si c'est effectivement un peu réducteur.
Au stade où j'en suis de mon appréhension de cette technologie , l'idée que je m'en fais est qu'elle peut trouver sa place dans certains cas sur une application Web classique, mais en aucun cas qu'elle puisse se substituer au développement "traditionnel", or c'est bien un peu le ton du discours ambiant, genre : "oubliez tout ce que vous avez appris et passez au SPA". Ce n'est d'ailleurs pas nouveau, j'ai (malheureusement) assez de bouteille pour avoir déjà entendu ce genre de discours bien souvent dans le passé, avec toujours les même suites, à savoir un apport complémentaire, jamais un remplacement ou basculement total. Je me souviens m'être fait avoir au début des année 90 avec l'IA (Intelligence Artificielle) et ses moteurs d'inférence ... Il fallait tout arrêter et passer à l'IA impérativement, tout le reste était à jeter à la poubelle, on sait ce qu'il en advint ! Et je ne parle pas du downsizing, des bases de données réparties and so and son on ...
Je suis assez curieux de nature et j'essaye de me confronter à ce qui sort et en particulier émerge dans le domaine, mais pour autant je tiens à conserver un esprit critique, voire septique.
Ceci dit si j'ai passé l'âge des emballements excessifs ;-), je reste toujours en éveil, voire suffisamment passionné pour me coltiner à l'innovation.

Bon, je suis en veine aujourd'hui.
Merci pour cet échange.

[Marco46]

Bien sûr ma conclusion était un peu abrupte, mais en vue externe, je ne vois pas vraiment la différence. Tout ce que j'ai pu lire jusqu'à présent sur ce concept de SPA était centré sur le fait qu'on restait sur la même page. Force est de constater que dès qu'on va un peu plus loin que les exemples rapides présentant cette technologie et qu'on met en oeuvre un début de réelle application, on passe son temps à télécharger des morceaux de pages qui peuvent vite devenir conséquentes.

En tout état de cause l'accès aux données situées sur un serveur RestFul se fait via l'asynchronisme et apparemment uniquement comme ça, donc le raccourci SPA => Promise n'est pas si abusif que cela, même si c'est effectivement un peu réducteur.

Tu mélanges un peu tout :

- L'asynchronisme est du à la nature même du web (stateless). RestFul est, entre autre, une architecture qui se cale sur le fonctionnement du web au lieu de chercher à simuler un environnement statefull que le web n'est pas. Ce n'est pas parce qu'une webapp est une SPA qu'elle utilise des promises. C'est parce qu'elle est construite sur http (qui est un protocole stateless).
- Le début SPA vs templating côté serveur. Dans les 2 cas tu auras des promises et de l'asynchronisme simplement dans un cas on gère tout côté client et dans l'autre on en gère une grosse partie côté serveur (ce qui est un non-sens en terme d'archi : gérer côté serveur ce qui relève du client, mais qui était obligatoire en l'absence des technos et des ressources adéquates. Les frameworks javascripts comblent ce manque.)

Au stade où j'en suis de mon appréhension de cette technologie , l'idée que je m'en fais est qu'elle peut trouver sa place dans certains cas sur une application Web classique, mais en aucun cas qu'elle puisse se substituer au développement "traditionnel", or c'est bien un peu le ton du discours ambiant, genre : "oubliez tout ce que vous avez appris et passez au SPA". Ce n'est d'ailleurs pas nouveau, j'ai (malheureusement) assez de bouteille pour avoir déjà entendu ce genre de discours bien souvent dans le passé, avec toujours les même suites, à savoir un apport complémentaire, jamais un remplacement ou basculement total. Je me souviens m'être fait avoir au début des année 90 avec l'IA (Intelligence Artificielle) et ses moteurs d'inférence ... Il fallait tout arrêter et passer à l'IA impérativement, tout le reste était à jeter à la poubelle, on sait ce qu'il en advint ! Et je ne parle pas du downsizing, des bases de données réparties and so and son on ...
Je suis assez curieux de nature et j'essaye de me confronter à ce qui sort et en particulier émerge dans le domaine, mais pour autant je tiens à conserver un esprit critique, voire septique.

Là aussi tu mélanges un peu tout, le choix entre webapp et appli traditionnelle (client lourd dans ton esprit je suppose ?) dépend de l'objecif de l'application. Si tu veux qu'elle soit accessible partout et sur tous les périphériques ton choix doit naturellement se tourner vers une webapp.
L'existence du SPA permet ce choix, ce qui n'était pas le cas avant. Elle est là la nouveauté. Et ce n'est pas une invention sortie du chapeau, c'est une évolution naturelle et logique des choses.

[clem_alain]

Bonjour,
Mais non, je ne mélange pas tout, tout au plus me suis-je mal exprimé ou ... ai été mal compris ;-).
J'ai à peu près 7 appli web à mon actif, dont trois encore "en vie", donc je sais "un peu" de quoi je parle.
Je dis simplement qu'à chaque fois on nous présente une innovation technologique comme le remède miracle et à chaque fois, cela fait sinon un joli flop, du moins on est loin d'un changement radical et en tout état de cause cela ne "révolutionne" en aucune manière l'état de l'art. On est comme toujours dans des glissements progressifs, ce qui est déjà pas mal et suffisamment dur à suivre. Il faut savoir garder raison, c'est par assez rageant de foncer dans une technologie d'investir beaucoup de temps et d'énergie pour s'apercevoir qu'en définitive elle a fait un feu de paille :-(
En ce qui concerne AngularJs, il y a en plus le fait que n'importe qui peut avoir accès au code source complet, ce qui pose quand même quelques problèmes, non ?
Je persiste et signe, il est peu probable qu'on puisse voir un jour des application web sérieuses uniquement basées sur AngularJs se généraliser comme se sont généralisées les applis web basées sur PHP, ASP.NET, JSP ...
Cela restera à mon sens soit une niche soit un complément très intéressant, par exemple les filtres dynamiques sont à cet égard bluffants.
Merci pour cet échange.

[Marco46]

Bonjour,
Mais non, je ne mélange pas tout, tout au plus me suis-je mal exprimé ou ... ai été mal compris ;-).
J'ai à peu près 7 appli web à mon actif, dont trois encore "en vie", donc je sais "un peu" de quoi je parle.
Je dis simplement qu'à chaque fois on nous présente une innovation technologique comme le remède miracle et à chaque fois, cela fait sinon un joli flop, du moins on est loin d'un changement radical et en tout état de cause cela ne "révolutionne" en aucune manière l'état de l'art. On est comme toujours dans des glissements progressifs, ce qui est déjà pas mal et suffisamment dur à suivre. Il faut savoir garder raison, c'est par assez rageant de foncer dans une technologie d'investir beaucoup de temps et d'énergie pour s'apercevoir qu'en définitive elle a fait un feu de paille :-(

Ca change fondamentalement l'architecture et ça s'appuie sur un précédent changement fondamental (Archi orientées services web).
On est loin, mais alors très loin du feu de paille. C'est un changement lent en lame de fond, une tendance lourde pour le futur.
Passer à côté de ça c'est pas possible.

En ce qui concerne AngularJs, il y a en plus le fait que n'importe qui peut avoir accès au code source complet, ce qui pose quand même quelques problèmes, non ?

C'est pas propre à Angular, c'est vrai pour toutes les webapp construites sur un framework javascript.
Tout le monde aura accès à une version buildée de ton code source, déjà ça fait une différence, ensuite oui évidemment tu ne peux mettre dans ton client que ce qui peut être public sans poser de soucis de sécurité. En dehors de ça où est le problème ?

Je persiste et signe, il est peu probable qu'on puisse voir un jour des application web sérieuses uniquement basées sur AngularJs se généraliser comme se sont généralisées les applis web basées sur PHP, ASP.NET, JSP ...

C'est déjà le cas. Tu n'imagines pas toutes les boites qui peuvent me contacter pour des missions de dev en AngularJS depuis un an. Et pas des petits trucs, des grandes comptes sur des projets durables dans le temps.
Actuellement je travaille sur un programme (une série de projets) de plusieurs dizaines de millions d'euros pour une institution très très connue.
L'archi c'est J2EE avec des webservice et le front du AngularJS partout.

C'est la nouvelle archi de référence pour faire des webapps.

Cela restera à mon sens soit une niche soit un complément très intéressant, par exemple les filtres dynamiques sont à cet égard bluffants.
Merci pour cet échange.

Tu te trompes lourdement. Le changement est déjà en cours. Les grands comptes adoptent cette techno les uns après les autres, donc la techno va être durable au moins pour la prochaine décennie.