Ca se comprend .

Pour les bbcodes ta pas de limite, c’est toi qui les créer, libre à toi d’en faire autant que tu veux. C’est fait par les expressions régulières…

les trois navigateurs principaux

Hum tu références à ceux sous windows . J'en compte cinq personnellement: IE, Firefox, Opera, Safari et Konqueror. Bon oki c'est sur que c'est du travail supplémentaire, c'est un choix à faire .

En notant le fait que les administrateurs du site sont des gamers, je ne pense pas trop m'avancer en présumant qu'ils sont tous sous Windows.

Cela dit j'ai pour coutume de passer mes sites sur browsershot avant de publier, les navigateurs minoritaires m'intéressent

Quant au BBCode, je vais pas m'amuser à réinventer Word en BBCode, y'a des choses plus passionnantes dans la vie

Au passage, si ca passe sur Safari, alors ca passe sur Opera et Konqueror, les 3 respectent très rigoureusement les spécification du W3C.

Quant au BBCode, je vais pas m'amuser à réinventer Word en BBCode, y'a des choses plus passionnantes dans la vie Smile.

J'en doute pas, c'était une question de culture :-p.

Au passage, si ca passe sur Safari, alors ca passe sur Opera et Konqueror, les 3 respectent très rigoureusement les spécification du W3C.

Oui en général chaque navigateur suive la W3C sauf Internet explorer ou il y a encore de gros problème avec le DOM. Mais il y a co-même des différences sur les autres. Je suis co-même mon projet sur ces navigateurs, je voix bien ce qui ce qui ne vas pas... Bon oki vous préférer passer par des bibliothèques déjà toute faite. Moi j'ai préférer créer les miennes. Ca m’avais prit du temps mais par contre je n’ai pas de code mort de plus je maitrise totalement le code étant donner que ce sont les miennes. Ca à aussi ces avantages :-p.

Disons que pour ma part le JavaScript je suis pas fan, c'est du bonus et je n'ai pas de temps à dépenser pour ça (je suis un professionnel), je préfère me consacrer totalement à la qualité de la structure, JS exclus. D'ailleurs c'est clair que le JS viendra se rajouter en fin de projet, quand le reste fonctionnera comme il faut.

Disons que pour ma part le JavaScript je suis pas fan, c'est du bonus et je n'ai pas de temps à dépenser pour ça (je suis un professionnel), je préfère me consacrer totalement à la qualité de la structure, JS exclus. D'ailleurs c'est clair que le JS viendra se rajouter en fin de projet, quand le reste fonctionnera comme il faut.

C'est là qu'on est content d'utiliser quickform, on remplace "select" par "adv_multiselect" et on a un double-select (un pour les disponibles, un pour la sélection), on remplace "textarea" par "fckeditor" et on a un editeur wysiwyg
Temps perdu à l'ajout du JS en fin de projet : 10 secondes
Pour être vraiment complet tu déclares un cookie en javascript dans ta page, et côté PHP tu n'utilises les champs "dynamiques" que si ce cookie est défini. Temps perdu : environ 1 minute
Et l'utilisation d'un cookie laisse même le champ libre à l'ajout d'une option de préférence pour l'utilisateur.

Finalement on retombe sur le sujet initial, dans le cadre de la modélisation (enfin plutôt de la définition du cahier des charges techniques), faire des choix de librairie spécifiques comme PEAR::HTML::QuickForm a un impact (positif ou négatif) très important jusqu'à la fin du projet. Il est donc important de choisir en connaissance de cause les outils et les frameworks.

En ce qui concerne l'éditeur WYSIWYG, j'utilise d'habitude FCKEditor, je ne sais pas si vous en connaissez un mieux ? Perso je le trouve un peu lourd mais il a l'avantage d'être bien fourni en fonctionnalités, généralement il plait aux utilisateurs.

Après niveau PHP, pour les templates j'avais dans l'idée de faire ma classe perso mais je pense que je vais plutôt me tourner vers PHPLib, qui me semble simple d'utilisation et léger. J'aurais bien essayé Smarty mais son langage spécifique me rebute, je n'ai pas trop envie de me tourner vers cette solution, si complète soit-elle. Pour la mise en cache je vais utiliser ma propre classe, que j'ai posté dans les Contributions, elle me convient très bien. Après pour les formulaires faut que j'étudie sérieusement le cas, ça me semble être un point crucial.

