Discussion :

[Welden]

Bonjour à tous,

Je poste ici dans le but d'avoir des avis de personnes plus compétentes que moi dans le développement d'applications web afin de m'orienter dans mon choix parmi les technologies existantes qui pourraient être appropriées à mon projet.

Je vous explique de quoi il s'agit dans les grande ligne :
- C'est une application qui permettra de tirer des statistiques (sous forme de graphiques "personnalisables", c'est à dire au niveau des variables à afficher et de l'échelle de ces graphiques) à partir de données d'un site internet.
- Les données seront triées, calculées et indexées en amont et je devrais donc me contenter d'aller les récupérer via des url apparemment. Tout ceci dans le but d'avoir une meilleure rapidité d'accès aux données dans l'application.
- L'application sera accessible en accès restreint via des comptes utilisateurs de différents niveaux (et donc différentes possibilités en fonction du niveau d'utilisateur).

Les contraintes qui me sont imposées :
- Une accessibilité au niveau de la lecture du code source étant donné que d'autres personnes que moi seront amenées à faire évoluer cette application dans le futur.
- Une rapidité d'affichage du résultat. L'application ne devant pas mouliner deux heures à chaque recherche de stats.
- Possibilité d'utiliser l'application sur différent support de lecture => Ordinateur, Tablette, Smartphone. Responsive Design donc !


On m'a déjà orienté vers quelques solutions possibles pour le développement de cette application. Seulement quelque soit la solution choisie je devrais certainement me former. En effet, pour l'heure j'ai développé principalement en PHP, sans utilisation de frameworks ou d'autres solutions de ce type.

- La première solution qui m'est venu à l'esprit pour ce genre d'application c'est Zend, surtout pour le modèle MVC qui réglerait la contrainte concernant l'organisation et la lecture du code.

Mais on m'a aussi parlé de solutions javascript comme Backbone, Angular ou Node. Sur les conseils que j'ai déjà reçu la solution full javascript semblerait être la meilleure, ok mais j'ai encore du mal à comprendre pourquoi et surtout laquelle (ou lesquelles) ?


Bref, j'ai commencé à lire de la doc concernant tout cela et j'avoue nager un peu dans toutes informations pour l'instant et je ne parviens pas encore à me fixer sur une solution. Si cette application était pour moi, j'avoue que je n'aurait peut-être pas chercher dans ce genre de solutions dans un premier temps et j'aurais peut-être fait comme je sais le faire, c'est-à-dire du PHP pur, sans "artifices" si j'ose dire...

Voilà, si certains peuvent m'aider dans mon choix, en m'expliquant pourquoi telle ou telle solution correspondrait mieux à la problématique alors je vous en serai très reconnaissant parce que pour l'instant je nage un peu et ça me bloque un peu dans mon travail.

Merci d'avance pour vos réponses !

[papajoker]

Bonjour,

tu nous décris un site relativement simple en php. Une solution ZF, pourquoi pas si tu as beaucoup de temps pour te former, je te proposerais plutot Silex.

D’après ta description, il n'y a presque rien en php, donc un framework php simple suffit largement.

Pour les Framework javascript, meme chose, le site me parait simple, je ne vois pas trop l'intéret.

La grande question, c'est surtout comment afficher-générer ces graphiques, avec quel choix technologiques ? Normalement la bonne façon de faire est de générer ces graphiques coté client (bibliothèque flash ou js), mais cela peut poser des problemes coté compatibilité et a l'impression.
Avec un choix de bibliotheque coté client, le site devient tres tres légé
quelques librairies js parmi les 99 existantes :
http://nvd3.org/ghpages/pie.html
http://www.rgraph.net/examples/bar-l...ie-charts.html
ou http://g.raphaeljs.com/barchart2.html
ou google charts https://google-developers.appspot.co...lery/linechart
ou http://tenxer.github.io/xcharts/examples/

[ABCIWEB]

Bonjour,

