20-12-2006, 03:35 PM
A mon avis, il faut sutrout différencier deux choses bien distinctes :
L'interface et le traitement des données.
Le traitement des données est difficilement réalisable en autre chose que PhP dans le cas présent. Même si on utilise d'Ajax, il y a du code PhP qui se cache derrière.
L'interface par contre, à part faire du HTML+CSS, Flash ou du JS, je ne vois pas.
Dans le cas soulevé par BlackDuty, je suppose qu'il parle d'une interface en JS pour sa carte. On tombe alors dans le cas bien classique d'une carte référencée dans une base MySQL, exploitée par PhP et gérée sur le client en JS. Rien de monstrueux donc.
Sur le coté "sécurité" de la partie JS, à mon avis c'est un faux problème. Si la gestion des valeurs passées aux procédures PhP est bien controlée, une page utilisant du JS n'est pas moins sécurisée qu'une page HTML avec un formulaire. Tant que le code source de la page ne contient pas de données "sensibles" (comme les PV d'un ennemi), je n'y vois aucun inconvénient.
Enfin, avec l'augmentation de la puissance des machines, il devient plus aisé de faire de la gestion d'interface du coté client. Cela soulage le serveur web de certains traitements non négligeables. D'ailleurs, il suffit de regarder le nombre de cartes qui proposent des menus contextuels, des effets mouseover, des tooltips en JS et même des animations. On est bien ici pile poil dans la partie interface du jeu ou le JS prend toute son importance.
C'est un peu le même système avec le XSLT coté client. Le serveur donne des informations brutes (XML + XSL) et le client mets en forme tout seul comme un grand.
Donc, JS pour l'interface et PHP pour le traitement des infos, tout est normal.
L'interface et le traitement des données.
Le traitement des données est difficilement réalisable en autre chose que PhP dans le cas présent. Même si on utilise d'Ajax, il y a du code PhP qui se cache derrière.
L'interface par contre, à part faire du HTML+CSS, Flash ou du JS, je ne vois pas.
Dans le cas soulevé par BlackDuty, je suppose qu'il parle d'une interface en JS pour sa carte. On tombe alors dans le cas bien classique d'une carte référencée dans une base MySQL, exploitée par PhP et gérée sur le client en JS. Rien de monstrueux donc.
Sur le coté "sécurité" de la partie JS, à mon avis c'est un faux problème. Si la gestion des valeurs passées aux procédures PhP est bien controlée, une page utilisant du JS n'est pas moins sécurisée qu'une page HTML avec un formulaire. Tant que le code source de la page ne contient pas de données "sensibles" (comme les PV d'un ennemi), je n'y vois aucun inconvénient.
Enfin, avec l'augmentation de la puissance des machines, il devient plus aisé de faire de la gestion d'interface du coté client. Cela soulage le serveur web de certains traitements non négligeables. D'ailleurs, il suffit de regarder le nombre de cartes qui proposent des menus contextuels, des effets mouseover, des tooltips en JS et même des animations. On est bien ici pile poil dans la partie interface du jeu ou le JS prend toute son importance.
C'est un peu le même système avec le XSLT coté client. Le serveur donne des informations brutes (XML + XSL) et le client mets en forme tout seul comme un grand.
Donc, JS pour l'interface et PHP pour le traitement des infos, tout est normal.
Quand on te dit qu'un projet est terminé à 90%, prépare toi pour les 90% suivant
Ninety-Ninety Rule
"Une guerre de religions, c'est quand deux peuples s'entretuent pour savoir qui a le meilleur ami imaginaire"
Vu sur IRC
Ninety-Ninety Rule
"Une guerre de religions, c'est quand deux peuples s'entretuent pour savoir qui a le meilleur ami imaginaire"
Vu sur IRC