Frame Ou Div ?, avantages et inconvénients

Bonjour à tou(te)s !

J'ai commencé un design, mais je me pose une question : frame ou div ?

Les divs me permettent de n'afficher qu'une page : je sais toujours où je suis.
Les frames me permettent de ne rafraichir que l'essentiel : c'est plus léger.

Vos avis ?

Tu peux très bien rafraîchir le contenu d'une DIV sans toucher au reste. Un peu de Javascript et hop! On pourrait même donner un nom à cette technique, mais ça risque de faire pompeux ?! J'avions pensé à AJAX.

Sans hésitation, je te recommande les div. Pour la mise en page, tu sera bien moins ennuyé.

Les DIV sans hésitations. Car si la mise en place d'AJAX peut paraître rébarbatif (à moins d'un bon Framework comme Anthel pour ASP.NET) à cause du Javascript à intégrer, avec des Frame, ce sont des galères de récupération de données entre les frame qui vont apparaître (et pourrir( ton espace de session n'est pas une bonne solution :-) ).

J'ajouterais que l'utilisation correcte du XHTML et des CSS permettent un allègement considérable des pages. Une fois les éléments graphiques en cache, le problème que poserait un rafraîchissement intégral de la page n'est plus aussi déterminant...

Ouaip, pour le Ajax, je connais déjà, c'est pas bien rébarbatif
Pour les images et CSS, je suis un tordu du css, et c'est pas ca qui m'inquiète.

Ce qui m'inquiète le plus c'est que je crée un objet joueur à chaque page qui contient les infos du joueur. Puis, si j'affiche la map j'ai un objet map qui est chargé. etc...

Ce sont des objets, ce qui veut dire que plus je change de pages, plus je risque d'avoir tous ces objets chargés et pleins. Alors, heureusement, une fois la map chargée, au pire je la recharge, mais bon...

Ce qui m'inquiète le plus ce sont les demandes à la base quoi...
Ajax est peut-êtr eune bonne solution, mais IE et FF le gèrent pas toujours de la même manière suivant les plate-formes (PC, Mac) si mes souvenirs sont bons.

Un objet joueur à chaque page? Heuuuu pourquoi?

Pouquoi ne pas mettre ledit objet en session, c'est précisément à ç que ça sert non : conserver des infos d'une page à l'autre.

Je me suis mal exprmié
En fait j'utilise bien l'objet joueur en session. Mais plus tard j'utilise l'objet map, et l'objet guilde, etc... Au final, ils seront tous pleins. Si j'utilise Ajax, autant tous les remplir au début, dès la connexion, peut-être. Je vais y réfléchir.

Pour tes soucils de compatibilité AJAX entre les navigateurs, utilise PROTOTYPE 1.4, une librairie javascript de 40 Ko en version complète ( tu peux prendre aussi uniquement les modules qui te sont nécésaire). Et le tout se place en CACHE donc 1 seul chargement puis c'est #1.

Pour de la documentation sur l'utilisation de prototype, cherche "sergio prototype" sur google, tu trouvera une page sympa dans les premiers résultats. (Avec pleins de traduction dans toutes les langues)


Et rien ne vaux un simple éditeur de texte pour faire un travail optimal et dont on est pleinement en controle. Sans vouloir lancer une guerre, les solutions de développement de microsoft sont des usines à gaz. Et cherchent tellement à tout simplifier que généralement le concept de base du fonctionnement d'un principe est totalement perdu de vu par le concepteur.

Annecdote: J'ai un ami qui développe en ASP et j'ai passé un bon 15 minutes à essayer de lui faire comprendre que tu AJAX, c'était Client Side, et non server side. Le Client demande une page, et non pas le serveur qui force l'envoi.... Enfin, qu'importe.

Mon point est que si tu code tout toi-même, tu connaitra mieux ce que tu as fait et avec un minimum de jugement, ca sera très simple d'éviter de faire une grosse usine à boucanne.

Hmmmm les infos du joueur dans la session. Pourquoi pas, mais le gros problème étant la sécurité, on ne peut pas se fier a ce qui se trouve dans la session !
Il est tellement simple de modifier un paramètre de session que c'est très dangereux.

Alors c'est sur c'est plus rapide, mais a mon avis il vaux mieux récupérer les infos que tu recherches a chaque fois, beaucoup plus sur !

Non, c'est faux, les sessions sont stockées sur le serveur et sont donc sous ton entier contrôle. Ce qui est exposé, c'est ce qui passe par le navigateur : cookies, données de formulaires, etc

Pour ma part j'enregistre $_SESSION['id_joueur']; et à partir de là je récupère les données dont j'ai besoin selon les pages, de plus j'utilise de l'AJAX ce qui est très pratique, car je pense que les FRAMES sont obsolètes et font perdre de la bande passante

Eh ben, he ben ! Un post qui se réveille !
Bon, les sessions sont protégées, Dalai-Lama, désolé de te décevoir. Si on peut changer tes objets session facilement, inquiète toi.
gotrunko, les frames ne sont pas obsolètes, je pense. Elles sont justes à utiliser d'une autre manière. J'utilise maintenant de l'Ajax aussi et ca marche pas trop mal. Le gros problème c'est que si l'on rafraichit, on revient sur la page de départ. De même, aucune page ne peut vraiment être suivie par un bot google et cie...

Pour ma part je n'ai qu'une page design (sur mes nouveaux sites) c'est à dire index.php à partir de là j'utilise la method GET pour choisir ma page, ce qui me permet d'être quand même référencer sur google. Pour l'ajax je ne fais que les actions attaquer, voler, soigner, acheter, messagerie, inventaire.. enfin toutes ces petites actions qui sont plus pratiques au lieu de rafraichir toutes la pages

En tout cas pour en revenir au sujet d'origine je conseil :

Ajax + DIV

et je déconseille les frames, du moins c'est mon point de vue, peut être que quelqu'un utilise les frames et que c'est mieux dans son cas

Un autre point à prendre en compte avec l'XMLHTTPRequest :
IE comme FF ne lance que 2 requêtes asynchrones puis mettent les suivantes en file avant le retour d'au moins une des premières (a priori, 4 pour Opera).
En gros, à mettre de l'AJAX dans tous les sens, on risque de se retrouver avec un navigateur stalled (je l'ai vécu à cause d'une vieile méthode récursive dans laquelle un appel XMLHttpRequest trainait :-) ).


Le bench

Bah... Surtout, pourquoi tu déconseilles les frames ?

Sur un de mes projets, je devais utiliser un ActiveX d'acquisition de signature.

J'ai fais une page contenant le composant et gérant l'acquisition et je l'ai intégrée avec des IFRAMEs partout où la signature était nécessaire dans mon formulaire principal.

Bref, cette page était l'équivalent d'un composant "Signature" et l'IFRAME dans ce cas avait, à mon avis, tout à fait sa place et son utilité.


Tout ca pour dire que, comme d'habitude,dire que telle ou telle technologie ou technique vaut mieux que telle autre n'a de sens que dans un contexte particulier.
Chaque projet, chaque conception peut être mis en oeuvre par différents outils et selon les cas, l'un est mieux adapté que l'autre. Mais il n'y a pas une technique qui vaut mieux que les autres dans tous les cas, sinon on aurait depuis belle lurette remplacé les mainframe des banques et assurances par des serveur Linux et du dev J2EE dans tous les sens :-).
Pourquoi ne l'a-t-on pas fait ? Parce que les COBOL/CICS sont parfait pour gérer du transactionnel et que le mode Mainframe/Terminal est nickel pour faire ce qu'il fait depuis 20 ans maintenant...

Merci Kalan,

c'est intéressant. Perso j'utilise le mode synchrone uniquement
Mais je m'en souviendrais !

En gros il y a deux bonnes raisons pour ne pas utiliser des frames. Si ces deux raisons la ne sont pas un soucis pour un cas particulier y aucune contre indication.

1) les frames ne seront sans doute plus supporté dans les prochaines versions du HTML.

2) les frames ne sont vraiment pas bonne pour le référencement

C'est un peu ce que j'allais répondre, mais je n'ai pas eu le temps, mais les frames peuvent être utilies dans certains cas je ne dirais pas le contraire, de toutes facon il faut se dire que l'on peut faire entièrement un site sans javascript, ajax ou frames du moins c'est ce que me dises les prof