+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Comment gérer ses interfaces graphiques ? (/showthread.php?tid=3593)
Comment gérer ses interfaces graphiques ? - Shao - 24-01-2009
C'est une grande question que je me pose assez souvent. Le titre parait un peu flou mais je vais tenter de m'expliquer.
Souvent lorsque je parcours des sites ou des jeux web, je remarque que les fonctions javascript liées à un composant sont totalement externes à ce dernier.
Prenons l'exemple d'un panel qui s'étend et se rabat (de manière dynamique) lorsqu'on clique sur le titre du panel. L'idée principale sur les sites web que je rencontre est la suivante :
1) on construit le panel en HTML
2) on lui associe des fonctions situées dans un fichier .js .
Je ne pense pas être le seul à imaginer cette manière de générer les vues, mais je vois plutôt le problème à l'envers. Ma façon de raisonner ressemblerait plutôt à :
1) Je fais appel au constructeur du panel contenu dans un fichier panel.js
2) Ce constructeur va donner des fonctions de délégation et des commandes à mon composant de telle sorte que quand je clique, mon panel s'agrandisse.
J'ai pris l'exemple du panel car pour moi c'est un exemple qui dans la plupart des cas ne nécessite pas de données supplémentaires (et donc un accès serveur), et donc le système d'agrandissement et de réduction sont des méthodes internes à notre composant. Ça éviterait par exemple de se dire "mince le panel utilise quelles fonctions de javascript pour se déployer...".
Si on souhaite récupérer des données supplémentaires, rien n'empêche dans la même page HTML de faire un contrôleur qui pointe sur l'id du panel. Et ce sera ce contrôleur qui injectera les ressources qu'il ira chercher sur le serveur.
Après, peut être que je raisonne de cette façon parce que je fais beaucoup d'interfaces flash et que je me rend pas compte de la complexité de javascript pour faire ce que je viens de proposer. XD
Je remarque également que mon système implique d'avantage de ressources clientes vu que pour la génération de composants visibles, c'est javascript qui travaille.
Cela dit, j'ai déjà vu ce genre de cas dans certains sites (notamment sur hordes par exemple, si on farfouille un peu, on a cette impression que les vues sont générés par du js).
Je voudrais avoir votre avis sur cette question si vous m'avez compris.
RE: [Javascript] Comment gérer ses interfaces graphiques ? - Adrien A. - 24-01-2009
Euh, si j'ai bien compris. La grosse différence que je vois c'est que dans la premier solution n'est pas dépendante de javascript, alors que la deuxième l'est. C'est une question de portabilité.
Mais j'aime beaucoup la deuxième solution, enfin si je l'est interprété correctement. En gros, chaque 'panel' est une instance javascript de la classe Panel.
RE: [Javascript] Comment gérer ses interfaces graphiques ? - wild-D - 24-01-2009
un petit détail; qui explique cette pratique de faire html et de rajouter ensuite la couche javascript pour "bidouiller" le panel (déplier, masquer)
pour moi c'est pour permettre d'avoir une interface accessible même dans le cas ou javascript est désactivé... mais bon ça se perd avec l'ajax/web2.0. (mdr, par défaut j'ai souvent javascript et flash, applet java.. bref tout désactivé - hé ben j'ai un nombre de site conséquent qui sont impraticables)
RE: [Javascript] Comment gérer ses interfaces graphiques ? - Ter Rowan - 24-01-2009
l'intéret est effectivement celui décrit plus haut
la grosse question qu'il faut se poser est : est ce que le site doit fonctionner sans javascript.
Si oui, js ne doit être que du confort et pas créateur de contenu. Donc tout doit être dans la page
Si non (ajax etc... donc javascript obligatoire) alors pourquoi pas , après c'est plus un confort de développement (choisir le plus simple pour soi)
RE: [Javascript] Comment gérer ses interfaces graphiques ? - Melimelo - 24-01-2009
Hordes t'es sûr que c'est pas plustôt en flash qu'il font ca ? Car j'ai pas encore vu un jeu de MT sans flash donc ^^
RE: [Javascript] Comment gérer ses interfaces graphiques ? - Shao - 24-01-2009
Citation :Hordes t'es sûr que c'est pas plustôt en flash qu'il font ca ? Car j'ai pas encore vu un jeu de MT sans flash donc
Y a du flash et du javascript et je pensais notamment à l'interface de choix de mode de jeu dans hordes (citoyen, héros) qui semble faite en js.
Citation :Mais j'aime beaucoup la deuxième solution, enfin si je l'est interprété correctement. En gros, chaque 'panel' est une instance javascript de la classe Panel.
Oui et c'est clairement l'idée que je veux afficher.
Pour la portabilité, je dirai que j'ai un panel générique qui est construit quand même avec du code HTML (par le biais du javascript).
Du coup je peux facilement faire un style pour tout mes panels. Mieux, je peux très bien lors du constructeur du panel, définir une classe de style afin de pouvoir par exemple générer des panels rouges et des panels bleus avec le même composant.
Par contre il est vrai que face à la remarque de Wild, je ne peux hélas rien faire.
RE: [Javascript] Comment gérer ses interfaces graphiques ? - Allwise - 24-01-2009
Si on prend le framework ExtJs, un framework orienté construction d'applications riches internet, il permet les deux méthodes : tu peux créer tes panels et autres composants dynamiquement en javascript et appeler le contenu via une requête ajax, ou autre.
Mais tu peux aussi créer un panel à partir d'éléments déjà présents sur ta page . Du coup, tu peux construire ta page, placer tes panels et, après, les transformer en panels sauce Ext. Cette méthode correspond exactement à ce que tu voudrais faire, ça vaut peut-être le coup de te pencher sur les différents frameworks js.
RE: [Javascript] Comment gérer ses interfaces graphiques ? - Shao - 25-01-2009
J'ai regardé les différents exemples et l'API de ExtJs, c'est clairement l'idée que j'avais en tête. L'avantage de ce framework c'est qu'il permet aussi de gérer des évènements.
Par contre je ne pensais pas qu'un framework comme celui-ci serait open-source. ^^
Merci pour cette trouvaille Allwise !