Reprise du message précédent :

va boire de l'arsenic

ba quoi c'est classe je trouve

 
Ah ouais!
 
Bah en fait, gérer par des span revient à suivre une règle du genre:
 
"A chaque fois que tu fermes une balise, quelle qu'elle soit, contente toi de fermer la dernière balise ouverte"
 
Mais ça rend le code beaucoup plus lourd (pour le stockage)
 
Bon, je vais voir comment je peux m'y prendre...
 
Il me reste mon problème de savoir comment gérer les sauts de ligne... => nouveau <p> ou simple <br />?

En plus c'est WYSINWYG compliant  

Non, parce que...
 

En l'occurence, ils peuvent être écrit par ma femme ou des connaissances à elle, les articles sur la Gloriette sont souvent le résultat de 2/3 ou 4 personnes.
Et pourquoi ne pas utiliser le HTML directement ?
Bah parce que [videoflash=toto.swf] est plus simple que tout le code de remplacement qui se trouve derrière pour mettre une image cliquable qui ouvre un pop avec une vidéo par exemple ou [imgc]chemindemonimage.gif[/imgc] est plus simple que <div align="center"><img src="lechemin".....
 

Pour la mise en page des paragraphes, dans les textes, les paragraphes sont déclarés par des [p][/p], mais j'aurais pu faire encore plus simple et récupérer les retour à la ligne vide.
L'avantage du bbcode sur le HTML, c'est que par exemple, si aujourd'hui, pour mettre un gras j'utilise toto, aujourd'hui, je le transformerais pas <b>toto</b>, si demain je veux en faire un PDF, je le transformerais par le code nécessaire, si dans 10 ans, je veux le transformer en un autre langage, il suffira que je fasse un parser qui me converti mon bbcode perso, dans le cas du <b>, ce n'est pas évident à cerner, mais pour du code plus complexe, comme [fla=monfichier.swf width=320 height=200], en HTML, c'est 5 lignes de codes, bonjour la complexité pour arriver à le parser correctement.

Pour donner un exemple concret :
Quand vous allez sur cet article :
http://www.gloriette-artemis.net/articles_11.html
 
Le code du fichier texte ressemble à ça :

