Reprise du message précédent :

Tu parles de ca:
http://java.sun.com/j2se/1.4.2/doc [...] e(boolean)
ou de ca:
http://bugs.sun.com/bugdatabase/vi [...] id=6545684

 
le premier je pense, ça fait un moment que je n'y ai plus touché...
j'utilise un schema dans une de mes applis, et il me semble me souvenir que j'ai du filtrer les nodes texte à la main...
 
le setIgnoringElementContentWhitespace avait aucun effet...
 
 
 

HEP
Quelqu'un connait un bon script en PHP qui "colorifie" du code... JavaScript ?
Merci  

la balise [ code ] [/code]

ca a l'air cool ca  
 
jvais mater de plus près merci  

Geshi (c'est ce qu'utilise le forum même si joce refuse de le mettre à jour), ou alors tu fais tourner Pygments séparément (c'est ce que fait Github)

tiens, j'viens d'me rendre compte que le site sur lequel je bosse, 80 requetes = 80 connections à la base
 
du genre il a une classe SQL, avec la connection dans le constructeur, et une nouvelle instance pour chaque requête  

 
Oh putain

Hello,
 
Je recherche le nom/lien d'un bug tracker (web based) dont j'avais vu défiler le nom quelque part sur ce forum (ça au moins j'en suis sûr que c'était ici). Ça m'intéresserait, car je trouve que l'interface était simple et plutôt bien faite (ce qui exclu d'office bugzilla ).
 
Je sais aussi que ce n'était pas mantis. Et c'est hélas un peu près tout.
 
Ouais, je sais, c'est vague, mais même après avoir passé en revu la plupart des liens dans Wikipedia (ou google image pour "bug tracker" ), impossible de remettre la main dessus. Alors dès fois que quelqu'un se souvienne d'une liste de lien posté ici ou là ....

jira ?

trac ?

Hmm, nan ce n'est pas ceux là (ni jira, ni trac).
 
Personne ne se souvient d'avoir vu une discussion sur blabla@web ? Rhâaa, j'y crois pas ça fait deux jours que je cherche ce lien  

trac et jira ne te conviennent pas ?

redmine?

Ce n'est pas redmine non plus    
 
Bon je vais arrêter de me prendre la tête, je viens encore de passer 1 heure à fouiller blabla@web, nada. Je sens que j'aurais mis en prod mantis ou trac, c'est là que le nom va me revenir  (ce n'est pas qu'ils ne me conviennent pas, loin de là, mais vu le choix de bug tracker qu'il y a, j'aimerais vraiment tester ceux avec qui j'ai eu un bon feeling).
 
P...n, je ne me souviens même plus de quelle machine j'ai vue cette URL, histoire de fouiller dans mon historique.

mantis?

Question bête, est-ce que c'est pas intéressant d'avoir ce type de script en javascript justement ? Histoire de décharger le serveur. On voit comme le serveur HFR peut en chier avec les pages pleines de codes !

Sisi c'est super ça fait ramer les clients, ça a plus de chances de planter et les gens qui n'ont pas le je activé n'ont pas de coloration s'trop bien.

1) Ouais mais z'ont pas à attendre 30 secondes pour que la page soit générées, on peut faire une petite animation d'attente et en attendant ils peuvent consulter le reste de la page, et on peut meme n'activer la coloration qu'à leur demande via un bouton
2) mouais, z'auront qu'à relancer le bouzin !
3) Bin on leur demande de l'activer si ils veulent la voir

Ca peut avoir des avantages en plus de décharger le serveur

 
Nan mais faut pas générer la coloration à chaque affichage hein

Faire fuir les utilisateurs ?

Bonne remarque en effet, mais je n'ai pas énormement de code (qq lignes ici ou là) et je ne pense pas que ca va avoir un impact monumental sur le serveur.
Mais bon on sait jamais, donc ca reste à creuser évidemment, avec des trucs comme Google Prettify par exemple.

Ca permet d'économiser de la bande passante aussi

Dans un peu le même style, ça me fait penser à gTalk intégré dans google mail où, contrairement aux forums classiques, les smileys sont traduits en image par javascript coté client plutôt que coté serveur !