A votre avis, y a-t-il déjà un outil performant en PHP5 pour gérer les formulaires de façon performante tout en gardant le contrôle sur la disposition (souplesse de mise en forme) ? Ou dois-je faire ma propre classe ?

Déjà :

Le livre c'est "Design patterns - tête la première" ? :-p

Oui ^^ Le livre est assez génial, même s'il y a de très nombreuses fautes ... C'est assez incroyable d'en trouver autant. On peut dire qu'on a une moyenne de 5 fautes par pages, normal. J'aurais peut être du le prendre en anglais Le plus grave, c'est les fautes dans le code

Puis :
Le gros problème avec les WYSIWYG, c'est l'accessibilité.
Faire des WYSIWYG interopérable, c'est faisable, et ça existe. Mais accessible ... c'est une autre histoire

Au passage, si ca passe sur Safari, alors ca passe sur Opera et Konqueror, les 3 respectent très rigoureusement les spécification du W3C.

Pas d'accord.
Opera respecte très très bien. S'il était plus ouvert aux programmeurs, je laisserais tomber Firefox (Tristan, ne me frappe pas ^^).
Konqueror, je connais pas assez bien pour faire une critique.
Et Safari par contre, je connais, donc j'affirme que non ^^ Oui il respecte, mais partiellement. La logique de Safari a été de choisir les implémentations. Quand un composant est implémenter, il fonctionne à la perfection. En revanche, si un composant n'est pas implémenter, il ne les pas du tout. Tout ou rien. C'est un choix, il a des plus et des moins. Mais le choix du composant a implémenter n'est pas toujours celui qu'on aurait choisi.

Pour répondre à Klomac sur la gestion des formulaires. Personnellement, je vais me faire mon propre gestionnaire de code HTML. Car je ne trouve rien sur le Web qui me satisfasse.

Pour conserver une certaine souplesse dans la composition de ta page et de ces éléments, il va falloir coupler (mais faiblement) ton moteur de template avec les composants de ta page (formulaire etc.). C'est pas si évident qu'on le pense Toujours garder le principe du MVC en tête.

Effectivement, je vais essayer de garder ce principe en tête.

Si tu es intéressé pour étudier à deux cette histoire de gestionnaire de formulaires, tu peux prendre mon MSN dans mon profil

Pour conserver une certaine souplesse dans la composition de ta page et de ces éléments, il va falloir coupler (mais faiblement) ton moteur de template avec les composants de ta page (formulaire etc.). C'est pas si évident qu'on le pense Toujours garder le principe du MVC en tête.

Pour ça j'ai beau ne pas trop aimer Smarty au départ, j'avoue que Smarty+QuickForm+Render_SmartyArray c'est très sympa

Pour conserver une certaine souplesse dans la composition de ta page et de ces éléments, il va falloir coupler (mais faiblement) ton moteur de template avec les composants de ta page (formulaire etc.). C'est pas si évident qu'on le pense Toujours garder le principe du MVC en tête.

Pour ça j'ai beau ne pas trop aimer Smarty au départ, j'avoue que Smarty+QuickForm+Render_SmartyArray c'est très sympa

Peux-tu développer s'il te plait ?

Cf. http://karma.nucleuscms.org/item/96 (une des pages qui décrit le plus précisément l'utilisation)

En gros le principe :
- Tu définis ton formulaire avec HTML_QuickForm
- Tu définis ton objet Smarty
- Tu lies les deux avec un objet HTML_QuickForm_Renderer_ArraySmarty. Son rôle principal est de transformer un formulaire en tableau associatif, afin de pouvoir l'utiliser directement dans ton template, avec au passage un peu de mise en forme propre au Renderer.

Tout marche très bien ensemble c'est très agréable à utiliser.

Le livre c'est "Design patterns - tête la première" ? :-p

Oui ^^ Le livre est assez génial, même s'il y a de très nombreuses fautes ... C'est assez incroyable d'en trouver autant. On peut dire qu'on a une moyenne de 5 fautes par pages, normal. J'aurais peut être du le prendre en anglais Le plus grave, c'est les fautes dans le code

Oki, As-tu lu: Les Design Patterns en Java - Les 23 modèles de conception fondamentaux (édition CampusPress) ? Il est bien ?

Cf. http://karma.nucleuscms.org/item/96 (une des pages qui décrit le plus précisément l'utilisation)

C'est chez moi ou le lien est down ?