Forum

Bonjour,



Je souhaiterais personnaliser la balise [img]

Il m'arrive souvent d'insérer des images qui sont plus grandes que la largeur de mon #main_content.

Si j'utilise la balise,

alors, si l'image est trop grand, elle va dépasser.



Je suis obligé d'utiliser



et je redimensionne l'image avec width="100%;"



Pour mieux comprendre, voici une capture : http://screencast.com/t/ODY2NjRjZT



Comment faire pour que si j'ajoute resize="1" cela ajoute width="100%;" dans mon code généré. ?



Par exemple :



donnerait en HTML quelque chose du genre :





Merci d'avance pour votre aide,

Jean

Alors une chose pour rappel :

L'image si le theme est bien developpé ne devrait pas dépasser du div main content... En effet en css on peut définir une taille max du genre max-height ou max-width.

Ensuite il me semble qu'un post a déjà etait créer...


Il serait sympa d'incule ce genre de paramètre dans la prochaine version 3.1

Est-ce que ça ne serait pas mieux qu'on ajoute un attribut style (pour mettre du CSS) à la balise image ?
Faire ce que vous proposez n'est pas compatible directement avec TinyMCE.

Oui, inclure un attribut style ne me poserai pas de soucis C'est même encore mieux, on peu davantage personnaliser ...
Si ça vous simplifie la vie pour la compatibilité avec TinyMCE, alors pas de problème ...

Sinon, merci ReidLos pour l'astuce du max-width en CSS qui va beaucoup me simplifier la vie, je vais essayer ça demain

Ben, sur tinymce... Quand tu ajoute une image tu peux la redimensionner non ?

Si tu fait un truc du genre : [img=260,125]lien[/img]


Lisans un autre de tes posts, ou il est ecrit que l'editeur tinymce transforme tout en bbcode... Cela ne devrait pas posé de soucis, si ?

Je parlais de resize=1, c'est ça qu'on ne pourra pas mettre dans TinyMCE.

