Salut salut !
 
Alors voilà, j'ai une jsp qui va générer du code html. Vous imaginez bien le bordel que ça va être si chaque table (il peut y en avoir plusieurs centaines l'une sous l'autre) doit être positionnée en absolu.
Je cherche tout simplement à ce qu'elles soient collées.
 
Par ex :  

 
En l'occurence, Line.gif est une ligne verticale que je veux visuellement continue sur les 3 tables...
Le border-collapse m'a bien réduit l'espace entre les tables mais pas assez... J'ai essayé border=0, margin=0 et même les 3 à la fois mais j'arrive pas à faire mieux...
 
Quelqu'un a une idée ?
 
Merci bien

Fais comme tout le monde : utilse des DIV au lieu des TABLE
 
Et puis les liens http://... pour les images : bravo c'est très propre  

Fraisouille > Tu pourrais essayer aussi border-spacing et padding pour supprimer l'espace.
 
Smaragdus > Faut arrêter avec les div et les tables sans savoir de quoi on parle hein ! Des fois, les tableaux c'est utile...genre pour faire des...tableaux !! La présomption d'innocence ça existe, y'a pas flagrant délit d'utilisation de tableau pour faire de mise en page ici.
Et c'est quoi le problème avec les lien http:// pour les images?

 
si tu utilises cette méthode pour ton site bah après tu dois tout changer
 
<img src="images/lol.jpg" alt="" />
est mieu que
<img src="http://www.ton_site.info/images/lol.jpg" alt="" />
 
et plus rapide je crois ^^

il faut ajouter dans chaque table cellpadding="0" cellspacing="0"
 
et puis la mise en page en tableau chapeau, tu aurais pu faire pire quanbd même nan ?

1) C'est juste un premier jet au brouillon pour essayer de voir ce que ça donne. Pas la peine de coder le code générant tout ça et de faire une belle mise en page si j'arrive pas à péter ces espaces... En plus, avoir aucune mise en page me permet de mieux localiser d'où vient le problème. Là, je sais que le soucis ne vient pas de ma mise à page
2) Pourquoi des tables ? Parce que les données vont m'arriver dans un tableau et que j'ai pas envie de multiplier les divs. Le faire en table limite le code côté java et allège le code côté javascript. Déjà qu'on sature les machines avec notre code js...
3) Les adresses des images, c'est ce que j'ai récupéré du code actuel (qui génère des divs d'ailleurs) et ces adresses sont générées. Le protocole est généré (http ou https), le nom de la machine, le port, le contexte le sont aussi. Y'a que le chemin et le nom de l'image qui sont en dur.
4) Le spacing n'a rien fait mais le padding a fait bon effet. J'ai pas le code sous les yeux là mais padding:0 dans le css et zou !
5) Merci

1) Oki
2) Si ce sont des données tabulaires (liste de personnes, résultats loto, pronostiques, résultats sondage (ca depend desquels)) alors tu les laisses en tableau
3) cf au dessus
4) no problemo
5) de rien appelle moi Dieu

Et bien à bientôt Dieu

 
Si ce sont des données tabulaires => TABLE
Si c'est pour faire de la mise en page => DIV
 
Y a pas à discuter, c'est comme ça un point c'est tout, les TABLE n'ont jamais été prévues pour faire de la mise en page au pixel près, d'où tes problèmes.
 
Et puisque tu parles de charges serveur, le code avec des div est bien plus leger qu'avec des table.

Nan pas que DIV ya pleins d'autres balises

 
Quelle découverte tu m'apprends  
De même, t'as remarqué que pour TABLE, j'ai pas précisé qu'il fallait utiliser aussi TR, TH et TD ?  (mais j'aurais du préciser vu qu'il y a toujours un pinailleur )

THEAD, TBODY et TFOOT aussi

Côté serveur ????
Euh... L'HTML et le javascript sont exécutés côté client... Côté serveur, ça ne change strictement rien que ce soit des divs ou des tables...

on parle surtout de la bande passante consommée.
On voit souvent des pages web qui font 45ko en HTML alors qu'en xHTML/CSS proprement bien fait, les pages ne font que 10ko

Je vois toujours pas le rapport avec la charge côté serveur...
 
Quant à la taille des pages, c'est pas un objectif important. L'important, c'est qu'on ait du code java plus facilement maintenable et du code html / javascript plus souple vis à vis des possibilités de présentation des données. On refait le code pour mieux présenter nos données et on cherche à utiliser des tables pour faciliter le codage du javascript et du java qui va pisser les pages html.
 
Enfin bref, le sujet est clos. Merci pour votre aide les gars, et Smaragdus, essaie de prendre les gens de moins haut, c'est pas très agréable là...

 
Si tu savais de quoi tu parles tu saurais qu'une page avec plein de tables dans tous les sens est bien plus grosse en poids et donc à générer en jsp qu'une mise en page avec div + CSS à part. Dois-je te rappeler que ton html est généré par le parseur jsp ?

Le problème, c'est que c'est toi qui raconte n'importe quoi... On s'en contre fout du php ! Qui a parlé de php ? Moi peut-être ?

LOL stembrouille!

A tiens, il a édité son post... C'est mieux comme ça, ça a plus de sens que son histoire de php...
 
Bref, si tu veux tout savoir, le code html est construit par un Tag. La jsp se contente de recracher une grosse chaîne de caractère en gros. Alors que la chaîne contienne des divs ou des tables, on s'en fout un peu côté serveur.
 
