Ganf

On peut voir une url avec le fichier de test ?

Le codage caractère n'a *rien* à voir avec l'aptitude à mettre les caractères spéciaux (j'ai nommé < > & et le délimiteur de chaîne pour un attribut) dans le code source. Un bon codage caractère peut éventuellement te permettre de ne pas passer sous forme d'entité les caractères non ascii (accents, caractères étrangers,...), mais c'est tout. Les deux problématique sont totalement indépendantes.

Moi j'aurai une question : pourquoi vouloir remettre à zéro les auto-increment ? Le propre de ces identifiants sont d'être neutres. À la limite même le fait qu'ils se suivent est un effet secondaire qui ne devrait pas être utilisé. Tu as un identifiant neutre, qu'il commence à 1 ou pas n'a aucune importance. Si pour toi ça a une importance, c'est probablement que tu utilises l'auto-increment pour quelque chose qui n'est pas fait pour.

Il faut bien savoir à qui tu t'adresses quand tu fais ta page. Et l'erreur la plus courante c'est justement de dire "je m'adresse à une catégorie de gens bien précise qui connait ...". Pourquoi ? parce que une foisle document lancé en public, tu ne contrôle pas qui y accède. Et il se peut tout à fait que via un lien mis sur un forum ou sur une liste de diffusion, ou même via Google, des gens autres que ceux que tu as prévu accèdent à ta page. La notion de base de l'accessibilité c'est justement selon moi ne faire aucune supposition sur qui est le client ou comment il accède chez toi, et de tout autoriser/prévoir. Maintenant reprenons ma question, qui accède à ta page ? ce n'est pas le public prévu, ce n'est pas non plus des personnes tierces qui viennent par un moteur de recherche. Non, ce qui accède à ta page c'est *toujours* une machine. Et la machine ne connait jamais ce qu'est XHTML, CSS ou autres. Pourquoi ça peut être utile de faire ce marquage ? imagines un moteur de recherche, tu lui demandes ce que veut dire XHTML, il saura aller chercher les pages qui contiennent l'acronyme. Il pourra aussi au besoin rechercher automatiquement un terme sous sa forme contractée _et_ sous sa forme étendue. Il y a potentiellement une infinité d'applications possibles pour tes acronym, les préciser n'alourdit que très peu les textes (au pire il y a quelques termes soulignés en pointillé dans les premiers paragraphes). Par contre tu peux faire plusieurs choses pour t'aider : - trouver un logiciel ou le développer afin qu'il te remplisse tout seul les acronymes que tu utilises fréquement - ne remplir les acronymes que la première fois qu'ils apparaissent dans chaque document - éventuellement faire en sorte que seuls quelques acronymes plus importants aient un soulignement, et enlever les autres par CSS (histoire de ne pas surcharger le visuel) _AT_Sibelius: Tes séparations sigles/acronymes/abbreviations sont parfois assez contestables. Malheureusement les définitions sont assez floues et je doute qu'on puisse vraiment avoir quelque chose de précis qui fasse consensus et traite tous les cas.

J'ai moi même donné des formations dans le cadre de ma boite, je peux peut être donner quelques pistes mais il y a une chose que je n'ai pas compris avant : quand tu parles de formation, c'est en tant que particulier ou tu parles de formation que ton entreprise pourrait te payer ? Parce que des formations sérieuses ça coute relativement cher. Ce n'est en tout cas AMHA pas envisageable pour un particulier juste pour son loisir. Maintenant, il est pour moi clair que suivre une bonne formation quelques jours te permettra d'aller bien plsu vite que de chercher par toi même. Et comme le temps c'est de l'argent sous forme de salaire, l'entreprise s'y retrouve rapidement. Sans compter que quand tu apprend par toi même tu n'apprend pas toujours comme il faut ce qu'il faut. Si par contre c'est pour tes loisirs n'hésites pas à prendre un bon bouquin, et j'insiste sur le "bon". Un mauvais bouquin risque d'être inutile voire négatif à ton aprentissage. Personnellement je suis l'auteur de "PHP 5 avancé" dont vous parlez plus haut. Difficile d'affirmer si c'est quelque chose qui te convient ou pas. Malgré le titre, si tu as déjà fait de la programmation, je pense que tu ne devrais pas être bloqué par les pré-requis. Dans le cas contraire ça dépend beaucoup des gens : certains se sentent très à l'aise tout de suite avec PHP et le Web, pour eux ça passe ; d'autres ont besoin d'un vrai livre d'introduction et là il vaut peut être effectivement mieux lire une bonne doc d'introduction avant. Quoi qu'il en soit : n'hésites pas à feuilleter en librairie.

Que veut tu qu'OVH y fasse? ta base de donnée n'a aucune notion de "code" ou de "source" ou "d'affichage". Elle enregistre du texte et te renvoie le même texte. Si ton texte affiche le code source il ne peut y avoir que deux solutions : - tu as fait une mauvaise manip en entrée et tu as modifié (échappé) le texte avant de l'insérer dans la base - tu fais une mauvaise manip en sortie après avoir récupéré le texte et avant de l'afficher. En rien ça ne peut être la faute de la base pour ton cas. Arrêtez de crier après les outils et commencez un peu à vous responsabiliser et à vous remettre en cause. Je sais que c'est plus facile de dire "c'est la faute de l'hébergeur qui a sa base qui déconne" mais tant que tu n'en es pas sûr il serait bien d'éviter de cracher sur l'hébergeur en question (ce n'est pas fait explicitement dans ton message mais c'est ce qui transparait)

Pour faire la div, un bête position:absolute; top:0; left:0; z-index:127; suffira. Si tu veux quelque chose au milieu de la fenêtre tu peux par exemple faire remplir les top et left en javascript à partir de la taille de la fenêtre utilisateur. Pour la faire disparaitre : onclick="this.style.display='none'" Ceci dit ... ça va être gênant pour l'utilisateur, et pas qu'un peu. Je serai tenté de dire que ça va être pire qu'une vrai popup ... et ça ne marchera pas non plus partout (extensions à la adblock, javascript non activé, navigateurs non graphiques, etc.)

Non (et ça manque d'ailleurs la possibilité de réutiliser des sous éléments). Par contre tu peux faire : div#monmenu1 ul, .maclasse , #divmonmenu2 ul { .... } Et la présentation s'attachera aux trois types de balises.

- le plus simple est que tu te serves de "sudo", il te permettra de te faire passer pour un utilisateur ou un autre le temps de l'exécution d'une commande. Par contre pour être vraiment utile il faudra faire un peu de configuration - sinon tu fais en sortes que /usr/bin/run appartienne à nico et tu lui fais un "chmod 1755 /usr/bin/run" (oui, j'ai bien mis un 1 en premier). Tous ceux qui exécuteront "run" le feront automatiquement en temps que nico

/<[aA]((?:\s\S+)*)\s+href=(['"]?)index.php\?cat=(.*?)\2((?:\s+\S+)*)\s*>\s*(.*?)\s*</[aA]>/ à transformer en <a\1 href="\5-\3"\4>\3</a> note1 : c'est un code pour PCRE et pas pour les EREG Posix note2: non testé, il y a surement des erreurs, mais ça doit tourner autour de ça et pouvoir te servir de base de réflexion

Oui, mais en même temps un standard c'est une cnvention du "on va tous parler la même langue pour se comprendre correctement". Tu peux toujours évidement ne pas y adhérer à 100% et mélanger la langue commune avec ton patois ou ton argot/jargon maintenant ... quel est le résultat ? le résultat c'est que si tu n'adhères pas à 100% des gens ne te comprendront pas à 100% et tu viens de remettre en cause le principe même du standard et son utilité. Ce sont des choses qui peuvent se faire, mais certainement pas à la légère. La faute aux évangélisateurs pro-standard. Le standard n'amène pas un code plus propre, il amène un code standardisé : compréhensible par tous. Tu peux toujours faire du HTML dégueulasse mais standard. La propreté du code, le modèle de conception ... ce sont bien sûr des choses qui ont été insuflées lors de la norme parce que quitte à fixer quelque chose autant que ce soit quelque chose de bien, mais le but d'une norme c'est uniquement de fixer une langue commune, pas de légiférer sur ce qui est bien ou pas bien. Après d'autres, parfois les mêmes, s'expriment su ce qu'ils pensent bien ou pas bien, accessible ou non accessible, mais c'est quelque chose d'indépendant. Pour reparler du contexte du target, on ne te place en fait pas devant un tout ou rien : codes ce que tu veux comme tu le veux. Si tu veux faire du strict avec pour seul écart l'utilisation du target, alors fais du strict avec pour seul écart l'utilisation du target. Il n'y a pas de problèmes la dessus. La seule chose que tu ne peux pas faire c'est déclarer du strict et utiliser quelque chose qui n'est pas strict, certains moteurs risqueraient de ne pas apprécier. Quant à ma réaction personnelle sur les window.open qui ne sont pas dans la philosophie stricte, c'est justement pour désacraliser le modèle strict. Si c'est pour faire ça, quel mal il y a t'il a utiliser le transitionel ? il fonctionne, il est standard, et il correspond aux besoins (même si c'est ne l'utiliser que pour le target).

autre question : pourquoi vouloir interdire la visualisation de tes codes ? Je ne penses pas que ton javascript soit tellement secret ou soit tellement innovant qu'il faille absolument le protéger de toutes les multinationnales qui n'attendent que de le piller. La question est "es tu sûr qu'il soit vraiment nécessaire de tout cacher ?"

En même temps j'ai du mal à voir dans quelles conditions on aurait à terminer un bloc par <br/>. Tu n'aurais pas une url avec la page exemple qu'on puisse regarder ?

Pas sans javascript sous Internet Explorer

Et pour répondre à l'initiateur du fil : Penser qu'il faut absolument ouvrir dans une nouvelle fenetre pour éviter que les visiteurs partent, c'est limite vouloir les retenir par la force. Penses tu gagner quoi que ce soit à les retenir si eux ont envie de partir ailleurs ? Et de manière plus générale, à quoi te sert d'avoir plus de visiteurs ? si ton site est rémnéré sur autre chose que l'affichage de pub (et je parle bien d'affichage, pas de clic), globalement faire rester l'utilisateur qui avait envie d'aller ailleurs ne t'apportera rien sauf des problèmes de bande passante. Maintenant, de mon expérience, si beaucoup de gens ne savent pas ouvrir une nouvelle fenetre d'eux même, ils n'ont pas non plus l'habitude de naviguer sur plusieurs fenêtres. La fenêtre du dessous elle restera au dessous, oubliée, et sera fermée quand il "éteindront Internet". Dans mes connaissances c'est même le contraire : plusieurs fenêtres ça les perturbera énormément en perdant la possibilité de revenir sur ton site comme ils savent le faire (bouton arrière).

Tout d'abord dans les réponses répides en vrac aux divers intervenants du sujet : - non l'attribut target n'a pas disparu, il est toujours valide, conforme, et présent même en XHTML. Aucune situation n'a changé depuis 1998 concernant l'utilisation de l'attribut target et l'ouverture d'une nouvelle fenêtre. Je comprend mal pourquoi d'un coup les gens se réveillent. - non un javascript avec un window.open() n'est pas plus accessible (j'ai vu ça dans une des réponses et ça m'a fait un peu sursauter) : c'est moins compatible et l'effet final est strictement le même, ça ne peut être que moins bien - le problème d'accessibilité ne vient pas de l'attribut target mais principalement des navigateurs qui n'ont pas prévu de manières de l'ignorer ou de prévenir l'utilisateur de sa présence. Au final ce qui pose problème ce n'est pas l'attribut lui même mais son effet (ouverture d'une nouvelle fenêtre), il ne sert donc à rien de retirer l'attribut pour refaire le même effet en javascript. Pour ceux que ça intéresse j'ai un gros article en préparation sur le sujet (en fait il est limite déjà fini). Si certains sont intéressés pour jouer les relecteurs ce weekend ça me permettrait de le proposer à Denis (ou à un autre si ça ne l'intéresse pas) dès la semaine prochaine.

La question n'a pas de sens. Le cookie est un procédé de transmission, la session c'est un procédé applicatif. Si cette phrase ne vous semble pas clair, peut être que celle là le sera : la plupart du temps les sessions passent par des cookies. Opposer les deux est un peu étrange. Maintenant : - quand tu parles d'utiliser les cookies en les opposant aux sessions ça peut vouloir dire deux choses. Tout d'abord refaire un système similaire aux sessions PHP mais en le recodant de 0, là à la base c'est une mauvaise idée, au mieux ton système sera identique aux sessions, mais il a aussi toutes les chances d'être moins bien, surtout du coté sécurité Ou alors ça veut dire stocker toutes les données dans le cookies, les envoyer au client et les récupérer à chaque fois. Si tu as une authentification à faire ou des données de ce type là à stocker, c'est la chose la plus importante à éviter. Sauf si c'est pour des petites trucs qui ne posent aucun problème de sécu (type les préférences utilisateur ou retenir l'email pour éviter qu'on le retappe à chaque fois dans les forum) : oublie les cookies et utilises les sessions voir : http://blog.dreams4net.com/CookiesEtAccessibilite - Quand tu utilises une session, le principe c'est de donner un identifiant au visiteur et faire en sorte qu'il te le rappelle à chaque visite. Cet identifiant on a deux manières de le transmettre : un cookie, ou le faire passer dans l'url des pages. Le cookie marche très bien (normal, ça a été créé pour) mais c'est dépendant de la bonne volonté du client (qui peut les désactiver). L'identifiant dans l'url ça marche même sans bonne volonté du client mais ça rend souvent la page non conforme, de plus ça perturbe les bookmark et l'indexation. Mais surtout, ça pose de sérieux problèmes de sécurité. Dans ces problèmes de sécurité on a la possibilité pour un tiers de récupérer tes identifiants (et donc de te voler ta session) via le problème des Referer HTTP, ou une facilité déconcertante pour faire une attaque par fixation de session. Dans tous les cas l'idée même de passer l'identifiant dans l'url doit être oubliée, la fonctionnalité doit être désactivée. Voir : http://blog.dreams4net.com/SessionsIdentifiantsEtReferants - Si des gens veulent couper les cookies tant pis pour eux. Ils savent ce qu'ils font, c'est leur problème. On n'est plus comme il y a quelques années où les magazines criaient que les cookies sont le mal, et où les utilisateurs les désactivaient sans savoit les remettre ni comprendre les conséquences. Actuellement si quelqu'un refuse un cookie c'est qu'il le fait exprès et qu'il connait très bien les conséquences (la plupart des gros sites ne marchent plus sans cookie). S'il veut se servir de la fonctionnalité de ton site : a lui d'activer ses cookies. De plus, pourquoi voudrait-il couper les cookies ? ça ne serait pas justement pour qu'on évite de le tracer et de stoquer des informations sur lui ? ce n'est pas justement ce que tu cherches à faire sur ton site (même si c'est pour des trucs "honnetes" comme l'authentification) ? S'il retire les cookies c'est pour ne pas avoir le type de fonctionnalité que tu essaies de lui donner. Tu n'as donc pas à essayer de le "forcer". à voir : http://blog.dreams4net.com/P3pEtFiltresDeCookies http://blog.dreams4net.com/CookiesEtAccessibilite

On ne peut pas(*). Si tu veux faire ça il te faut faire une déclaration statique dan ta classe fille aussi. D'ailleurs si tu réfléchis bien ça n'a aucun sens de toutes façons : si ton truc avec __CLASS__ marchait, l'objet Foo et l'objet ExtendedFoo stockeraient tous les deux leur instance dans foo::getInstance(). Si tu as les classes extendedFoo et extendedFoo2, tu ne pourrais pas avoir une instance de chaque (vu qu'elles sont toutes les deux stockées dans une variable unique de la classe mère). D'ailleurs pendant qu'on y est, ta variable statique devrait plutot être au niveau de la classe qu'au niveau de la méthode. (*) : à vrai dire on peut, il faut ouvrir la trace avec debug_backtrace() et récupérer les différents appels, mais bon, ce n'est pas fait pour.

Première question : pourquoi cherches tu à faire ça ? Parce que normalement les identifiants en auto-increment sont faits pour être des identifiants neutres. Ils pourraient être aléatoire que ça ne changerait rien. Si tu cherches à ne pas avoir de trous c'est probablement que tu t'en sers pour autre chose que ce que tu devrais (dans ce cas penses à faire autrement ou utiliser un autre champ de ta DB) ou que ce n'est que cométique, parce que c'est plus joli (en ce cas oublie, ce n'est pas fait pour être joli). Et globalement, la conclusion suite au paragraphe précédent : tu peux pas, simplement parce qu'il n'y a aucune raison de pouvoir.

WHERE date1 > now ORDER BY date1 ASC ?

_AT_Anonymus : " Quel intéret de strval($grp), alors qu'il retourne la même chose que $grp ?" Il ne retourne pas la même chose. $grp est un objet, strval($grp) est un texte. Quand tu utilises $grp dans une chaîne PHP fait la conversion tout seul, mais si tu souhaites pouvoir envoyer ta donnée à une fonction tierce pas forcément conciliante, il te faudra peut être passer par strval() avant pour être sûr de n'envoyer que le contenu sans l'enrobage SimpleXML. L'exemple type c'est justement celui d'Ace : si il envoie $grp à print_r() ça lui donne des résultats étranges, si il passe d'abord par un strval(), tout rentre dans l'ordre.

print_r() est trompeur. Il te donne l'intérieur d'un objet, malheureusement les objets simpleXML utilisent à fond les possibilités PHP5 et ont pas mal de comportements "magiques". Pour récupérer le contenu textuel d'un noeud, il faut simplement essayer d'afficher ce noeud avec echo ou print. Au lieu de faire un print_r($tab_groupes) essayes plutot de faire un foreach($tab_groupes as $grp) echo "grp : $grp <br/>" ; Si tu veux récupérer le texte sans l'afficher, il te faudra passer par strval($grp);

_AT_Anonymus: oui oui, je suis d'accord, je ne critique pas. La session est probablement ce qu'il y a de plus simple. J'ai juste voulu être un peu plus complet. Si Lea a connaissance des défauts et accepte de s'en contenter (on n'a pas forcément le temps de faire un truc parfait partout) c'est tout à fait correct. J'ai voulu appuyer la dessus en haut de mon message justement pour ne pas lancer forcément tout le monde dans un truc complexe. Désolé si je n'ai pas été clair. Par contre, et là ce n'est pas un point de détail, si vous avez PHP 4.3.x, n'utilisez pas session_register(), vous risqueriez des problèmes. Sur deux config totalement distinctes on a vu quelques problèmes majeurs (sessions corrompues) en utilisant les session_register. Les problèmes ont disparus avec un remplacement automatique de "session_register('xxx') ; " par "$_SESSION['xxx'] = $xxx ; " dans tout le code. Je ne comprend d'ailleurs pas ton argument, $_SESSION est *toujours* accessible en écriture pour peu qu'on ai fait un session_start, et son contenu est toujours sauvegardé (avec la même condition). L'avantage de $_SESSION est d'ailleurs qu'on peut aussi écrire des variables non globales. De mon point de vue comme en plus c'est plus simple/naturel (une simple affectation), autant en profiter.

L'histoire des sessions c'est bien et ça marche mais ce n'est pas parfait. Avec l'arrivée des nouveaux navigateurs de plus en plus de gens naviguent avec plusieurs fenêtres/tab ouverts sur le même site. Je ne parle pas que des informaticiens mais aussi de monsieur tout le monde. Le problème survient dans ton cas quand la personne rempli un même formulaire dans deux fenêtres différentes (ou deux formulaires qui utilisent une même var de session). Imaginons le scénario suivant qui demande de choisir un pays dans la première partie du formulaire et un visiteur qui utilise deux fenetres, A et B : - fenetre A : remplie avec le pays "allemagne" et on envoie (ça écrit "allemagne" dans la session) - fenetre B : remplie avec le pays "canada" et on envoie (ça écrit "canada" dans la session) - fenetre A : on remplit la seconde partie et on envoie => vu que la session contient maintenant "canada" il se retrouvera avec un résultat qui ne correspond pas à ce qu'il a envoyé dans la fenetre A mais à ce qu'il a envoyé dans la fenetre B Effectivement suivant les formulaire on peut dire qu'il est idiot/inutile de faire deux fois le formulaire simultanément. Mais en même temps l'utilisateur peut avoir envie de tester, ou avoir besoin de faire quelque chose de non prévu. Il a même le droit d'être idiot ou de faire un truc inutile sans s'en rendre compte (malheureusement il ne se rendra pas forcément compte que le résultat ne correspond pas à ce qu'il devrait avoir et que ton système de session a tout mélangé). Coté paliatifs on a : - au lieu de tout stocker en session on rajoute tout en champs cachés dans la seconde partie du formulaire. C'est à mon avis la meilleure solution mais il ne faut pas oublier de revérifier la cohérence de ces données lors de la soumission de la seconde partie : il serait simple pour un informaticien ou un utilisateur averti de modifier ce qui est dans les champs cachés. Tant qu'il y a une vérification de toutes les données à chaque fois (et ne jamais considérer qu'une donnée a déjà été vérifiée), il n'y a pas problème. - lors de la visualisation de la première partie on tire un identifiant aléatoire et on le rajoute en champ caché, on remet ce même identifiant dans les parties suivantes du formulaire (toujours en champ caché) et on stockes les données en session dans une variable tableau qui a le nom de cet identifiant. Si la personne utilise deux fenetres, chacune aura son identifiant et les données n'interféreront pas. Ca ne règle pas tous les problèmes (notament ceux d'éventuels retours arrière ou de duplication de fenêtre), mais ça règle le principal

En fait ce n'est pas qu'on peut, c'est qu'on doit Le "id" c'est pour identifier le champ dans le document, le name c'est pour nommer la donnée dans la transmission. Les deux sont utiles mais ils peuvent être totalement différents (le name peut ne pas être unique, le id l'est forcément).