Je préfèrerais mettre un syntaxe de type style que [img=largeur,hauteur], ça permettra de mettre des tailles en pourcentage ou autres (plus souple qu'un nombre de pixels).

garder la syntaxe de la balise flash, serais a mon avis personnel un plus qui éviterais de perdre tout le monde, et ainsi garder un cohérence dans les balises.



pour le coup du max-width, ce peut etre u plus surtout au niveau de la galerie, mais ce n'est pas le meme sujet ...

Ouais mais du coup on peut pas faire en sorte que l'image prenne 100% de la largeur. Donc je persiste à penser que style sera plus adapté. Ca sera peut-être plus compliqué, mais on n'est pas obligé de l'utiliser contrairement à swf où là on n'a pas le choix.

Bah pour quelle prenne 100% de la largeur, tu n'as pas a t'en occupé, c'est nous graphiste qui devont nous occuper de ça... en changeant le .img dans le global.css il me semble et en rajoutant un max-width...

ensuite bah si dans la balise tu as le signe = cela signifie que tu as un paramètre de rentré, sinon bah tu utilise la balise normalement... En gros deux fonctions, avec une condition, si tu passe par là, et si tu as le temps, j'aimerai bien savoir ou sont les fichiers a modifier pour ce type de chose, également pour l'ajout d'une balise...

Édité par ReidLos Le 21/01/2010 à 10h48

L'avantage du style est que ça permet de faire des mises en forme autres que de l'assignation de taille (bordure, transparence...).

Par contre, il est hors de question que je mette à la fois le = et le style, c'est suffisamment compliqué d'en mettre un.



Reidlos : le parser se trouve ici. Il est entièrement construit à partir d'expressions régulières et ce n'est pas évident de modifier son comportement parce qu'il est écrit pour être performant et malheureusement code propre et performance dans ce cas-là ne sont pas compatibles.

Rajouter un paramètre à une balise est loin d'être trivial. Rajouter une balise l'est encore mois, d'autant plus que tout modification doit être faite sur le BBCode et sur TinyMCE qui ne fonctionnent pas du tout pareil.

Si tu veux rajouter des balises et que tu ne maitrises pas bien les expressions régulières (j'insiste sur le bien), je te conseille de les parser ici, ça sera plus simple mais moins performant.



Quoi qu'il en soit, si je suis réticent à rajouter des balises, c'est parce que ce n'est pas simple à intégrer et surtout à stabiliser et tester.

Ceci dit, je suis convaincu que dans l'ensemble on a des possibilités de formatage bien plus puissantes que la concurrence : on propose deux éditeurs qui sont compatibles et c'est pas courant, on supporte l'imbrication de tableaux, de listes, bref de toutes les balises imbricables, le code HTML... Cette puissance se paye par la complexité des parsers

nikel ta réponse me convient bien, Ce fichier me convient amplement pour la balise que je veux rajouter. Merci ben.

Le fait de faire la modif en style passera par dessu le css non ?



Modifier tous les fichiers css risque d'etre lourd non ?

vue tous les theme qui sont disponible, sans parler de tous les cms en prod...



Personnellement je trouve que il y a trop d'évolution du kernel, ou de l'environement.

ces maj touche trop a des élment qui pourrait etre mis en attente, et sortie quand ce sera stabiliser. je pense la a une date butoire de révision, et non une version.



Un peu a la "ubuntu" qui sort une revision tous les 6mois.

cette façon de faire peut parraitre "con" mais néanmoins a l'avantage de donner une perriode de dev de 3 mois au départ et d'intégré dans une nouvelle version que du stable.



je dis sa dans ce sujet, vu qu'il s'agit de faire une intégration d'une modification du systeme de bbcode sur les images.



petit detail aussi, mais le kernel est pas mal efficasse, certes il peut encore etre amelioré, mais le nombre de modules reste le meme. A ce jour le point faible de phpboost, de mon point de vu, n'est pas sa stabilité, ni son efficassité, sa simplicité, mais plutot le nombre de module.

il y en a plein qui sont "non officiel" ou en alpha, beta, tests ...

mais trop peu sont soit mis a jour de la V2, soir dans les "a faire" (je pense ici au sitemap xml auto)



Ce n'est que mon avis, et si je m'exprime c'est pour donner mon avis (a moi utilisateur) en espérant etre constructif.

SaTurNin :

Le fait de faire la modif en style passera par dessu le css non ?















Modifier tous les fichiers css risque d'etre lourd non ?







vue tous les theme qui sont disponible, sans parler de tous les cms en prod...

Dans tous les cas la taille de l'image sera définie en CSS dans la balise HTML img. Ca n'a absolument aucune conséquence sur les fichiers CSS des différents thèmes. Et je sais bien qu'il y a beaucoup de thèmes à maintenir, mais il y aura forcément des modifications des templates dans la 3.1, c'est inévitable. C'est pas pour rien que j'ai longtemps suggéré de redéfinir un minimum de fichiers.

SaTurNin :

Personnellement je trouve que il y a trop d'évolution du kernel, ou de l'environement.







ces maj touche trop a des élment qui pourrait etre mis en attente, et sortie quand ce sera stabiliser. je pense la a une date butoire de révision, et non une version.















Un peu a la "ubuntu" qui sort une revision tous les 6mois.







cette façon de faire peut parraitre "con" mais néanmoins a l'avantage de donner une perriode de dev de 3 mois au départ et d'intégré dans une nouvelle version que du stable.















je dis sa dans ce sujet, vu qu'il s'agit de faire une intégration d'une modification du systeme de bbcode sur les images.

Je suis d'accord, c'est une bonne manière de gérer les versions. Cependant, si nous ne sortons pas de nouvelles versions souvent, ce n'est pas parce que nous l'avons choisi mais parce nous ne pouvons pas consacrer énormément de temps à PHPBoost et qu'une bonne partie de ce temps est consommée pour faire du support, du coup nous ne pouvons pas beaucoup avancer. On fait ce qu'on peut mais a bien d'autres choses à faire que bosser sur PHPBoost, et concilier tout cela n'est pas toujours facile voire possible.

SaTurNin :

petit detail aussi, mais le kernel est pas mal efficasse, certes il peut encore etre amelioré, mais le nombre de modules reste le meme. A ce jour le point faible de phpboost, de mon point de vu, n'est pas sa stabilité, ni son efficassité, sa simplicité, mais plutot le nombre de module.







il y en a plein qui sont "non officiel" ou en alpha, beta, tests ...







mais trop peu sont soit mis a jour de la V2, soir dans les "a faire" (je pense ici au sitemap xml auto)

On ne voit certainement pas les choses de la même manière. Le noyau de la 3.0 n'est clairement pas bon pour nous. Le framework est très limité, le code du noyau n'est pas bien maintenable, et tant que ça ne bouge pas on devra faire du code déguelasse dans les modules. On ne peut plus faire ça, on a trop de lignes de code pour pouvoir se permettre de les écrire n'importe comment. Je conviens que pour vous utilisateurs il n'y a pas d'intérêt à ce qu'on bosse sur le framework car il n'y a quasiment aucun changement visible, mais pour nous c'est crucial et franchement le code des modules qu'on fait en ce moment n'a plus rien à voir avec ceux de la 3.0.







Je conçois très bien que vous ne voyez pas l'intérêt (il n'y a pas que toi) à ce qu'on bosse autant sur le noyau, mais moi je vous assure qu'il y en a un, nous ne le ferions pas sinon. On n'est pas tombés de la dernière pluie, le développement logiciel c'est notre métier, donc on sait ce qu'on fait















Pour les modules, je suis bien d'accord que c'est ce qui manque à PHPBoost, mais c'est comme quand tu as 10 € en poche et que tu veux acheter un ensemble de trucs qui coûte au total 1000 €, tu dois choisir.















Ceci dit, le module sitemap est quasiment terminé et sera de la partie pour la 3.1

SaTurNin :

Ce n'est que mon avis, et si je m'exprime c'est pour donner mon avis (a moi utilisateur) en espérant etre constructif.

Tu as raison de donner ton avis, j'ai essayé de justifier nos choix, j'espère que ça te convaincra.