Reprise du message précédent :

http://dealnews.com/developers/php-mysql.html

salut
j'ai besoin de faire un formulaire comme celui ci http://pgolan.free.fr (en 2eme page, clikez sur go en bas)
 
Avec une arrivée directe dans ma boite mail.
Je crois comprendre qu'il faut que je fasse un script cgi mais c'est tout ce que j'ai compris^^
Ah oui, je voudrais aussi mettre un petit menu déroulant pour choisir en 2 dates par exemples...
Si vous avez des idées ou des liens pour m'aider.. Merci
au passage, si vous avez des remarques sur le site

supair, un test sans donner le code source du test, ni les conditions T'as pas plus foireux pour etayer tes dires?

 
YOU SIR IZ TEH BIG SUXXEY

C'est normal que Visual Web Developer 2005 propose l'édition de page au format XHTML 1.1 quand IE7 ne supporte pas les header application/xhtml+xml ?

 
J'ouvre le fichier mysqli_prepared_inserts et là j'y trouve devinez quoi?
 

mysqli_query($mysqli, $sql);
        $stmt = mysqli_prepare($mysqli, "insert into testing_mysql (char_field, text_field) values (?, ?)" );
        mysqli_stmt_bind_param($stmt, "ss", $char, $text);
        if($stmt){
            for($x=0;$x<10000;$x++){
                $char = str_repeat("X", rand(1, 255));
                $text = str_repeat("X", rand(1, 65000));
                $char = mysqli_real_escape_string($mysqli, $char);
                $text = mysqli_real_escape_string($mysqli, $text);
                mysqli_stmt_execute($stmt);
            }
        }

regardez les lignes 8 et 9
 
Nan mais franchement

Bof
 
Faut se rappeler que les différents sous-groupes de MS ne communiquent pas vraiment les un avec les autres hein
 
Et si je me souviens bien, il ne propose pas le XHTML 1.0 btw

Si, Transitional, mais pas Strict, et Frameset.

Je note qu'il produit des pages avec des balises "<ItemTemplate>", si je ne m'abuse ça découle direct d'une implantation XML (nommage perso des balises)

PS : En plus ça rame cette merde c'est affreux

<asp:ItemTemplate> c'est une balise serveur
et si tu trouves que c'est de la merde, ben utilise-le un peu plus, une fois que t'auras passé le stade "MS=caca" et "putain ça rame et ça plante" (oui ça rame et ça plante) tu découvriras la surpuissance de cet IDE et de ce langage

 
Mais les brêles

J'suis pas entierement stupide, le code (source) généré dans ma page (affichée par Firefox) c'est bien :

Ensuite, c'est du code que nous a filé le prof donc j'en sais rien.

Ms = Caca c'est un fait établi, mais le l'IDE est vraiment puissant c'est également un fait établi

 
doit y avoir un problème, ton prof est à la ramasse stou
même si effectivement le code généré n'est pas franchement un modèle de propreté (javascript:... dans les liens par exemple)
 

faut arrêter d'être bloqué en 1995 hein

C'était une belle année 1995, l'annonce du bug de l'an 2000

PS : Y'avais bien une erreur dans le ItemTemplate xD

mysqli_query($mysqli, $sql);
        $stmt = mysqli_prepare($mysqli, "insert into testing_mysql (char_field, text_field) values (?, ?)" );
        mysqli_stmt_bind_param($stmt, "ss", $char, $text);
        if($stmt){
            for($x=0;$x<10000;$x++){
                $char = str_repeat("X", rand(1, 255));
                $text = str_repeat("X", rand(1, 65000));
                $char = mysqli_real_escape_string($mysqli, $char);
                $text = mysqli_real_escape_string($mysqli, $text);
                mysqli_stmt_execute($stmt);
            }
        }

 
Oki, c'est de la merde en boite, j'avais pas vu   Mea culpa

tain mais

Pour être honnête il n'y a rien qui y ressemble dans le fichier PDO, mais bon ça inspire quand même pas confiance quoi.
 
Accessoirement, sur mysqlperformanceblog on peut trouver des posts sur le sujet: http://www.mysqlperformanceblog.co [...] tatements/ http://www.mysqlperformanceblog.co [...] s-of-data/  
 
Et http://www.mysqlperformanceblog.co [...] ery-cache/ nous dit par contre que le QueryCache ne fonctionne pas avec les prepared statements.
 