Avec une toute petite ligne [video qui sera remplacé par une image annonçant une vidéo avec ouverture de popup d'une page contenant un swf standard qui récupère la vidéo en question et l'affichage dans le lecteur.

 
D'acc, merci pour les différentes réponses...
 
Pour les paragraphes, je pense que je vais me contenter d'utiliser des <br />, cad remplacer tous mes "\n" par des <br /> et basta, ça sera plus intuitif pour l'utilisateur...
 
En ce qui cocnerne la nécessité de ne pas directement utiliser du html, je comprends aussi, tu veux utiliser un code plus générique, plus universel, donc plus portable...
 
Sinon, ou est ce que je pourais trouver un exemple assez complet, cad gérant le coté client, avec gestion Javascript pour mettre le BBCode en place, puis la gestion de la transfo du BB Code en html (coté serveur donc), de préférence en PHP?

exactement
c'est d'ailleurs pour ca que c'est du WYSINWYG

Pour la transfo bbcode vers HTML, fait une recherche dans ce topic, y'a déjà eu des exemples dans ce topic.
Pour le js de génération des bbcode, clique droit, afficher la source.

Bonne idée.
 
Par contre, ce n'est pas comme ça ici...  

Ouais ben en attendant ça répond pas aux autres points

On dirait du TeX en moins lisible

Ben non, mauvaise idée puisque le rendu de l'exemple devient alors
 
Bonjour et au revoir
 
ce qui pour le coup n'a plus aucun rapport avec ce qui était voulu
 
Et ça ne marche que pour les trucs de mise en forme simple

 
Bah bien entendu, j'ai déja fait click droit pour voir le JS.
Mais bon, je préfèrerais trouver un ensemble JS + code PHP qui fasse ça.
 
Sinon, je trouve que sur le forum hfr, la fonction "visualiser" est très efficace... (mais ça appelle du code sur leur serveur...)
 
Bon, je vais jeter un oeil...
 
Sinon, j'ai trouvé ça également qui a l'air pas mal: http://freetextbox.com/demos/
 
 

Pourquoi utiliser du BBCode ?
 
Parce qu'il est universel à tout le site.
 
du coup, je peux faire une news sur le site ou reprendre la première page d'un article faire un copier coller directement dans mon forum et j'aurais une mise en page identique.
 
Par exemple, si je fais un copier/coller sur mon forum avec [imgr]monimage.gif[/imgr], comme c'est le même BBcode, je me retrouverais avec une image en float:right même sur mon forum.
 
Bon, certains me diront que du coup mon BBcode forum doit être énorme, mais pas tant que ça, ça rajoute une dizaine de regexp à traiter maxi.
 
Et du coup, je peux mettre les même smileys dans mes articles que sur mon forum.
 
Les langages que tu recommandes sont (en apparence, j'ai pas approfondis) trop puissant pour une dizaine de possibilités en plus qu'un bbcode classique (tel qu'ici).  

Oui mais au moins c'est valide et le rédacteur du message voit tout de suite qu'il a merdé, donc cay bien.

Suffit de mettre un vrai parseur et un validateur au lieu de regex pas faites pour ça et d'afficher un beau message d'erreur (ou de corriger proprement le code) et paf

Clair qu'une bonne lib ne faisant que ça dans un bon langage serait je pense beaucoup mieux ^_^

ca existe pas quelque part ?

Allez, vas-y, le PHP "cay trop dla merde" le retour.    

Hého, je ne souhaite pas lancer de polémique.
 
Mon besoin reste assez simple tout de même.
 
Vous avez vu ce genre de truc: http://freetextbox.com/demos/ (fait en ASP.Net malheureusement).
 
En version ultra simplifiée, c'est ce qu'uoil me faudrait, car ça offre un retour immédiat à l'utilisateur sur sa mise en forme. Pour le coup, il a l'impression d'utiliser un traitemnt de texte simplifié.

Ca n'a rien à voir. Même avec PHP tu peux te faire un parser correct. Il suffirait de faire un tidy sur le bbcode avant l'insertion dans la db, histoire de gagner du temps à chaque affichage. Mais bon, ça demande juste de se casser un peu plus la tête que de faire une quinzaine de regexp.

de toutes façons, le PHP cay trop dla merde

Allez, arrêtons ces broutilles...
 
Perso, je connais suffisamment bien ces langages de scripts que sont PHP et Perl (Perl étant quand même plus évolué que PHPpour tout ce qui est manipulation de données) pour être convaincu qu'ils offrent tout ce qu'il faut pour faire ce que l'on veut avec nos données...

Dans ce cas, ça m'arrangerait si tu pouvais me donner le nom d'une lib Perl qui manipule de l'OWL.

 
Ca ne va sans doute pas te satisfaire (et je ne connais me^me pas l'OWL) mais vas voir ici: http://search.cpan.org/search?query=OWL&mode=all
 
On ne parle pas ici de savoir si tel langage est capable de manaer tel ou tel truc, mais simplement de se dire que le PHP peut largement permettre de pallier aux besoins requis (en tout cas, aux miens).
 
ON va éviter de troller et de transformer le topic en guéguerre.

T'es gentil mais faut arrêter la drogue là, sinon il n'y aura bientôt plus d'espoir
 
J'ai dit qu'il fallait faire un parseur au lieu d'utiliser des REs pas faites pour ça, ce sont deux mécanismes totalement indépendants du langage d'implémentation, et si taper sur les REs (ce que je ne fais même pas, les REs sont faites pour du pattern matching pas des parseurs c'est tout) c'est taper sur un langage, c'est PERL et sûrement pas PHP

http://search.cpan.org/~cmungall/g [...] ers/owl.pm

 
Bon, faire un vrai parser, c'est peut être au delà de mes moyens et de mes compétences (il faudrait vraiment que je m'y plonge, mais je n'en ai vraiment pas le temps et l'énergie).
Donc, ça passera nécessairement par des REs.
 
Et je suis d'accord qu'il n'y a pas plus évolué que le Perl pour les REs (qui est à des années lumière d'avance dans ce domaine), et d'ialleurs les REs du PHP sont inspirées de celles du Perl.
 
Mais bon, pour les REs, PHP m'ira très bien

Oui mais non, je parlais d'un véritable outil. Ceux de CPAN je les connais déjà, c'est juste du foutage de gueule.

 
Tu n'es pas un peu relou sur les bords toi, hein?
D'une part, je dis que je ne souhaite pas lancer de polémique sur PHP Vs Perl (moi même ayant un background Perl, j'accepte aujourd'hui de travailler sur PHP, sans faire l'apologie de l'un ou l'autre), d'autre part, tu n'as en rien participé à mon problème. Tui n'es donc venu que pour lancer une polémique à laquelle nul de ne veut participer.
 
Enfin, en ce qui concerne la lacune de Perl vis à vis de OWL (et que CPan, c'est du foutage de gueule), bah...pourquoi tu ne nous écrirais pas une belle librairie, tiens? Je te garantis que Perl dispose de tous les outils pour le faire, sans problème... Allez, au boulot !
 

Ce serait surtout complètement inutile, surtout dans un environnement Web.
Développer un parser complet juste pour rajouter quelques bbcodes, c'est comme quelqu'un qui achèterait un IPB et virait toutes les préférences dans l'administration pour faire son livre d'or.

 
Bah rajouter quelques BBCodes ne reviendrait il pas à rajouter quelles REs, tout simplement?
 
Je pense qu' lintérêt du parseur est pour le puriste, voulant éviter toute imbrication foireuse de tags html...
 

Si si, tout à fait.
 

Tout à fait, donc la solution Joce était viable, pas d'imbrication mauvaise de code.  
Ha oui mais non, le puriste n'aimera pas car ce n'est pas sémantiquement correcte.
[HS]
Les même puriste qui s'entêtent à répéter que <b> et <i> sont déprécier au profil de <strong> et <em> alors que les puristes de la typographie dans mon genre trouvent que c'est une aberration et pour cause.
Finalement, on n'est tous puristes de quelquechose.
[/HS]

Bah la solution de Joce, je la trouve géniale, car elle rend le code toalement propre, mais par contre, elle a tendace à bouffer des infos. Contrairement à un bon parseur qui pourrait, je pense, comprendre ce que cherchait à faire l'auteur lorsqu'il entrelace ses balises...
Par contre, je ne vois pas en quoi sa solution n'est pas sémantiquement correcte?
 
 

Bah c'est vrai que les <b> et <I> ont tendance à inclure directement le style dans le code HTML alors que cai pas bien (contrairement à <strong> et <em> qui donnent simpelment une info su r l'intention de l'auteur, sans donner le style)
 
Pour ma part, je pense qu'il faut savoir être pragmatique et je préfère cent fois la compacité d'un <b> et d'un <i>... Et tant pis pour la beauté théorique du truc...
 
C'est un ppeu comme avec les CSS, et le design complet d'un site web en <div> et autres balises de blocs. C'est vrai que c'est comme ça qu'il faudrait faire, et je me suis évertué à apprendre les choses comme ça, mais franchement, quelle galère pour obtenir ce que l'on veut (sans parler du fait qu'il y a toujours des bugs à droite et à gauche selon les navigateurs, et qu'on passe notre temps à appliquers des hacks). Finalement, les tables simplifient vachement la vie, même si le code est plus lours et sémantiquement mauvais... Bah tant pis, moi, je vai me mettre aux tables ou faire un mix des deux, mais je vais arrêter de me priver....

un compromis parfois pratique c'est un tableau "général" pour les trucs méga casse couille genre design en 3 colonnes auto-adaptives etc... , et tout les trucs dedans avec du code propre.
 
The-Shadow : tu peut détailler ton avis sur b / i / strong / em stp ?

Bah, la sémantique, c'est d'utiliser les balises adéquate, utiliser un <hx> au lieu d'un <div id="titre">, etc.
Donc <span class="b"> n'est pas adapté.
 

Ce n'est pas une question de compacité pour moi, c'est juste que le gras et l'italique sont des notions typographiques réelles qui font parti de l'enrichissement typographique du contenu et n'ont rien à faire dans un autre contexte.
Mais c'est un peu hors sujet, je voulais juste insister sur le fait qu'on a tous quelquechose à redire mais que je ne passe pas mon temps à le rappeler aux gens.
 
 

Je suis d'accord, comme j'expliquais à quelqu'un récemment qui me demandais si j'étais capable de faire un design CSS/W3C Compliant, oui, j'en suis capable, mais je dois penser mon design CSS, hors, en tant que maquettiste, je passe souvent par un croquis papier sans m'inquiéter de la difficulté de réalisation.

 
une <div id="titre"> n'est pas bon, mais par contre, pourquoi pas un <div class="titre"> ne le serait pas?
 
Pour moi, ça reste strictement équivalent à un <hx>. C'est un peu un <hx> custom made, un style personnalisé...
 
Enfin bon, je ne dosi pas être assez puriste...

 
Ouais...
 
Je n'ai pas enore trop étudié le truc, mais je pense que je vais être plus flexible dans ma mnière de penser (sans pour autant en arriver à utiliser un outil de type WYSIWYG).
 
Mais utiliser des tableaux peut s'avérer très sympa, srutout que les <td> sont, sous tous les nnavigateurs, d'excellents conteneurs, sans trop de problèmes de compatibilité...

Parce que les hx c'est pas uniquement un style, c'est avant tout un élément qui dit "titre de niveau X", et qui le dira avec ou sans style dessus.
 
Un div#title ou un div.title ça dit rien du tout

 
Oki, tu as raison. Il faut toujours que je pense à memettre à la plce de l'interprêteur qui lit du code html sans en interprêter le style... Il comprendrait le h1, mais pas le div#title...

pour google et sémantiquement ca n'a pas la même signification

merde grillaid