Discussion :

[Vicrabb]

Bonjour,

Je me lance dans ce sujet. Le rendu des formulaires avec checkboxes m'a un peu choquée visuellement avec les listes à puces visibles. J'ai bien trouvé deux solutions (avec certains inconvénients qui m'ont un peu perturbées pendant quelques jours avant que je trouve un moyen de les contourner hier) et j'ai bien entendu envisagé d'aller changer ce rendu directement à la source (mais je ne sais plus si j'ai abandonné par crainte de mettre la pagaille ou parce que je n'ai pas trouvé le fichier où se trouvait ce code).

J'ai également trouvé de la documentation sur le sujet mais cela concernant sfWidgetFormChoice et non sfWidgetFormDoctrineChoice (qui est le widget utilisé).

Donc ma question est: existe-t-il une autre manière de retirer ces listes à puce autre que:
- bidouiller le code source
- utiliser la fonction strip_tags()
- faire un ccs spécialement pour cela
?

Si cela est possible avec un nouveau renderer, que l'on m'explique alors comment le faire pour sfFormDoctrineChoice? Car aux dernières nouvelles, je ne peux pas lui mettre un renderer_class et je n'ai trouvé aucune documentation à ce sujet-là (d'où un post dans mon blog à ce propos avec mes deux malheureuses solutions).

Pour info, les deux manières que j'ai trouvé sont:

-strip_tags avec un str_replace pour avoir une liste verticale

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
<?php 
//remplace les fins de li par des br pour un affichage vertical
$form2 = str_replace("</li>", "<br/>",$form);
 
//impression du formulaire en indiquant les tags autorisés
echo strip_tags($form2,'<a><input><tr><b><td><th><label><select><option><ul><textarea><br/>');

- ccs:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
#nouveau css form.css
li{
list-style-type: none;
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
//code dans _form.php
<?php use_stylesheet('form.css') ?>

[Michel Rotta]

Dans le xhtml résultant de symfony (et dans tout xhtml) seul la notion de sémantique devrait être prise en compte.

Et à ce niveau, la liste, pour une série de case à cocher me semble parfaitement adaptée.

La gestion du rendu peut être parfaitement obtenue par une css adaptée.

Je pense que mettre les cases et leurs libellé dans des div imbriqués ou tout autre système est une mauvaise idée.

[Vicrabb]

Pour moi, il est hors de question de faire des divs imbriquées, j'utilise la solution de la CSS adaptée et non strip_tags() si cela peut te rassurer . Je pense aussi que celle-ci est mieux adaptée, après avoir testé les deux il y a une ou deux semaines (du moins pour le test sans le str_replace et avec la règle css directement dans le main.css).

J'ai mis la version strip_tags uniquement pour montrer que j'avais planché sur le problème (d'ailleurs, c'est normal de venir ici après avoir cherché et tenté de résoudre son problème) et pour éviter que quelqu'un me donne cela comme réponse.

Mais en voyant ta réponse, tu me confirmes quelque part qu'il n'y a pas d'autres possibilités à part celles énumérées. Je vais laisser le sujet encore non-résolu un peu histoire de voir si d'autres ont quelque chose à proposer.

[Michel Rotta]

En fait, ce n'est pas tant dans symfony qu'est le problème, mais dans le html. Il faut que le fichier html reste sémantiquement viable et la liste reste le moyen par excellence pour l'énumération.

[mantex]

Oui mais quand le client se fou de l' excellence il faut malheureusement l' écouter gentiment et trouver une solution. Si on est pas obliger de passer 15 jours pour faire qqchose de simple, c 'est le paradis !

[Michel Rotta]

Si tu as un client qui s'occupe du html généré et non pas de la page vue, tu as là un client exceptionnel ! En général, il ne savent même pas qu'il y a du HTML et du CSS.

Je ne sais pas s'il faut le garder où le changer...

Il reste à lui faire comprendre que la génération d'une liste ne change rien dans le cadre de l'affichage avec une CSS et rend la page plus lisible si la CSS n'est pas prise en charge par le terminal.

[mantex]

Non le client il veut que ca s' 'affiche comme il a imaginé ou pu voir sur d' autres sites, effectivement le css, et même le html c' est de l' hébreu pour lui.

Alors parlé avec lui du respect des standards du web...

Ce que je voulais dire c' est que de plus en plus de client ne connaissent rien au web mais malgré tout des nouveaux clients qui ont des besoins très précis car inspiré des sites existants (Les fameux like qqchoses).

Pour ces clients la, seul le résultat compte avec bien souvent la réflexion suivante, la zappattitude :

vous savais pas faire , je vais voir aillleurs...
ça me marche pas comme je veux, je vais voir aillleurs...
c 'est trop compliqué, je vais voir aillleurs...
je comprends pas, je vais voir aillleurs... si c'est plus simple
etc etc..


et je parle pas des budgets très serrés qui vont avec.

Dans ce contexte, il est impensable de passer 2 semaines à trouver comment implémenter ou tout simplement faire fonctionner un formulaire simple quand en dev classique il faut moins de 2h.

J' ai de plus en plus de doute sur 'Développez plus vite avec un framework'.
moins sur "explose tes délais avec un framework'.

C' était le ptit coup de gueule du matin..

Bonne journée.

[Michel Rotta]

Pour le cas présent de cases à cocher, c'est plus un problème d'utilisation correcte des CSS qu'un problème de génération du html.

Utiliser le html à des fin uniques de mise en page, tel que c'était pratiqué (et cela l'est encore) il y a quelques années avec des tableaux dédiés à la mise en page n'est pas une bonne manière de faire. Il y a très peu de cas où les css, appliqué sur une page sémantiquement correcte (justement une de celle qui n'a pas été torturée pour correspondre à un affichage précis) ne puissent arriver à ce que tu veux.

Et le framework n'a rien à voir la dedans. En tous cas pas pour le cas présent.