Pages :
Bonjour,

Désirant retirer les frames sur mon site (http://bmjdr.free.fr) pour des tas de raisons, j'ai trouvé les deux solutions proposés dans les tutoriels :

http://css.alsacreations.com/xmedia/exemples/frames/frames2.php?page=accueil
http://css.alsacreations.com/Tutoriels-et-articles-divers/Optimiser-le-poids-de-son-site-web-CSS-separee-et-include-PHP

Je sais implémenter les deux (j'y connais rien en PHP, mais comme j'ai des bases en d'autres langage, je comprend le code et peut donc sans problème l'adapter à ma situation).

Seulement, voilà... laquelle des deux solution choisir sachant que :

Le menu de gauche change selon la section choisit (le lien de la section se trouvant dans la partie titre)

La section où se trouve le contenu doit parfois contenir aussi un menu dans le haut, ce qui signifie d'y mettre aussi un include.

Laquelle des deux solutions seraient la meilleure ? Ou alors un mélange des deux ?

Merci pour vos conseils Smiley smile

Nota : Dans deux semaines je commences une formation Javascript axé web qui suit celle de CSS que je viens de terminer. Je suppose que j'y apprendrais à faire des menus déroulant. Donc si vous y voyez une partie de solution... c'est dans mes possibilités à venir, normallement. Smiley cligne
Salut,

je n'ai pas compris ta question.

Il n'y a qu'un seul moyen de ne pas faire de frame et c'est de ne pas faire de frame (désolé pour la tautologie), il n'y a pas de solution de remplacement.

Tout ce qui est php n'est qu'une optimisation de la gestion des fichiers par le développeur et rien d'autre.

Tout ce qui est css n'est qu'un jeu d'illusion optique, s'appuyant sur les propriétés css overflow et height forcé, qu'il vaut mieux oublier tant il amène peu.
Les navigateurs offrent nativement le dispositif de défilement vertical permet la consultation des contenus et il est très bien de s'appuyer là dessus.
Modifié par Christian Le Bouler (26 May 2007 - 15:14)
Christian Le Bouler a écrit :
Salut,

je n'ai pas compris ta question.

Il n'y a qu'un seul moyen de ne pas faire de frame et c'est de ne pas faire de frame (désolé pour la tautologie), il n'y a pas de solution de remplacement.


Je ne veux pas remplacer, mais faire autrement... tout en conservant l'avantage de ne pas répéter le code dans chaque page, ce que le include de PHP permet. Cependant, il semble y avoir deux façon de faire.

Tu as suivit les deux liens qui démontre justement ces deux façons ?

Ma question est... considérant mon site dont j'ai donné le lien et les différents menus qui doivent le composé, laquelle des deux méthodes PHP serait la plus conseillé pour moi...
Shara a écrit :


Je ne veux pas remplacer,



Ben oui mais comme c'était dans ton titre ... Smiley cligne

Donc il s'agit de choisir entre des include conditionnelles (1er lien) ou des include permanentes (2ème lien) ?

La 2ème solution est vraiment plus simple et très intuitive, en plus elle évite la question de l'url rewriting.
Perso je trouve que les include conditionnellles ne se justifient que quand on en a vraiment besoin, ce qui arrive à un moment ou à un autre dans l'utilisation du php, et qu'il est inutile de s'embarquer là dedans tant que ce n'est pas nécessaire.
Modifié par Christian Le Bouler (26 May 2007 - 15:42)
Christian Le Bouler a écrit :


Ben oui mais comme c'était dans ton titre ... Smiley cligne


Bin je les remplace puisque je les retire... mais je ne cherche pas un équivalent 100%...

Le terme est peut-être un peu confus en effet Smiley lol

Christian Le Bouler a écrit :

Donc il s'agit de choisir entre des include conditionnelles (1er lien) ou des include permanentes (2ème lien) ?


Oui, voilà. Comme j'y connais rien, mais que je saurais implémenter, je me demande laquelle prendre pour ce que je veux en faire.

Christian Le Bouler a écrit :

La 2ème solution est vraiment plus simple et très intuitive, en plus elle évite la question de l'url rewriting.
Perso je trouve que les include conditionnellles ne se justifient que quand on en a vraiment besoin, ce qui arrive à un moment ou à un autre dans l'utilisation du php, et qu'il est inutile de s'embarquer là dedans tant que ce n'est pas nécessaire.


Donc je ferais mieux de choisir la seconde solution, même si cela signifie que toute la page sera rechargée à chaque fois (titre et menu compris).
Shara a écrit :

même si cela signifie que toute la page sera rechargée à chaque fois (titre et menu compris).


Quelque soit l'option choisie c'est une nouvelle page complète qui sera chargée à chaque fois. C'est cela qu'il faut que tu visualises comme j'ai déjà dit :
a écrit :

Tout ce qui est php n'est qu'une optimisation de la gestion des fichiers par le développeur


Par le développeur, et pas du tout par l'user agent. Donc du point de vue du navigateur c'est exactement la même chose, au final qu'il faudra charger. C'est une des raisons supplémentaire pour utiliser la solution deux quand on est peu familiarisé avec tout cela, on appréhende beaucoup mieux le mécanisme de l'include php, qui est très simple au demeurant.

Mais bon, je sais bien que le chant des sirènes est irrépressible, alors à toi de voir.
Shara a écrit :
Nota : Dans deux semaines je commences une formation Javascript axé web qui suit celle de CSS que je viens de terminer. Je suppose que j'y apprendrais à faire des menus déroulant. Donc si vous y voyez une partie de solution... c'est dans mes possibilités à venir, normallement. Smiley cligne


Les réponses ne posant pas de problèmes sur ces points, juste des questions en passant:

Une formation à la gestion de contenu aurait été un point de départ plus utile. Mais encore faut-il en trouver, certes... Quelqu'un aurait une idée, à ce propos, dans le genre "tout public" ou dans des formations plus spécifiques ?

Sinon, par pure curiosité, de quelle(s) formation(s) CSS/javascript s'agit-il ?
Aah. Moi je croyais qu'avec la première solution, il y avait que le contenu qui se rechargeait et pas le contour... c'était le seul avantage que je lui trouvais.

Maintenant en fait s'il recharge tout à chaque fois peu importe la solution, alors je préfère prendre la seconde, cela semble plus simple et si jamais mon menu change, il y aura moins de changement à faire je crois au niveau du code.

Merci pour ces éclaircissements Smiley smile
Laurent Denis a écrit :

Une formation à la gestion de contenu aurait été un point de départ plus utile. Mais encore faut-il en trouver, certes... Quelqu'un aurait une idée, à ce propos, dans le genre "tout public" ou dans des formations plus spécifiques ?

Sinon, par pure curiosité, de quelle(s) formation(s) CSS/javascript s'agit-il ?


Tu veux parler d'un CMS ou d'une gestion de contenu plus générale ?
Vu le design très particulier de mon site et mon ignorance en php/mysql, il me semble plus simple de refaire mon site en CSS que de prendre un CMS et de chercher à en refaire le design.

Pour les formations, il s'agit des formations à distance du centre Technofutir TIC ( www.technofuturtic.be ). Etant enseignante à Bruxelles j'y ai accès gratuitement, alors j'en profite Smiley cligne
Shara a écrit :
Aah. Moi je croyais qu'avec la première solution, il y avait que le contenu qui se rechargeait et pas le contour


Ne t'inquiètes pas tu n'es vraiment pas la seule, c'est d'ailleurs pourquoi j'attaque toujours bille en tête dès que le sujet est abordé Smiley cligne
Modifié par Christian Le Bouler (26 May 2007 - 16:55)
Christian Le Bouler a écrit :


Ne t'inquiètes pas tu n'es vraiment pas la seule, c'est d'ailleurs pourquoi j'attaque toujours bille en tête dès que le sujet est abordé Smiley cligne


Promis, dès que j'ai terminé mes deux syllabus pour septembre, je ressors le bouquin de PHP qui traine dans ma biblio depuis des mois et je m'y mets
Smiley lol
Shara a écrit :

Vu le design très particulier de mon site et mon ignorance en php/mysql, il me semble plus simple de refaire mon site en CSS que de prendre un CMS et de chercher à en refaire le design.


Hum... Pour éviter justement les diifficultés actuelles, j'aurais plutôt recommandé le chemin iinverse (aucun design n'est assez remarquable pour ne pas être gérable aisément dans un CMS courant, à moins de tomber dans la catégorie spécifique des designs flash qu'on peut faire en CSS mais sur lesquels on va perde inutilement du temps)

Bien que la gestion de contenu ne soit pas pas forcément synonyme de CMS, ici, ça semblerait bien correspondre et surtout être plus simple.
Modifié par Laurent Denis (26 May 2007 - 17:16)
Shara a écrit :

Promis, dès que j'ai terminé mes deux syllabus



Smiley confused Smiley confused Smiley confused

Quoi, que, qu'est ce que des syllabus ? vivent ils obligatoirement par couples ? Ou bien peut on en trouver à l'état de célibataires ? Y a t'il des rituels de séductions ?

Smiley ravi

Laurent Denis a écrit :

Hum... Pour éviter justement les diifficultés actuelles, j'aurais plutôt recommandé le chemin iinverse (aucun design n'est assez remarquable pour ne pas être gérable aisément dans un CMS courant, à moins de tomber dans la catégorie spécifique des designs flash qu'on peut faire en CSS mais sur lesquels on va perde inutilement du temps)

Bien que la gestion de contenu ne soit pas pas forcément synonyme de CMS, ici, ça semblerait bien correspondre et surtout être plus simple.


Au passage et rapidement, j'adhère bien sur.
Modifié par Christian Le Bouler (26 May 2007 - 17:38)
Laurent Denis a écrit :


Hum... Pour éviter justement les diifficultés actuelles, j'aurais plutôt recommandé le chemin iinverse (aucun design n'est assez remarquable pour ne pas être gérable aisément dans un CMS courant, à moins de tomber dans la catégorie spécifique des designs flash qu'on peut faire en CSS mais sur lesquels on va perde inutilement du temps)

Bien que la gestion de contenu ne soit pas pas forcément synonyme de CMS, ici, ça semblerait bien correspondre et surtout être plus simple.


hmmm... je sais pas... je connais les CMS que de nom, je connais plus les LMS comme on pense en monter un dans mon établissement (mais on est encore au début du cheminement)...

mais pour un site de jdr par mail, car c'est ici mon cas... ça me semble trop gros comme outils, mais encore là je suis peut-être pas assez au courant...

Tu as des suggestion de CMS, que je regardes ?

Bien que le côté 'coder son site soi-même', j'aime beaucoup. Bon je réinvente peut-être la roue en passant, mais j'aime bien faire tout de mes petites mains (de toute façon c'est un site que je gère en bénévolat, alors je n'ai aucune contrainte sinon moi-même ). Smiley lol

Edit : euh... quoi qu'un CMS demandera forcément une base de données MySQL. Considérant que ce site est hébergé chez Free.fr et que le proprio de l'espace utilise déjà une base MySQL, si free ne permet que d'avoir une base par abonnement, ça risque de causé un gros problème Smiley confus
Modifié par Shara (26 May 2007 - 17:35)
Christian Le Bouler a écrit :

Smiley confused Smiley confused Smiley confused

Quoi, que, qu'est ce que des syllabus ? vivent obligatoirement par couples ? Ou bien peut on en trouver à l'état de célibataires ? Y a t'il des rituels de séductions ?

Smiley ravi


Je suis enseignante en école supérieure et je vais donner deux nouveaux cours l'année prochaines. Il faut donc que j'écrive les notes de cours pour les étudiants, c'est-à-dire le Syllabus.

Et comme ce sont deux cours tout nouveau, je dois partir de 0.
Un est justement 'Environnement Internet et applications Internet' où je dois leur montrer les bases du XHTML, CSS et Javascript en plus des serveurs web. Le but n'étant pas d'en faire des webmasters, mais étant mené à devenir administrateur réseau, ils doivent connaitre un peu.
Shara a écrit :

Un est justement 'Environnement Internet et applications Internet' où je dois leur montrer les bases du XHTML, CSS et Javascript


Alors dans ce cas le mieux c'est de parler de html en tant que langage et de n'évoquer le xhtml qu'en tant que doctype possible mais avec peu d'enjeux actuellement. Effectivement de parler de css en relation avec le support que constitut le balisage html natif du document et de renvoyer le javascript à une option bien lointaine dans une démarche de prime apprentissage (lointaine mais riche certes et potentiellement problématique certes plus encore)
Christian Le Bouler a écrit :


Alors dans ce cas le mieux c'est de parler de html en tant que langage et de n'évoquer le xhtml qu'en tant que doctype possible mais avec peu d'enjeux actuellement. Effectivement de parler de css en relation avec le support que constitut le balisage html natif du document et de renvoyer le javascript à une option bien lointaine dans une démarche de prime apprentissage (lointaine mais riche certes et potentiellement problématique certes plus encore)


Normalement ils ont déjà fait du Assembler et du C. Donc le javascript devrait pas être trop complexe pour eux puisque ça restera en effet très basique et ce sera à eux d'aller approfondir par eux-même. La majorité du cours sera axé gestion de serveur web (faut dire que 37,5 heures de cours en tout, ça laisse pas beaucoup de temps non plus).

Sinon je pensais commencer directement en Xhtml, en expliquant les grosses différences avec le html, mais c'est sûr que pour eux, en dehors de taper <br /> plutôt que <br>, la différence restera très minime. Et le CSS ne sera que décrit et légèrement démontré, sans vraiment entrer dedans (pas le temps).

Maintenant comme j'ai jamais encore fait de Javascript et que j'ai pas encore commencé la formation, ce que je leur montrerai est pour le moment très flou dans ma tête, mais ça s'éclaircira. Mais à mon avis à part des ti trucs pas trop complexe style changer le z-align pour changer une image par une autre ou faire un menu déroulant, ça n'ira guère plus loin.

C'est une formation en electronique à la base, et en fait puisqu'ils doivent gérer un réseau, c'est bien qu'il sache un minimum comment est constituée une page web.
Shara a écrit :

Normalement ils ont déjà fait du Assembler et du C. Donc le javascript devrait pas être trop complexe pour eux


Je ne parlais pas de complexité mais de la place du javascript dans l'économie de la gestion/prise en charge de contenu que constitue un document web.
a écrit :

Sinon je pensais commencer directement en Xhtml,


Cela n'a pas vraiment de sens encore une fois. Le langage en jeu est bien le html, il pourrait en être autrement mais pour l'instant ce n'est pas le cas, xhtml n'est pour l'instant qu'un doctype avec des contraintes syntaxiques particulières et rien d'autre.

Donc commencer c'est partir du langage html. Bon en fait c'est pas vrai puisque commencer c'est partir du contenu, parce que s'il n'y a pas de contenu on se demande bien ce que les markup du langage hyper texte prévu pour ça pourraient baliser... Bref.

La question des css est très importante car elle fonde, du moins en partie, l'évolution des doctypes transitional vers les doctypes stricts.
Modifié par Christian Le Bouler (26 May 2007 - 18:26)
Christian Le Bouler a écrit :

Cela n'a pas vraiment de sens encore une fois. Le langage en jeu est bien le html, il pourrait en être autrement mais pour l'instant ce n'est pas le cas, xhtml n'est pour l'instant qu'un doctype avec des contraintes syntaxiques particulières et rien d'autre.


Pour le moment oui, mais le xhtml n'est-il pas voué à remplacer le html ? Et dans ce cas, ne vaut-il pas mieux directement leur apprendre la syntaxe du xhtml plutôt que du html, puisque de toute façon il faudra y passer et qu'il est donc presque dépassé ?

Personnellement j'ai toujours fait du html en amateur, j'ai appris le html par moi-même et je ne connait donc rien aux enjeux et autres aspect politique de la 'bataille' html VS xhtml et normes W3C. J'avais cru comprendre que le xhtml, à plus ou moins long terme, deviendrait le standard, remplaçant alors le html.

J'ai du mal à voir l'intérêt de leur apprendre le html si de toute façon ensuite ils devront se plier à la syntaxe du xhtml qui, si j'ai bien compris, n'est en somme que du HTML reformulé pour suivre des règles de syntaxes plus précises, soit être moins permissif que le html quant aux erreurs de codages.

Et d'un autre côté, considérant qu'ils seront amené à faire plutôt du Assembler et du C sur le marché du travail et que ce sont des langages qui sont très stricts, vaut mieux alors qu'ils conservent cette habitude de rigueur qui semble être plus présente en xhtml qu'en html.

bon je dis pas que le html ne marchera plus si le xhtml devient le standard, car alors X% du web deviendrait inaccessible, mais ne vaut-il pas mieux leur montrer directement le langage le plus à jour, surtout que le xhtml de base n'est pas plus complexe que le html, sinon en terme de rigueur de code (rigueur qu'ils ont en théorie déjà acquise avant par les autres langages).
Pages :