Bof, ça marche bien http://google-code-prettify.google [...] ml#issue22
 

 
Ca depend, dans mon cas précis le code en question provient d'un fichier XML généré par JSdoc, qui contient toutes les infos qui vont bien (bribe de code, etc...).
Or l'idée est justement de pouvoir généré seulement le XML, et laisser la mise en forme se faire tte seule, donc oui la coloration syntaxique se ferait à chaque génération (appel).
Il est clair que potentiellement ca peut foutre le boxon niveau perf, c'est pour ca que la coloration du coté client est une solution à étudier (et si le client à désactiver le JS, il suffit de lui dire de le réactiver ou de proposer au pire une version au format 1995 ... Mais bon dans mon cas il s'agit d'une lib JS, donc ca serait un peu ballot de désactiver le JS ).
L'autre solution serait tout simplement de conserver un cache du docuement généré, basé sur la dernière modif du fichier XML, comme on ferait pour une bete gallerie d'images...

Si t'as un site avec 3 geeks dessus c'est clair que non, mais dans certains cas ça peut ne pas etre négligeable ...

J'sais pu quelle boite (genre Amazon) disait: 0.1 seconde de gagnée au chargement de la page c'est X clients en plus !

Fin bref, c'est pas ce que tu penses = c'est pourri, blabla

1. Au lieu d'attendre 30s (...) que la page se charge ils attendront 30s que leur browser ne soit plus freezé, trop cool
2. Les caches et la dénorm ça existe, tu fais ta coloration une fois et tu stockes le résultat

Si t'as pas envie que tes utilisateurs aient de coloration suffit de pas la mettre tu sais

Non.

Pas de bol, ton JS ralentit le chargement de la page pour l'utilisateur au final

Si t'as des problèmes de perfs, tu crées ta colorisation à l'edit, paf tu génères ta couleur une seule fois (tu peux même le gérer via une taskqueue si ça t'amuse) et tu balances direct ta page HTML à l'utilisateur

Sauf qu'on peut proposer la coloration syntaxique sur le bout de code uniquement si l'utilisateur le souhaite vie un bouton par exemple:
1) la page n'est pas bloquée au chargement ni plus longue à chargée
2) dans certains cas, il est possible qu'une partie des utilisateurs s'osef du bout de code et/ou de la coloration syntaxique
3) Si l'utilisateur préfère activer le javascript pour que ça soit plus lisible il peut le faire en cliquant sur un bouton

Ca me semble avantageux dans certains cas J'dis pas qu'il faut utiliser ce procédé pour tout site qui contient du code non plus ... Mais que dans certains cas ça peut etre une solution viable !

 
Nan mais explique nous l'intérêt de proposer de la coloration "à la demande" ?

Ca peut permettre de proposer différentes coloration suivant le user, ou que le user applique la bonne coloration si la syntaxe du code est mal/pas détectée, lorsque du code est intégré dans un autre code ( genre PHP + HTML ) ça peut permettre d'highlighter à la volée correctement soit le HTML, soit le PHP etc ...

Comme je l'ai dit au dessus, si tu veux pas coloriser le code autant rien mettre du tout c'est plus simple pour tout le monde

Non et puis la solution de "mm mon truc est super lent mais si on le désactive paf c'est rapide" (no shit), c'est pas une solution

CSS

Tu demandes à l'utilisateur de préciser le langage et done

Non mais avec une vraie lib de colo' t'as les deux en même temps tu sais

Arrete de chercher des cas d'utilisation abracadabrantesque à ton idée de merde. Les inconvénients de ton idée sont trop énormes pour justifier son utilisation.

ok

Sinon j'suis à moins de 100ms pour générer la page complete au dessus ( http://google-code-prettify.google [...] ml#issue22 ) sous chrome

Enfin j'dis ça j'dis rien

 
bugzilla, confluence...

Ça dépend de la date :

• Si date arbitraire, un calendrier est sympathique
• Si date de naissance, un seul input suffit (la date est souvent "hard-codée" dans les doigts des utilisateurs, ayant l'habitude de la taper)