(à titre personnel ça ne changera rien, j'utilise les prepared statements parce que c'est plus clair et que ça fait décroitre exponentiellement le risque d'injections SQL et de caractères à taper pour les éviter sans prepared statements)

[mylife]
 
J'ai choppé "Pratique de Ruby On Rails" par O'Reilly et j'ai commandé "Agile Web Development With Rails"

 
J'ai ça dans ma read-list   J'espère que la cat ruby va un peu se développer, t'apprends pas mal rien qu'en lisant les pb des autres
 
Rien à voir, mais, sémantiquement, le titre d'un site ça devrait être un <h1> nan ? Et genre si c'est une image, le <h1> devrait être la même s'il est pas visible ? Ou j'ai tout faux ?

Raison suffisante personnellement pour ne pas utiliser les prepared statements, au moins pour les systèmes à forte charge

 
Je plussois, pour le <h1>

Y'a deux écoles, certains disent que le H1 est situé juste après le title, et donc que l'on peut l'utiliser plusieurs fois dans une page.
 
Perso j'utilise le H1 une seule fois, même quand c'est une image, avec un span =>display:none pour le texte (d'ailleurs je cherche une soluce propre pour foutre un lien sur un H1 avec une image. Un truc qui produise le même effet que l'invalide : <a><h1></h1></a>
 
J'utilise H2 pour les titres de sections, genre "news", "derniers articles", ect...
 
Le truc c'est que j'ai l'impression de m'arreter trop haut, (ça va rarement en dessous de H3), donc est-ce-que le H1 multiple n'est pas une bonne alternative, surtout si il exprime une entité forte qui permet la mise en valeur de partie importante du contenu.

sauf quy'avec cette approche, je trouve qu'il doublonne avec le <title> du header.

A titre indicatif : http://www.w3.org/QA/Tips/Use_h1_for_Title
 

Bon ça me rassure un peu quand même ! J'ai donc bien fait d'envoyer chier (gentiment certes) le client qui m'a bassiné pendant 3/4 d'heure entre autres pour m'expliquer comment il fallait organiser les hx et comme quoi ce que j'vais fait (h1=titre etc) ça voulait rien dire. Il m'avait foutu le doute ce con. C'est donc debatable  
Je savais déjà que le type y connait pas grand-chose (profil je bricole à la maison = je pense que je maîtrise) mais vu que j'ai pas non plus trop d'expérience et que je sais que j'ia du boulôt pour m'améliorer, il m'a mis le doute...
Remarque quand il commencé à me parler de meta tags pour les moteurs de recherche, je l'ai cerné plus vite, ça m'a enlevé deux trois doutes

@ 0x90 : C'est bon a savoir

Non.
 
C'est une optimisation valable quand le bottleneck est là, et uniquement en mesurant ce que ça donne avant et après.
 
On va rappeler quelques règles de base de l'optimisation hein...
 

 
Le passage des prepared statements à une version "manuelle" peut être défendue, mais commencer à coder sans prepared statements parce qu'on considère que la pénalité de perfs est trop grande ne peut jamais l'être.
 
Et si le système est correctement codé, remplacer les prepared statements avec des query classiques et un échappement manuel est trivial, alors qu'avoir un programme correct et sécurisé est, à tout point de la vie du logiciel, capital.

 
('tain mais lol quoi )

http://www.w3.org/2007/03/html-pressrelease
 

Inversement si c'est bien codé tu peux remplacer les échappements manuel par des prepared statements
Et conserver le query cache sans rien changer au code j'appelle pas ça une optimisation inutile.
 
Je suis tout à fait d'accord avec toi que les optimisations dont l'efficacité n'est pas mesurée ne sont pas des bonnes optimisations. Concernant le query cache, je n'ai pas connaissance de situations où sa mise en place n'apporte rien ou très peu (pour des applis web classiques j'entends , c'est-à-dire avec une majorité de SELECT).

Ce que veux dire masklinn : il faut sortir les chiffres.
Mesure la perf de ton appli avec et sans query cache, et si la différence se fait réellement sentir, et qu'il est nécessaire de la combler, alors optimise. Ce n'est pas en te disant "ça ira plus vite" que tu optimises ; il y a des chances que tu aies des surprises, et qu'en fait la différence soit ridicule.
L'avantage des requêtes préparées c'est la sécurité, supérieure aux mysql_real_escape_string_this_time_it_really_works... il faut voir si la vitesse est pour toi plus importante que la sécurité.

Sauf que les échappements manuels ne sont pas un outil facilitant un codage correct (et quand je parle de codage "correct" je ne parle pas de "bien codé" mais de "code faisant ce qu'on veut qu'il fasse" ), bien au contraire, et ils ne sont pas non plus un outil facilitant la lisibilité du code.
 
Contrairement aux prepared statements.

Sauf que
1. Tu n'en as aucune idée puisqu'aucune mesure (et moi non plus)
2. La majorité des articles ont une opinion très nuancé sur les impacts de perfs des prepared statements: améliorations des perfs pour certains, diminutions pour d'autres. Par contre le gain en "correctness" et en lisibilité est toujours indéniable, surtout sur des requêtes complexes.

Ce n'est même pas une question de "bonnes" ou "mauvaises" optimisations, s'il n'y a pas de mesure ce ne sont pas des optimisations, même les meilleurs programmeurs le disent (cf passages sur le sujet dans Code Complete et Programming Pearls si je me souviens bien): quand on se dit "je sais d'où vient le problème de performances" sans faire de mesures, 95% du temps on se plante. Et au final, on optimise pas, on perd du temps.
 
Ce genre de schéma représente bien le déroulement de l'opération:

on optimise là où est le tag "naïve optimisation" parce qu'on pense que c'est de là le problème (ou parce que c'est le plus simple), et ça n'a aucun impact, on a juste perdu son temps sur un truc sans intérêt

Oulala les théories Masklinnienne, ça donne mal à la tête.
 
Bon sinon pour mon affaire de domaine/ss-domaine j'ai eu ma réponse.
Mais une question :
 
écrire dans une page lors de l'appel d'une image :
 
 

 
ça influe sur quelques points je crois, pouvez vous me les rappeler. Merci.
 
La seconde me plait pas...Mais dans mon cas j'aurais pas le choix...Mais c'est pour savoir

Le contenu de ce message a été effacé par son auteur

Ouais enfin ça ça se fait en trois clics

C'est pas grave pour l'URL car la base sera dans une variable

Pourquoi , car j'ai mis en place un sous domaine blog.domaine.fr qui est en réaliter un alias de domaine.fr/blog et que j'ai besoin d'avoir accès aux images de domaine.fr/images

Voilà pourquoi

Donc à par ce problème qui n'en est pas vraiment un....rien d'autre :\

C'est le navigateur qui résoud le chemin de l'image. Dans le cas où il est dans ssdomaine.domaine.com, ça racine est ssdomaine.domaine.com et il ne pourra pas aller plus haut et convertira les éventuels ssdomaine.domaine.com/../images/ vers ssdomaine.domaine.com/images.
Maintenant, si tu veux pas te prendre la tête, tu fais un lien vers domaine.com/images dans la racine de ssdomaine.domaine.com (s'ils sont sur la même machine bien sûr ).

Sauf si tu as un fichier de config paramètrables
Le truc que j'aime pas trop avec les adresses relatives, c'est que dès que tu as une arborescence compliqué ça devient plus chiant de monter/descendre les repertoires.
 
Et puis je rappele egalement que tu as des trucs du genre document_root dans à peu près tous les langages ...

 
Ouais j'avais pensé à ça, mais j'ai pas la possibilité de faire de "ln" sur mon serveur.
 

 
Bon en même temps j'aurais besoins d'adresse en dure qu'au moment de l'affichage de photos, tout le reste, reste en relatif dans les scripts
 
j'avais tout au début suivi aussi la piste des varibles $_SERVER pour PHP, mais je vois pas ici à quoi ça me servirais ?
 
Merci

Sauf que là y a pas vraiment d'optimisation. C'est de l'optimisation à cout 0. Mais je suis d'accord sur les mesures (cf mon message précédent).
 
En quoi une requête préparée est + sécurité qu'une requête utilisant des mysql_real_escape_string ?
 

On est d'accord sur la définition d'une optimisation, je remets pas ça en cause.
 
Mais au niveau code, tu peux imaginer dans ton API d'accès à la BDD un appel du style executeQuery(query, params) dont les appels sont identiques, que tu fasses des échappements par mysql_real_escape_string ou qu'en fait tu fasses du prepared statements avec des mysqli_bind_param. Du coup aucun problème de sécurité sans utiliser de prepared statements

 
La fille elle se branle avec dans l'Exorciste

parce que sauf erreur, dans les requêtes paramétrées, le moteur de BDD teste tout seul les choses comme le type de champ, la taille maximale etc (en tout cas en sql server c'est ça, je suppose que mysql le fait aussi).