Reprise du message précédent :
Savez vous si il éxiste un topic référencement sur HFR ?
 
XaT

http://www.velo.toulouse.fr/les_st [...] on/(id)/1#
 
Comment puis-je récuperer les informations sur les stations ?  
Je voudrais juste récuperer la contenance, et les velo dispo, et les places libres.
 
XaT

http://www.velo.toulouse.fr/service/stationdetails/13

parce que comme un couillon tu as spécifié une largeur a chaque élément qui se retrrouve a droite de l'image.
Et comme tu leurs fous une largeur, tu leurs applique le haslayout (IE only), ce qui fait qu'ils se retrouvent pile-poil à coté de l'image (au lieu de démarrer à l'offset 0 du bloc conteneur (comportement naturel des flottant.
MAIS comme leur width est plus grande que la place qui leur est aloué, ils l'ont dans le cul et ils retournent en dessous de l'image.
 
PS : vire ces largeurs qui sont TOTALEMENT INUTILE.
C'est une manie chez les gens de poser des largeurs à tout bout de champ en CSS alors qu'il n'y a strictement pas besoin quand les éléments sont dans leur conteneur

C'est marrant leur liste de critères, ya même pas la lisibilité & compatibilité avec les usages des autres langages, par contre ya le nombre de caractères...

 
Et oui, mais si je mets pas de largeur, toutes les images du bloc news (excepté l'image de la news) se retrouve à droite de l'image de la news sous IE, ça avance un peu mon problème mais c'est toujours pas ça.

zoom:1 sur chaque element
 
mais franchement, tu aurais du les englober d'un div qui aurait eu du contexte de formatage, et ainsi pas de pb

 
Je suis pas sûr de tout avoir compris  
 
Le mieux aurait été de mettre tout le contenu de ma news dans un div (images et texte) sauf l'image à gauche ?
 
Et le zoom: 1 je dois le mettre sur tous mes blocs sauf sur celui de l'image ?

sur le div

On parlait il y a quelques temps du SELECT *
 
Ca pourrait peut-être en intéresser quelques uns :
http://www.parseerror.com/sql/select*isevil.html

Pfff, encore un avis biaisé

 
il reste pas des masses d'arguments quand derrière tu lis tes colonnes via leur nom et pas via leur position

Nan, plus tôt tu détectes le problème, mieux c'est conçu => si l'erreur est détectée lors de la requete c'est mieux que lors de la lecture des résultats

C'est mieux selon quel critère ?

rs = sqlMachinTruc("SELECT * FROM articles" );
if (rs == null) {
  throw "epic fail !";
}
while (!rs.eof()) {
  title = rs.get("title" );
  text = rs.get("text" );
  rs.advance();
}

rs = sqlMachinTruc("SELECT text, title FROM articles" );
if (rs == null) {
  throw "epic fail !";
}
while (!rs.eof()) {
  title = rs.get(0);
  text = rs.get(1);
  rs.advance();
}

Pour savoir à quoi correspondent 0 et 1, faut aller lire plus haut dans le code. Et si on change la requète pour ajouter un truc, il faut mettre a jour ces valeurs. Niveau lisibilité et non-répétition, le premier me semble gagnant.
Je dis pas que le * est bien, je dis juste que l'accès par numéro de colonne est une pratique aussi bancale que l'utilisation de l'*, et que donc tout les arguments anti-* qui reposent sur l'utilisation de ces numéros sont bancales.

 
zoom: 1 sur .news ne change rien

ça laisse 4 arguments valides sur 5 dans l'article quand même.
 
EDIT: IWH P666

 
Euh non,
 
Self-Documentation Lost : la doc elle est à l'utilisation du resultset, cf le sample de code que j'ai posté.
Broken Contract : ça va péter à l'utilisation du resultset, aucun bug caché.
Size Matters : c'est le seul argument valable.
Out Of Order : c'est la même chose que broken contract, une permutation de champs c'est pareil qu'un champ renommé.
Don't Do It : c'est pas un argument.

1)la requête n'est pas toujours à coté du code qui traite le resultset
2) pas forcement. En ADO par ex. ça ne fera pas d'erreur et ça te renverra null si tu demandes un champs qui n'est pas renvoyé dans la requête.
3)oups, j'ai mal compté

 
1) Dans ce cas, le code qui traite le resultset reçoit "un resultset *" et y'a rien qui garantisse que ce resultset ait été créé avec les champs que le code attends. Si tu commence à mettre de la distance entre l'exécution de la requète et l'utilisation du résultat (via des appels de fonction, des ifs de 500km de long, ...) alors rien ne sert d'avoir une requète autodocumentée, au moment ou tu utilise le resultset tu n'a plus cette information sous les yeux.
2) c'est sur, si t'as un langage/outil/api qui a décidé de pas faire la moindre vérification, t'es oubligé de tout faire coté sgbd. Tu fais quoi le jour ou ton sgbd décide de renvoyer null quand tu select un champ qui existe pas ? (sinon, ça renvoie quoi si tu met un n° de champ plus grand que le nombre de champs ?  )
 
