Ganf
-
Compteur de contenus
348 -
Inscrit(e) le
-
Dernière visite
Tout ce qui a été posté par Ganf
-
Hum ... utilisé comme ça le switch/case/default est équivalent au if/elseif/else. Si ça marche et que ça ne marchait pas avant c'est que tu avais mal écrit ton if ou que tu as corrigé quelque chose ailleurs. Ce n'est en rien le passage au switch qui corrige quoi que ce soit (si tu préfère cette syntaxe utilises là, mais ne crois pas que ce soit ça qui "corrige" quoi que ce soit).
-
> Pour info, tu devrais remplacer tes 'if' par un 'switch'. A lui de voir, moi je conseillerai de ne surtout pas le faire. Les switch/break c'est tout de même pervertir pas mal le switch (qui marche normalement en cumulatif) et ça n'apporte globalement pas plus de perf. Les switch/break c'est le meilleur moyen pour oublier un break, confondre quand dans un code pour une fois tu as réellement besoin du switch sans le break (et casser la lisibilité des deux formes qui se ressemblent), faire une exception visuelle dans le code avec une forme unique de bloc qui ne se sert pas d'accolades ...
-
Modérons : <! ... > est une instruction de contrôle en SGML (donc en HTML) et en XML (donc XHTML). Les instructions de controle (je ne sais pas si c'est le terme exact, les experts me corrigeront) on en trouve pas mal, y compris en HTML et en XML. On les trouve entre autres pour définir le doctype, ou dans la dtd pour définir les éléments, pour définir les entités ... <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">'>;http://www.w3.org/TR/html4/strict.dtd"> est une instruction de contrôle (<! au début, > à la fin) Dans une instruction de contrôle on peut faire pas mal de choses ... dont des commentaires. Un commentaire dans une instruction de contrôle doit commencer par "--" et finir par "--". Ainsi <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd" -- il s'agit de la DTD HTML 4.01 stricte --> est théoriquement strictement équivalent à ce qui est au dessus, et donc théoriquement valide en HTML. Ce qu'on utilise habituellement comme commentaire en HTML c'est juste une instruction de contrôle ne contenant qu'un commentaire et rien d'autre) : <!-- xxx --> Les balises <!xxx> sont donc sensées être une syntaxe correcte du coté grammaire. La balise <![if IE]> est donc une balise tout à fait correcte, mais qui n'est simplement pas connue par les clients autres que MSIE. Sauf si je fais une boulette dans mon raisonnement, un document elles ne remettent pas en cause la validité HTML ni le fait que le document soit correct. Elles devraient être ignorées par n'importe quel document conforme. S'il s'agit bien de contenu non standard, c'est du contenu qui théoriquement ne devrait poser problème à aucun navigateur standard (un peu comme les hack CSS, ce sont des erreurs mais qui devraient être ignorées par les navigateurs corrects). Selon moi il n'y a donc rien de mal, ni avec la première forme, ni avec la seconde. Il s'agit juste d'une syntaxe moins connue de ceux qui n'ont pas exploré à fond SGML/XML. (Note, je ne garanti aucune information ci-dessus, il ne s'agit pas d'un terrain d'expertise pour moi). Il se trouve donc que <!-- xxx --> est une instruction de contrôle ne contenant ... qu'un commentaire.
-
Pour les limitations elles sont souvent volontaires, mais il n'empêche qu'elles sont très sérieuses. Au chapitre des trucs innacceptables : l'accès aux éléments avec espace de nom qui est imbitable, et l'impossibilité pour simplexml de faire la différence entre <test> et <!-- test --> (ce qui est tout de même plutot étonnant pour un moteur xml) Tout le monde a attendu ça avec impatience et effectivement c'est simple. Mais en fait ils ont développé ça sans faire de réflexion et sans penser la chose. Au final c'est mal foutu (et encore, ça aurait pu être pire, il ont tout refait au moment des béta). avec DOM je n'ai pas la syntaxe en tête et je ne suis pas chez moi pour regarder mes codes. Je te donne ça dans quelques jours si tu me le rappelles et que personne n'a répondu entre temps. Mais c'est grosso modo la même chose pour obtenir ça : - chargement du doc - récupération du noeud racine à partir du doc - récupération du nom de tag du noeud racine Le problème de SimpleXML c'est que tu ne peux pas avoir le nom d'un noeud à partir du noeud lui même, mais uniquement à partir de son parent ... et que par défaut tu obtiens déjà l'élément racine (et non /)
-
SimpleXMl a plein de limitations, tu viens simplement de tomber sur l'une d'elle. Et franchement, c'est probablement la plus petite. L'idée d'une interface objet plus simple que DOM était bonne, la réalisation est complètement bancale et sorti de quelques cas bien spécifiques (lecture d'un fichier de configuration XML très hiérarchique par exemple), SimpleXML me semble de moins en moins utile. Pour ton problème où tu utilises DOM de bout en bout, ou tu fais une conversion SimpleXML -> DOM sur l'objet pour après lire le nom de l'élément. Il est possible que la conversion ne consomme presque aucune ressource (vu que ça utilise les mêmes structures de la libxml en interne), il faudrait vérifier.
-
Je suis d'accord sur la maturité de PHP5. Pour une entreprise qui a un site critique, je pense qu'il vaut peut être mieux attendre un peu voir si une release de correction arrive dans un mois. Par contre pour l'analyse de Nexen je dirai le contraire. Le marché de mutualisé bas prix est très volatile, avec une forte concurence. Si un hébergeur dit "je suis sous PHP 5 et ça marche" il risque de faire migrer pas mal de comptes. Personnellement je pense que les mutualisés risquent de s'y mettre très vite pour ne pas donner l'impression d'être à la traine. Très vite ça ne se compte pas en jours mais en semaines tout de même. Disons que je pense voir arriver les premières offres sérieuses en masse avant septembre pour les mutualisés. Je pense qu'on aura une conversion de l'essentiel des offres avant la fin de l'année (ça parait loin mais 6 mois pour une migration majeure c'est assez peu). quand à migrer les plate-formes déjà existantes il n'y a pas vraiment d'intérêt pour l'instant (il y en aura quand les bugs et failles ne seront plus corrigées sur la branche 4.x), ça peut trainer un bon moment, et tant mieux.
-
Si je ne me trompe pas les MSIECrawler c'est quand quelqu'un fait un "rendre disponnible hors connexion" et que le navigateur fait un peu comme un aspirateur.
-
echo ${'bla'.$i}; ou $tmp = 'bla'.$i; echo $$tmp;
-
Pour ceux qui ont du mal à le trouver chez eux (ou qui en veulent un dédicacé sans être proche de là où j'habite) je peux toujours faire moi-même les envois. Par contre il faudra me faire parvenir le prix le montant correspondant au prix du livre + celui du port (et le port pour Quebec ça peut être non négligeable). Envoyez moi un mail ou un message privé si ça intéresse quelqu'un.
-
Que veux tu dire ? de gauche à droite ou de droite à gauche ? de 90° ou de 180° ? Plus sérieusement, tu veux quoi ? afficher 10 liens aléatoirement dans une liste globale ?
-
Coté vitesse d'affichage on ne change rien. Coté vitesse de traitement d'url c'est probablement un chouiat moins rapide qu'un jeu de regexp compilées via le mod_rewrite mais c'est clairement négligeable si on ne fait pas l'idiot. D'autant qu'avec un peu de chance via PHP on peut justement faire des traitements simples sans sortir les regexp.
-
La date du 04 juillet avait été très sérieusement avancée. Sinon j'avais vu passer un 15 juillet. Bon, comme d'hab les dates sont très optimistes, mais s'il n'y a pas trop de mouvement j'attend ça avant aout.
-
Tu as quelques autres solutions suivant ton hébergeur : - si ton hébergeur utilise PHP en CGI tu peux probablement utiliser des urls comme http://example.org/script.php/xxx/yyy/zzz Pour peu que tu remplaces "script" par "forum" ou autre truc du genre, ça devrait pouvoir suffir à avoir des URI correctes. Il ne te restes qu'à faire tes règles de rewrite dans le script php (ou autre) - toujours dans ce même cas, la plupart des hébergeurs ont activé une option qui s'appelle "multiview". Elle permet théoriquement de faire de l'auto-négociation de contenu, donc de choisir automatiquement parmi plusieurs formats différents pour une même ressource. L'effet annexe sympa c'est que ça te permet d'oublier l'extension et de faire quelque chose comme http://example.org/script/xxx/yyy/zzz à la place Si tu n'as pas accès à cette option tu as peut être accès à l'option qui te permet de forcer le type d'un fichier. En gros là c'est ne pas mettre le .php au fichier mais informer Apache que c'est tout de même un fichier PHP. Généralement si tu n'as pas accès au multiview tu n'as pas ça non plus mais ça vaut le coup de vérifier - pour les solutions les plus lights il y a la technique des 404. Tu rediriges toutes les pages inexistantes vers une page 404 qui est en fait un script PHP. Dans ce script PHP tu regardes quelle URL a été demandée et tu fais ton rewrite en PHP là dedans.
-
Non, c'est un gros FUD (qui vient je crois d'ODEBI). La LEN (puisque c'est de ça qu'on parle) ne change strictement rien à ce qui est ou pas de la correspondance privée (et pour ceux qui doutent le conseil constitutionnel a confirmé la chose en précisant). Par contre non, le mail n'est pas forcément de la correspondance privée. Il peut en être, il en est généralement, mais pas forcément (en général quand ça contient "enlarge your pen*s" ça n'en est pas , quand c'est envoyé à une liste de diffusion archivée en public non plus). Ce qui qualifie la correspondance privée c'est uniquement sa destination (correspondance ET privée), la média utilisé n'est en rien ni qualifiant ni disqualifiant.
-
C'est public. L'auteur d'Orkut est justement quelqu'un qui a sur son CV des boulots dans la récolte et la renatabilisation de fichiers : recoupements, prospection, profilage ....
-
Je met en garde contre toutes les techniques à base de et %xx Les marchent pour l'instant mais si ça se répend les robots ne mettront pas longtemps avant d'être un peu meilleurs au niveau du décodage HTML, ça ne leur coute pas grand chose. Les %xx sont à éviter à tout prix. Ça ne marche pas avec tous les clients emails et surtout ça empêche les copier/coller de l'email (et ça c'est pas mal embêtant).
-
Pour les invit orkut je peux vous en passer si vous me donnez votre adresse email. Par contre je vous propose dotnode. Un équivalent orkut mais avec des conditions de vie privée totalement revues. (je rappelle par exemple que si vous uploadez une photo sur orkut vous en donnez tous les droits à orkut). Pour l'instant dotnode est un clone bête et méchant mais il est probable que basé sur un système ouvert, il évoluera un peu plus vite. Et pour ne rien gacher, il est fait par des français (donc on peut basculer l'affichage en français pour ceux qui veulent)
-
Certains des développeurs majeurs vivent en Israel. Il s'avère qu'en interne quelques erreurs sont en israelien ... et en faisant des trucs louches sur des parties de codes où peu de monde à participé (généralement le moteur Zend), on peut voir PHP nous répondre en Israelien. Ça m'est arrivé quelques fois et c'est vrai que ça fait bizarre. Mais à priori on peut faire des années sur PHP sans en voir un seul. Le dernier que j'ai vu date d'il y a pas mal de temps je crois.
-
SELECT count(id) FROM table GROUP BY ch1
-
Oh, il est d'ores et déjà stable. Assez pour que l'équipe pense sortir la version finale dans la première semaine de juillet. Les versions sont relativement exploitables depuis de nombreux mois, assez pour la documentation et les tests. Les messages israeliens il y en a quelques uns, globalement les mêmes que sous PHP4, normalement quand on tombe dessus c'est qu'il y a eu un comportement non prévu de la part du moteur, pas qu'il s'agit d'une erreur normale du script. Il y a des exceptions, on en trouve de temps en temps, mais globalement c'est bon du coté de la gestion des erreurs aussi.
-
Malheureusement celui d'Atkinson est le pire, et il risque de tromper pas mal de monde car il a un nom bien connu (et que ses bouquins PHP ont eu une bonne réputation par le passé). En gros le livre est sorti vers octobre 2003 (de mémoire), et documente PHP5 à l'état des versions de développement de l'été 2003. La grande difficulté c'est choisir à un moment "on sort le livre pour qu'il soit sur les étalages dans 2 mois" en pensant qu'à cette date PHP sera stabilisé. Atkinson a visiblement été monstrueusement optimiste. Un bon test pour les bouquins PHP 5 c'est de regarder si ils documentent quelque chose qui s'appelle les "namespace" (espace de nom en français mais ce n'est pas toujours traduit). Si c'est le cas c'est que le bouquin date de l'été 2003. Le livre d'Atkinson en fait parti, ce n'est pas le seul. Si vous aimez l'auteur vous avez à mon avis intérêt à attendre une réédition mise à jour (donc que d'autres personnes achètent la version actuelle ...)
-
accessibilité des sites publiques et la loi
Ganf a répondu à goetsu - Forum : Accessibilité et Ergonomie Web
Zut, ils n'ont pas lu mon oublions les handicapés, ils parlent bien des personnes handicapés uniquement : Ce qui sous entend bêtement que si les sites publiques devront être compatibles avec les navigateurs oraux (1), il n'ont aucune contrainte vis à vis de me rendre accessible le site, à moi qui ne suis pas handicapé. Pourtant, moi j'ai aussi des difficultés d'accès aux sites officiels, avec mon navigateur et mon système d'exploitation qui ne commencent pas par "Microsoft" et qui pourtant ont la prétention de lire la version graphique des pages. On ne donne aucune garantie tout ça va m'être accessible à moi qui lis les textes plus gros que la moyenne, mais certainement pas assez pour que ça constitue un "handicap" à leurs yeux. Non, si tu n'es pas lourdement handicapé on s'en fiche, c'est ton problème l'accès aux sites de l'état, tu n'as qu'à être comme tout le monde. Brrr, encore une loi mal pensée. Pourquoi ne pas simplement imposer l'accessibilité tout court et pas uniquement celle des handicapés ? au moins une obligation de moyen. (1) entre autres, mais concernant le Web, "handicapé" est souvent compris comme "aveugle", ici aussi d'ailleurs puisqu'à la fin on fixe spécifiquement sur les alternatives textuelles des images, oubliant les difficultés de pointages, les couleurs, la lisibilité, etc ... -
> Je voudrais savoir combien de temps de travail a été consacré Le projet a commencé quelque part en décembre si je me souviens bien, donc ça a duré un an et demi à deux. Par période on a travaillé à plein temps, pendant d'autres périodes c'était plusieurs heures après le boulot le soir et le WE. Difficile d'évaluer plus que ça mais je pourrai évaluer le temps par "énorme". > quelles ont été les sources (je me doute le manuel et les listes de news) La doc pas trop finalement, parce que les trucs qui nécessitaient le plus de recherche étaient PHP5, donc pas dans la doc. La liste de développement de PHP (qu'on peut suivre sur news.php.net), les versions de développement de snaps.php.net, les sources même de PHP5 (pour certaines extensions j'aurai eu des difficultés à documenter sans ça, et .. les fonctionnalités d'introspection de PHP5, qui sont bien pratique pour savoir ce qu'offre une classe donnée. > quelle en est la rémuneration... Faible surtout au regard du temps passé. On touche un % de l'ordre de 10% du prix hors taxe. Vu les volumes prévus ça ne ne rendra certainement pas riche. Ça n'approchera même pas le smic horaire de loin. Je crois que ce que ce livre a pu ou pas nous apporté ne se mesure pas vraiment sur le coté financier. Merci Denis, je suis d'ailleurs très intéressé personnellement par les commentaires que tu pourrais sur le livre quand tu l'aura reçu (ça vaut pour les autres aussi).
-
input[disabled] ? mais bon, ça ne marchera pas sous IE (peut être avec les scripts de compatibilité IE7 ?)
-
Non, rien à voir avec les fichiers. Seules les communications sont cryptées. Un peu comme si tu utilises un téléphones spécial : toi (PHP) tu restes le même, la langue que tu parles (HTML/HTTP) reste la même, par contre les deux téléphones qui gèrent la communication (serveur Web + navigateur) font du cryptage/décriptage en temps réel pour que si quelqu'un écoute sur la ligne il ne puisse rien entendre (par contre si il écoute dans une des deux pièces directement il peut tout comprendre).