Les framework sont utilisés pour le travail en équipe pour avoir un code standardisé mais encore faut-il que tous les membres travaillant sur le projet utilisent le même. Si la personne qui doit travailler par la suite sur ton site utilise habituellement synfony, il faudra qu'il se tape la formation Zend avant de pouvoir comprendre ton code (à supposé que tu utilise Zend).
Bref en dehors du travail en équipe, l'utilisation d'un framework ne garanti pas que le code sera facilement maintenable par "tout le monde", mais uniquement par des personnes connaissant ce framework.
Aussi si on ne t'impose pas de framework et que le projet n'est pas très compliqué (d'après ce que tu décris) tu pourrais aussi te contenter de ton propre code correctement documenté.

Pour le reste, on t'a donné des explications sur le fait que le full javascript serait sans doute la meilleure solution ? Javascript côté serveur n'a d'intérêt que pour des mises à jour en temps réel côté client en fonction de changement sur le serveur. Basiquement, il n'y a que les chats ou les jeux en lignes qui peuvent en tirer un profit évident (surtout pour des montées en charge importantes).
Ou peut-être voulait-on te parler de javascript côté client pour créer les graphiques comme disait papajoker En complément des lib déjà indiquées, je peux citer flot qui est basée sur jquery et que j'ai déjà utilisée.

[Welden]

Merci pour vos réponses !

Je potasse toujours de la doc à gauche et à droite et en effet Silex a l'air assez intéressant car peut-être plus facile (et rapide) que Zend à apprendre.

Concernant les bibliothèques qui génèrent des graphiques j'avais déjà fait quelques recherches, et une solution du type de ZingChart avait l'air sympathique avec une belle interactivité, mais payant d'après ce que j'avais compris. Là Google Chart, Flot ou encore NVD3 ont l'air de répondre à mes attentes en gratuit qui plus est .

ABCIWEB => En effet, eux travaillent avec Zend (d'ailleurs le site d'où seront tirées les statistiques est développé avec Zend), mais c'est vrai que j'ai tout de même une certaine liberté quant au choix que je ferai du moment où j'expliquerai pourquoi. Le but étant tout de même de sortir une application propre au niveau des sources j'essaye de réfléchir à la solution qui serait la meilleure.
Pour le full javascript il serait justement intéressant, d'après eux, côté serveur. Pour faire simple, le site fonctionne un peu comme une site de vente en ligne, où x personnes différentes vont ajouter et enlever x produits. Les statistiques seront là pour donner certaines valeurs comme le nombre de produits mis à disposition pas une certaine catégorie d'utilisateurs, voir par un seul utilisateur, le tout afin de comparer. Il y aura aussi des taux de transformation en fonction du nombre de recherche effectuées / le nombre de vente, des données de recherches effectuées sur le site par les clients, et beaucoup d'autres choses.

Cela sera d'ailleurs amené à évoluer, car chaque calcul (ou presque), sera prévu et effectué par eux en amont et les résultats seront indexés. J'irai donc chercher ces résultats pour les organise sous forme de tableau et de graphique. Seulement il faudra que ces statistiques soient à jour (pas à la seconde forcément mais assez rapidement quand même). D'où l'inquiétude concernant les temps de réponses et l'idée de passer par du full javascript.

Apparemment les solutions proposées permettraient même de tout écrire en js. Je ne sais pas vraiment si c'est une bonne solution, mais pourquoi pas si en même temps les temps de réponses sont quasi-instantanés.


L'application en elle même n'est pas des plus complexes, bien que certaines petites fonctions intéressantes vont me demander tout de même un peu de réflexion. Mais les contraintes techniques sont là, et c'est compliqué de faire un choix quand on ne sait pas tout ce qu'une solution peut entraîner, ou pas.

[ABCIWEB]

Bonjour,

Les sites de ventes en ligne actuels avec ou sans statistiques poussées se font depuis des lustres et n'ont pas besoin d'un serveur javascript pour fonctionner. D'après le cahier des charges que tu indiques je ne vois nulle part quelque chose de fondamentalement différent, ni à quel niveau ont pourrait en tirer un avantage.

Mais peut-être j'ai pas tout compris.

J'irai donc chercher ces résultats pour les organise sous forme de tableau et de graphique. Seulement il faudra que ces statistiques soient à jour (pas à la seconde forcément mais assez rapidement quand même). D'où l'inquiétude concernant les temps de réponses et l'idée de passer par du full javascript.

Il n'y a qu'en détaillant cette phrase qu'on pourrait en savoir plus. D'où vient cette inquiétude concernant les temps de réponses ?

[Welden]

Oui ce n'est peut-être pas clair.

En faite, il s'agit d'un site de réservation d'hôtels, dans cette centrale statistique l'utilisateur pourra consulter des statistiques () où il indiquera un encadrement de dates (parfois deux), et des variables. Par exemple, je veux connaître toutes les réservations entre le 01/01/2013 et aujourd'hui (date de la facture en quelque sorte) pour des réservations concernant les dates comprises entre le 01/06/2013 à aujourd'hui, dans les hôtels d'une région en particulier et de x étoiles.

Si dans ce cas de figure une réservation vient d'être effectuée, elle devra être comptabilisée dans mes statistiques. Bon ce problème là concerne surtout la mise à jour de l'index à mon avis, et donc pas mon travail. Cependant, dans un gros encart de date comme je viens de donner, voir même plus (encadrement de dates sur 1, 2 voir 5 ans par exemple), on aura énormément de réponses. Et là si le chargement de ma page prend trop longtemps ça risque de poser de gros soucis.

Autre chose aussi sur lequel je n'ai peut-être pas assez insisté, les graphiques et tableaux seront "interactifs". Autrement dit, une fois que j'ai sélectionné mes critères de recherche, je dois pouvoir :
- Echantillonner mon graphique dans le temps (prenons un graphique avec une ligne de temps sur l'axe des abscisses, cette ligne correspond à la période appelée. Je dois donc pouvoir varier l'échelle par jour / mois / année, etc...).
- Avoir une moyenne pour chaque variable.
- Masquer / Afficher une variable (ça la plupart des class le font visiblement).
- Depuis un tableau (sous forme de classement), situé sous mon graphique, je dois pouvoir ajouter une des lignes de ce tableau à mon graphique pour le comparer à mes résultats. De plus ce tableau affiché est en réalité plusieurs tableaux sur lesquels je peux switcher. Par exemple un tableau de classement des réservations, ou bien des hôtels, ou bien des villes, etc...

Le tout doit évidemment se faire sans recharger la page une fois la requête de recherche de l'utilisateur validée.

Voilà où se situent mes craintes, car même si une grosse partie sera gérée par les index, j'ai bien l'impression que j'aurai tout de même pas mal de calculs et d'affichages sur mes pages.

[ABCIWEB]

Cependant, dans un gros encart de date comme je viens de donner, voir même plus (encadrement de dates sur 1, 2 voir 5 ans par exemple), on aura énormément de réponses. Et là si le chargement de ma page prend trop longtemps ça risque de poser de gros soucis.

Le temps de réponse sera en relation avec l'optimisation de tes requêtes et le temps d'affichage de la page mais je ne vois pas ce qu'un serveur javascript apporterait de plus. Un affichage standard de la page complété par une requête ajax sur les critères de recherche peuvent remplir ce rôle normalement.

Autre chose aussi sur lequel je n'ai peut-être pas assez insisté, les graphiques et tableaux seront "interactifs". Autrement dit, une fois que j'ai sélectionné mes critères de recherche, je dois pouvoir :
- Echantillonner mon graphique dans le temps (prenons un graphique avec une ligne de temps sur l'axe des abscisses, cette ligne correspond à la période appelée. Je dois donc pouvoir varier l'échelle par jour / mois / année, etc...).
- Avoir une moyenne pour chaque variable.
- Masquer / Afficher une variable (ça la plupart des class le font visiblement).
- Depuis un tableau (sous forme de classement), situé sous mon graphique, je dois pouvoir ajouter une des lignes de ce tableau à mon graphique pour le comparer à mes résultats. De plus ce tableau affiché est en réalité plusieurs tableaux sur lesquels je peux switcher. Par exemple un tableau de classement des réservations, ou bien des hôtels, ou bien des villes, etc...

Le tout doit évidemment se faire sans recharger la page une fois la requête de recherche de l'utilisateur validée.

Ben pareil, cela se fait normalement avec ajax.
Es-tu certain que vous n'accordez pas au serveur js des vertus magiques ? Parce que je comprends toujours pas (dans la description que tu as faite) à quel niveau un serveur javascript pourrait faciliter ou accélérer les choses ?

[Welden]

Es-tu certain que vous n'accordez pas au serveur js des vertus magiques ?

Ça c'est possible.


C'est eux qui m'ont parlé de ces solutions comme backbone. D'après eux ça pourrait éviter des problèmes de rapidité, javascript étant plus approprié aux appli web, et ça pourrait être plus simple pour moi de développer en full javascript. Maintenant ce sont des solutions qu'ils connaissent en théorie, mais non en pratique. Pour ma part je ne connais ni la théorie, ni la pratique de ces technologies. C'est d'ailleurs pour ça que je pose les questions ici, en me tournant vers des gens qui maîtrisent tout cela pour écouter vos conseils et faire mon choix en conséquence.

La vraie question est finalement quelle méthode serait la meilleure pour ne pas trop galérer pour moi, tout en répondant aux contraintes du cahier des charges (rapidité, accessibilité de la lecture du code source, etc...) ?

[ABCIWEB]

C'est eux qui m'ont parlé de ces solutions comme backbone. D'après eux ça pourrait éviter des problèmes de rapidité,

Des problèmes de rapidité à quel niveau ? dans quel cas de figure exactement ?

javascript étant plus approprié aux appli web, et ça pourrait être plus simple pour moi de développer en full javascript.

Dans certains cas uniquement mais pas d'une manière générale. Et je ne vois nulle part dans la logique de ton application un point particulier qui pourrait en tirer avantage. Et si tu l'utilise sans en avoir réellement besoin il est très probable que ça te procure beaucoup plus de problèmes (notamment en termes de temps de développement) que d'avantages.

[Welden]

Le javascript m'a été conseillé pour éviter d'éventuels problèmes de lenteur pour afficher les données. Mais aussi, d'après eux pour une meilleure compatibilité sur différents supports (smartphones, tablettes). Et parce que ça me faciliterait les choses de ne coder qu'en js, même la mise en page visiblement.

Ceci dit d'après vos conseils je pense plus m'orienter vers des solutions comme Zend ou Silex pour la simple et bonne raison que l'apprentissage sera moins compliqué. Je n'ai aucun problème avec le PHP, base de ces frameworks, alors que le javascript me file des boutons

[ABCIWEB]

1/ Que l'on s'entende bien : quand plus haut je parle d'ajax, je parle donc de javascript qui envoie des requêtes au serveur interprétées par du code php et retour de la réponse php qui sera intégrée dans les pages en javascript. C'est le fonctionnement classique d'ajax.

Donc dans ton travail et si tu veux une multitude d'affichages sans avoir besoin de recharger la page tu auras à écrire à la fois du javascript côté cllient (on utilise habituellement une lib comme jquery pour faciliter le travail), et du php côté serveur.
...Et pour adapter l'affichage en fonction du support on utilise aussi parfois javascript (mais c'est un autre problème qui parfois peut se traiter avec css).