* sauf si t'es dans un langage très malin qui en fonction des gets faits sur le resultset infère un type implicite sous la forme d'un tuple représentant les champs attendus, et dans ce cas, c'est le type inféré du resultset qui décide de la liste des champs à requéter, c'est la fête \o/

IWH \o/

rs = sqlMachinTruc("SELECT * FROM articles" );
if (rs == null) {
  throw "epic fail !";
}
while (!rs.eof()) {
  title = rs.get("title" );
  text = rs.get("text" );
  rs.advance();
}

rs = sqlMachinTruc("SELECT text, title FROM articles" );
if (rs == null) {
  throw "epic fail !";
}
while (!rs.eof()) {
  title = rs.get(0);
  text = rs.get(1);
  rs.advance();
}

Ce n'est pas parceque tu n'utilise pas le * que tu es OBLIGE de te baser sur l'ordre des résultat...
Tu dispose toujours du nom de ta colonne pour acceder au resultat (et en même temps tu le maitrise vraiment en pouvant mettre un "as nom_custom" )

Après si tu veux te baser sur l'ordre, tu fais ce que tu veux mais c'est une autre histoire

 
Je disais juste que les arguments anti-* reposent sur le fait d'utiliser l'ordre des résultats, et sont donc du coup pas systématiquement valides, pas que la non-utilisation de l'ordre des résultats dépendait de la non-utilisation d'autre chose que l'*, et de même pour l'inverse et le contraire, mais pas pour l'opposé  .

Bon bref, il faut utiliser * avec des numéros, on a compris

1) L'"autodocumentation" sert aussi pour l'écriture ou la modification de la clause where de ta requête
2) Je te parle d'un cas réel et assez répandu, pas d'une élucubration de développeur paranoïaque

Ce qui est complètement faux

Il y a des frameworks PHP qui intègrent l'i18n (surtout dans le routage d'url) ?
 
(IWH)

ya un truc dans zend framework, il me semble, mais je sais pas exactement ce que ça fait

http://www.betaversion.org/~stefano/linotype/news/169/

IWH  \o/

IWH SATAN !

IWH, et ça ça vaut bien des heures supp pour le hellfest

IWH

rue89.com, j'y vais, y a un genre de siouper redirection et j'arrive sur une page blanche:
http://adtech.panthercustomer.com/ [...] board.html
et jsuis bloqué là

bravo les dev

Tu peux le faire via un fichier htaccess
 
http://httpd.apache.org/docs/2.0/mod/mod_expires.html
http://kevin.vanzonneveld.net/tech [...] _htaccess/

Tu peux le faire en javascript.

à la racine c'est pris en compte pour tout ce qu'il y a en-dessous, normalement.

666 Pages sa porte la poisse

ça ça dépend de tes fréquentations

IWH \o/