Discussion :

[lidaa]

Salut tout le monde,

Voilà je cherche l'équivalent de ça en Symfony2:

$w = new sfWidgetFormInputText();
$w->setAttribute('class', 'foo');

Merci d'avance.

[Michel Rotta]

Les form sont en pleine refonte.

Je pense qu'il est urgent d'attendre un peu.

[RapotOR]

Je serais tenté de dire que l'ajout d'une classe (css) se fait dans le template de Twig.

Edit:
Dans le template concernant les attributs, la propriété "class" n'est pas disponible. Il faut d'abord l'ajouter et ajouter l'attribut dans la classe...

Code :

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

1
2
3
4
5
6
{% block attributes %}
{% spaceless %}
    id="{{ id }}" name="{{ name }}"{% if read_only %} disabled="disabled"{% endif %}{% if required %} required="required"{% endif %}{% if max_length %} maxlength="{{ max_length }}"{% endif %}
    {% for attrname,attrvalue in attr %}{{attrname}}="{{attrvalue}}" {% endfor %}
{% endspaceless %}
{% endblock attributes %}

[Michel Rotta]

En v1 il était possible de préciser pour un widget une classe.

Ce qui permettait de générer l'affichage avec un simple render du formulaire tout en gardant la possibilité d'avoir un champ avec une classe particulière. Et donc de ne pas avoir à reprendre entièrement à la main le déroulé du formulaire dans le template.

Je n'ai aucune idée de si ceci est repris dans le future form qui va arriver.

[lidaa]

oui tout a fait d'accord, en v1 il était possible de préciser pour un Widget une classe.

en espérant avoir la même manip dans le future form qui va arriver.

[RapotOR]

Il ne fait pas partie des attributs par défaut en tout cas.

[RapotOR]

J'ai confirmation que l'attribut 'class' (comme 'style') est possible par le biais du template uniquement. Ces attributs concernent le display et sont donc paramètrable par ce biais. Ce choix permet de séparer clairement la vue du reste. Cela me parait logique.

Un exemple:

Code :

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

{{ form_widget(form.field_name, {'attr': {'class':'foo'}}) }}

Un autre moyen plus général serait de modifier le block "{% block attributes %}" pour y intégrer l'attribut "class". N'oublions pas que la vue est dotée de "if". Vous pouvez donc facilement changer l'attribut "class" à votre guise.

A noter qui si vous vous trouvez frustré de ne pas pouvoir le faire en php; il est possible d'utiliser un template PHP

Voilou

[winzou]

Je crois que la refactorisation des forms permet a nouveau de pouvoir definir ces attributs depuis PHP. Il me semble avoir vu ca passer.

[Michel Rotta]

@RapotOR
En Sf1 tu pouvais aussi le faire dans le template dans le même type de déclaration. La différence étant que tu pouvais le faire dans la partie configure du form, d'où, un form utilisé dans plusieurs template embarquait avec lui cette logique visuel. Il est malgré tout possible de forcer au niveau du template même si cela a été défini dans le configure.

Je suis d'accord que coté conformité au MVC, il y a une entorse.

Mais l'avantage est que si tu rends ton form avec le code minimal

Code :

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

<?php echo $form ?>

tu as cette logique qui s'applique.

Bon, on va voir ce que nous donne la nouvelle mouture du form en Sf2

[RapotOR]

@winzou
Je parlais déjà de la nouvelle mouture (je travaillais sur la branche 'form'). Sauf si j'ai vraiment loupé cela, il n'est pas possible de le faire. J'ai meme posé la question sur un commit de gihub (https://github.com/symfony/symfony/c...comment-350566).

Sinon; au passage; la branche 'form' vient d'être appliquée à la branche 'master' à l'instant!

Je comprends la facilité de minimiser la partie template et tout mettre dans le code (je le faisais) mais je crois que ce n'est pas la bonne approche. C'est surtout le cas lorsqu'on travaille à plusieurs sur un projet. Les personnes qui programment ne sont pas nécéssairement celle qui mettent en page.

[Michel Rotta]

Je pense que cela dépend essentiellement du type de projet sur lequel tu travail et que (pour la 1) symfony s’adapte aux deux principaux types.

Cas un, le site public de présentation où chaque page doit être léchée avec respect !

Cas deux, le site "applicatif" qui permet de mettre à disposition a travers une interface web une application plus classique style ERP, Gestion d'association,...

Dans le premier cas, où la présentation est essentiel, je suis d'accord avec toi, ceci doit se gérer dans le template, dans le deuxième cas, tu as intérêt à le gérer dans le form pour uniformiser l'interface et accélérer le développement.