Tout cela c'est le fonctionnement standard d'un site avec les fonctionnalités que tu décris. Et effectivement les requêtes javascript permettent d'accélérer l'affichage car on ne réaffiche à chaque fois que les données nécessaires sans avoir besoin de recharger toute la page.

2/ Mais tu me parlais plus haut d'une solution full javascript, et j'ai compris par là que le serveur devait être lui aussi en javascript. Par rapport à la solution ajax précédente, l'avantage est de pouvoir envoyer des données depuis le serveur pour un changement d'état du serveur sans avoir besoin d'une demande du client. Au passage, on peut aussi avoir un principe équivalent en utilisant les sockets php. L'autre avantage annexe d'un serveur javascript est le support des processus non bloquants mais à moins d'en avoir un réel besoin, niveau programmation c'est plutôt un handicap qu'un avantage car très prise de tête.
Concrètement on utilisera donc avantageusement un serveur javascript (ou des sockets php) quand on code par exemple un chat ou un jeu en ligne à plusieurs joueurs. Car avec une solution standard ajax, on est obligé d'envoyer des requêtes régulièrement au serveur (toutes les secondes par exemple) pour voir si un joueur à répondu. Cela fonctionne correctement mais avec de nombreux joueurs on multiplie les requêtes souvent inutiles au serveur ce qui peut poser des problèmes de montée en charge. Alors qu'avec un serveur javascript (ou des sockets php) ce problème est résolu car c'est le serveur qui enverra lui-même une réponse au client dès qu'une autre réponse aura été envoyée (et aura donc provoquée un changement d'état du serveur).

Nul part dans ton application je vois un besoin qui ressemble à ce fonctionnement, de sorte qu'il serait inutile (et pas plus rapide) d'utiliser un serveur javascript. Comme déjà dit ton application ressemble donc apparemment à une solution ajax standard... D'une manière générale, tant que tu n'as pas besoin de scruter en continu un changement d'état du serveur pour modifier l'affichage côté client en temps réel, un serveur javascript ne t'apporteras rien de plus.
J'espère que j'ai été clair

[papajoker]

Le javascript ...Mais aussi, d'après eux pour une meilleure compatibilité sur différents supports (smartphones, tablettes)

compatibilité par rapport a quoi et de quoi ?
Générer des graphiques coté client va justement générer des problèmes de compatibilités, mais générer des graphiques coté serveur va entraîner "grosse" lenteur du site

Le javascript .. Et parce que ça me faciliterait les choses de ne coder qu'en js, même la mise en page visiblement.

js coté serveur voir le post de ABCIWEB.
Utiiser un framework js coté client ? le site me parait trop léger, et pour une personne qui ne maîtrise pas, c'est une couche supplémentaire d'ennuis.