zedark
-
Compteur de contenus
10 -
Inscrit(e) le
-
Dernière visite
Tout ce qui a été posté par zedark
-
Merci, 100% d'accord, j'ai fais une grossière erreur de diagnostic... PDO n'est pas en cause, je suis donc HS, désolé. Ma solution a été de rajouter un second tri sur une colonne qui est unique et a toujours des valeurs.
-
Bonjour J'ai une page php affichant un tableau de résultats paginés d'une recherche multicritères, triable par colonne. En cliquant su un lien de résultat, j'ouvre une page affichant les détails d'un seul résultat, cette page contenant également une pagination, mais cette fois-ci de 1 en 1, pour naviguer dans les résultats de la même recherche. Cette 2è page fait donc exactement la même requête SELECT, hormis la clause LIMIT pour ne renvoyer qu'un seul élément. À ma grande stupéfaction j'ai constaté que si je triais le résultat sur une colonne contenant des valeurs vides ("", pas NULL), pour toutes les valeurs vides le tri était différent pour la première page et la page des détails d'un résultat... ce qui fait qu'en cliquant sur un résultat de la première page, je tombe sur les détails d'un autre résultat : c'est plutôt gênant. Je teste les requêtes dans phpMyAdmin -> le tri est conservé, aucun problème. Je pense donc à un problème de PDO (car mes connections se font via PDO dans les pages, mais pas dans phpMyAdmin), ou peut-être une histoire de cache mysql, mais je n'ai aucune connaissance dans le domaine. J'ai fini par placer des index sur les champs utilisés pour le tri, et là miracle ça marche (j'aurai dû les indexer depuis longtemps de toute façon). Mais bon j'ai résolu mon problème sans le comprendre, et ce n'est pas comme ça que l'on progresse. Votre avis ?
-
Pareil pour moi. C'est la première fois que j'essaie de faire un joli tableau du point de vue xhtml en exploitant colgroup, et tout n'est pas clair. Il y a quelques semaines je me suis cassé les dents sur le stylage des colonnes (j'ai fini par utiliser des classes sur les <td>)... et ça recommence avec la langue Il me semble que le navigateur utilise les <col /> pour identifier les colonnes lorque <colgroup> en contient : « Les agents utilisateurs doivent ignorer cet attribut (span) si l'élément COLGROUP contient un ou plusieurs éléments COL. » C'est bizarre. j'ai regardé ce que firebug en disait : la colonne déclarée avec <col lang="en" /> est bien au bon endroit sur la page, l'inspecteur dom me dit qu'elle a "lang: en", mais quand je sélectionne du texte de cette colonne, les propriétés me disent que c'est du français. Tant pis, j'ai toujours l'autre méthode qui fonctionne.
-
Merci Nullette et Monique ! Suivant vos explications, j'ai codé la langue de ma colonne de 2 manière pour voir ce que ça donne : Méthode avec col : <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"> [...] <meta http-equiv="Content-Language" content="fr" /> [...] <table summary="Résultat de la recherche de cartes."> <colgroup> <col /> <col lang="en" /> [...] <tr> <td>Ceci est un texte en français<td> <td>This is an english text<td> [...] Résultat : Mon ptit firefox considère que la page est en français, et la 2è colonne du tableau comme du français également Méthode sans col : <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"> [...] <meta http-equiv="Content-Language" content="fr" /> [...] <table summary="Résultat de la recherche de cartes."> [...] <tr> <td>Ceci est un texte en français<td> <td lang="en">This is an english text<td> [...] Résultat : Mon ptit firefox considère que la page est en français, et la 2è colonne du tableau comme de l'anglais Conclusion : soit j'ai une erreur dans la méthode avec col (j'ai pourtant testé plusieurs variantes), soit on peut décidément pas faire grand chose avec colgroup, et c'est dommage. Encore merci, alex,
-
Bonjour, Sur une page déclarée en français (<html lang="fr">) j'ai un tableau dont la deuxième colonne contient un nom traduit en anglais. J'ai donc pensé à <colgroup>, et à placer l'attribut lang="en" dans la balise <col> correspondant à ma colonne. Est-ce la bonne manière ? Si oui je suppose que je n'ai pas besoin de déclarer lang="fr" pour les autres colonnes, elles auront la langue de la page. J'ai bon ? Merci,
-
Merci Kioob pour l'info sur le cache mysql, je vais refaire les tests. Pour ce qui est de la complexité de la clause WHERE, je ne vois pas vraiment comment faire plus simple, et ça va être bien pire par la suite avec la mise en place d'une recherche multi-critères sur la même jointure. Par contre j'utilise si souvent cette jointure dans mes requêtes que je vais essayer de dénormaliser les deux tables pour voir ce que ça donne (une a 10 000 lignes, l'autre 15 000). J'avais lu le post de captain_torche, mais j'ai écarté la solution avec SQL_CALC_FOUND_ROWS pour une raison dont je ne suis pas très fier : en local je n'ai aucun souci, mais chez l'hébergeur je n'arrive pas à réutiliser un objet PDO, la connection se referme systématiquement après chaque récupération de données. Et j'ai contourné le problème sans chercher la solution pour l'instant, mea culpa Mais promis ce soir je m'y met. Merci pour vos réponses,
-
Bonjour et merci pour la réponse rapide Oui, le résultat de mon petit test ne me laisse d'ailleurs aucun doute. J'avais juste l'idée que pour un nombre restreint d'enregistrements retournés (et j'estime que c'est le cas pour ma recherche par nom), le fait d'avoir une seule requête pouvait accélérer un peu le code. Je me trompais. Désolé j'ai oublié de préciser que ce ne sont pas les requêtes utilisées, j'ai mis ça pour ne pas alourdir mon post. Il s'agit en fait d'un : SELECT a.card_name_en AS name_en,[...] b.edition_code FROM card a JOIN card_edition b ON a.card_id = b.card_id WHERE (card_name_fr LIKE :cardname OR card_name_en LIKE :cardname) GROUP BY a.card_id ORDER BY card_name_en; Comme c'est la première fois que je joue à tester la rapidité d'exécution d'un bout de code, j'ai appliqué l'exemple de la page microtime() du manuel php : $time_start = microtime(true); for ($a=0; $a<100; $a++) { ...mon code à tester... } $time_end = microtime(true); $time = $time_end - $time_start; echo $time; S'il y a d'autres moyens pour tester plus fiables (sans être trop compliqués à mettre en uvre), je suis preneur, car je compte renouveler l'expérience pour améliorer petit à petit mon vilain code d'amateur
-
Bonjour ! J'ai mis en place sur mon site (php6+mysql) une recherche simple par nom. La requête est un bête SELECT sur 2 champs, et les résultats sont paginés. Pour la pagination j'ai besoin du nombre total de résultats retournés par la recherche, d'où dans le code 2 requêtes successives, via PDO : Un SELECT COUNT(*) pour récupérer le total ; un SELECT * LIMIT 0,30 pour récupérer les résultats à afficher sur la première page. Puis, à force de lire partout que pour rendre son code plus véloce il faut limiter au maximum le nombre d'appels à la BDD, j'ai essayé une solution à une seule requête : Un SELECT * pour tout récupérer ; je stocke dans un tableau, qui me donne le nombre d'enregistrements retournés ; puis un array_splice() sur le tableau pour ne garder que les 30 premières lignes à afficher. Puis je me suis demandé : au fait c'est laquelle la meilleure solution ? Donc j'ai testé avec microtime() : Pour une centaine d'enregistrements à retourner, pas de différence significative de vitesse d'exécution ; Par contre avec l'ensemble de la table concernée (15 000 lignes), la méthode à 2 requêtes est 75 fois plus rapide ! Voyez-vous d'autres critères que la vitesse d'exécution pour orienter mon choix ? Merci,
-
Bon ben j'ai plus de problème D'autant plus que j'ai déjà intégré un patch similaire pour la gestion du hover toujours pour IE6 mais je n'imaginais pas que la solution existait pour les png. Un grand merci !
-
Bonjour à tous ! Un premier message (j'en profite pour me présenter : alex, 34 ans, bidouilleur amateur sur le web depuis une dizaine d'années) pour avoir votre opinion sur un choix qui me préoccupe depuis quelques semaines : l'utilisation du png 24 bits sur mon site. La problématique : le site, bien qu'en ligne, ne sera pas terminé avant 1 an la gestion de l'antialiasing par niveaux de transparence du format png24 m'apporterait énormément dans la charte graphique que je prévois le vilain Internet Explorer 6 qui ne les affiche pas correctement est encore estimé à près de 20% des navigateurs en ce début d'année. Ça ne rendrait pas le site inutilisable (que les png24 ne s'affichent pas correctement), mais simplement très moche. Donc j'hésite... Votre avis ? Merci