Tu sais, je connais mieux mon code que toi

Ho, un bon vieux débat table vs div, ça fesait longtemps.

Ben non, même pas, y'a pas de débat. Smaragdus raconte des bêtises et en plus, il me prend de haut et il est désagréable... Et vu les bêtises qu'il sort, le "débat" va tourner court... Quand on croit que le code html est parsé côté serveur, on n'a pas trop de crédibilité

 
Ah en plus tu sais pas lire ? Le gars il code encore sa mise en page avec des tables et il se permet de parler de crédibilité. Je te rappelle ma phrase un peu plus haut :
 

 
Arrete de t'enfoncer, tu sais plus quoi sortir pour justifier ton code HTML qui date des années 80
Et bizarrement, tu n'as rien dit sur le fait que la bande passante occupée par tes pages codées à l'arrache est bien plus grosse. Un trou de mémoire ?

...
Pourquoi tu veux que je me justifie ? J'ai rien à justifier...
 
J'ai ma réponse, le sujet est clos.

Faisait  

 
faisait
Pas de majuscule en milieu de phrase

pas de TABLE pour la mise en page

Le choix a déjà été fait par les hautes instances de l'équipe IHM. Pas de mon ressort. On verra bien ce que ça va donner...

Ah dans ces cas là, je compatis  

Je compatis et ai pitié de toi et j'espère que tu ne continueras pas à faire du code de porc à cause de ces incapables de l'équipe IHM

C'est pas le fait d'utiliser des tables ou des divs qui rend le code dégueux... C'est toute l'architecture qui est crade...
On a une base Oracle qui est attaquées par un noyau codé en C et ProC. Par dessus une couche C++ qui est attaquée par l'ihm via un bus Corba. L'ihm est composée d'un gros enchevêtrement de 1200 classes plus ou moins bien commentées, plutôt moins bien qu'autre chose d'ailleurs... Y'a une grosse partie des traitements qui sont fait côté client avec du javascript (qui est une grosse merde pas maintenable et surtout pas efficace, surtout quand y'a un getElementById toutes les 2 lignes). Tu rajoutes à ça une gestion des exceptions quasi inexistante et tu as un code sale...
La refonte de la partie présentation des fiches s'inscrit dans le nettoyage du code pour avoir quelque chose de plus facile à maintenir. On a pas trop d'objectif en terme de perfs. A l'heure actuelle, il faut 10 secondes pour afficher 3000 fiches. Pour être user friendly, il faudrait descendre à 3 secondes max mais faut pas rêver, faudrait laisser tomber l'html / js pour passer à une applet. Le plus gros du temps correspond au code javascript qui s'exécute sur le client.
En utilisant bien les événements et en évitant les getElementById, on devrait réussir à gagner en perfs mais c'est pas sûr et c'est pas le plus important...

Le plus simple serait directement d'attaquer la base oracle via une classe propre ou un prog C/C++ qui serait lui attaqué par l'IHM html/Js
 
putain c'est mal chié ton truc en entreprise, démissionne vite avant qu'il ne soit trop tard.
 
en tout cas bonne chance

Ben c'est une appli énorme qui a 10 ans d'existance... Elle a été développée couche par couche... Et pas le temps de tout refaire à zéro, c'est trop énorme... Niveau fonctionnel, c'est un peu le même principe que SAP. Tout est générique et paramétrable, des données des fiches aux workflow de ces fiches...

Un gros caca avec pleins de trous partout et dont le code est à 50% fait par des stagiaires ?

Non, plutôt par des gars qui avaient leur façon à eux de coder... Genre un neuneu qui se servait de long comme des pointeurs... Je te laisse imaginer le bordel quand on est passés en 64-bits... Ça explosait de partout... Puis y'a aussi le classique "c'est tellement évident pour moi qui ait conçu cette fonctionnalité que je ne vais pas mettre de commentaires"... Tu rajoutes une pointe de "Le client modifie les specs 3 jours avant la livraison donc on pose un bout de scotch" et voilà...
 
C'est comme dans une bonne partie des SSII... Sauf que comme on est mi SSII, mi éditeurs, ben ça amplifie les problèmes...

putain faudait inventer une prime au code commenté dans les entreprises.
 
jfais parfois 10 lignes de commentaires pour 5 lignes de codes.
C'est con mais au moins je m'y retrouve

Ben ouais, c'est ce qu'on fait depuis un an à peu prêt... Avec des docs de conception et tout ! C'est la révolution ! Mais bon, c'est que pour les nouveaux trucs... Pour l'ancien code, c'est un peu mort... Par moment, on ne sait même pas à quoi il sert... T'as de belles fonctions de 2 ou 3 mille lignes sans aucun commentaire (mis à part les commentaires automatiques (super utile...)). De temps en temps, quand on tombe sur des fonctions comme ça, on regarde un peu dans le reste du code si elle est encore utilisée et si elle n'est pas appelée, zou !!! A la poubelle ! Ça nous fait presque bander quand on fait ça

combien de fois j'ai vu ca dans mon ancienne boite, c'était à se pisser dessus de voir des fonctions JS de 2000 lignes alors qu'en 200 lignes tu faisait pareil

Ben là, c'est surtout qu'il aurait fallut faire des petites fonctions bien découpées quitte à rallonger la pile d'appels... Qu'est-ce qu'on gagne en lisibilité avec du code bien organisé... Mais c'est clair qu'on peut bazarder un bon paquet de code... Le nombre de fois où j'ai vu du code dupliqué dans une fonction !