[sf 1.4.x] Affichage de données dans un form embarqué

[erictomcat]

Voila j'ai un module admin avec un form embarqué.
Hors je ne désire pas que l'utilisateur puisse modifier tout les champs mais seulement certains d'entre eux dans le sous formulaire.
La methode read-only dans le configure du form embarqué ne me plait pas trop, mais la solution $form->getObject()->getValue() ne fonctionne pas dans un embed form.

Y a t il une autre solution ?

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
 
<?php use_stylesheets_for_form($form) ?>
<?php use_javascripts_for_form($form) ?>
 
<div class="sf_admin_form">
  <?php echo form_tag_for($form, '@groupasset') ?>
    <?php echo $form->renderHiddenFields(false) ?>
 
    <?php if ($form->hasGlobalErrors()): ?>
      <?php echo $form->renderGlobalErrors() ?>
    <?php endif; ?>
 
<?php 
	$infoGal='<table>';
	foreach($form as $key=>$widget)
	{
		if($key=='listAsset'){
			$listAsset = '<table>';            			              
			foreach($widget as $subKey=>$subForm){				
				//echo '<tr><td>'.$subKey.'</td>';				
				$listAsset.='<tr>';
$ob=$subForm->getObject()	//********* cette ligne ne fonctionne pas *********/			
if($subKey==1)
				{
					$listAsset.= '<td>&nbsp;</td>';
					foreach($subForm as $field)
					{
						if(!$field->isHidden()) $listAsset.= '<td>'.$field->renderLabel().'</td>';
					}
					$listAsset.= '</tr>';
				}
				foreach($subForm as $field){
 
					$listAsset.= '<td>'.$field->render().'<br>'.$field->renderError().'</td>';
				}
				$listAsset.= '</tr>';
			}
			$listAsset.= '</table>';
		}
		elseif(!$widget->isHidden())
		{
			$infoGal.= $widget->renderRow();
		}
	}
	$infoGal.='</table>';	
?>
	<table>
		<tr>
			<td><?php echo $infoGal ?> </td>
			<td><?php echo $listAsset ?></td>
		</tr>
	</table>
    <?php include_partial('groupasset/form_actions', array('groupasset' => $groupasset, 'form' => $form, 'configuration' => $configuration, 'helper' => $helper)) ?>
  </form>
</div>

[Vivian Pennel]

Si on suppose que ton embedForm est imbriqué dans le form principal via le nom "listAsset"

Si relation 1-1 :

Code :

1
2
3
4
5
6
7
 
 
<?php echo $form['listAsset']['widget1'] ?>
<?php echo $form['listAsset']['widget2'] ?>
 
<?php // affichage d'une valeur ?>
<?php echo $form->getObject()->getListAsset()->getXXX() ?>

Si relation 1-n

Code :

1
2
3
4
5
6
7
8
9
10
11
 
 
<?php foreach($form['listAssets'] as $key => $fieldSchema ?>
 
  <?php echo $fieldSchema['widget1'] ?>
  <?php echo $fieldSchema['widget2'] ?>
 
  <?php // affichage d'une valeur ?>
  <?php echo $form->getObject()->getListAssets()->get($key)->getXXX()?>
 
<?php endforeach; ?>

Version rapide, pour expliquer le principe.

[Michel Rotta]

ATTENTION !

Le readonly en HTML utilisé de cette manière n'empêche pas que les données soient modifiée par un utilisateur un tant soit peux averti. En effet, elles partent chez l'utilisateur et revienne et son validée par un validateur (essaye de le retirer pour voir !). Donc, si une personne intercepte le paquet POST avant qu'il ne quitte le poste et le modifie, ta valeur en readonly, est est en writeaussi

Il faut faire le formulaire à la main et afficher les valeurs plutôt qu'un champ. Ensuite, il faut retirer le validateur du form pour éviter toute entrée d'information. (et si non, il va crier vu que la donnée, elle ne revient plus).

Voir ici un petit article.

[erictomcat]

tout a fait Michel, j'ai lu ton article.
Sauf que la c'est un embed Form dans un admin form, donc un poil plus complexe et je trouvais intelligent d'afficher juste les valeurs, et de unset les champs ciblés puisque de toute façon ce sont des champs qui ne seront jamais à mettre a jour via l'interface.

Si vivian ne s'est pas trompé j'appelai l'object un niveau hiérarchique un poil en dessous. Je teste et je reviens

[erictomcat]

bon j'ai un comportement bizarre, quand j'ai plusieurs "sous enregistrement" ici 2;
Il m'affiche les valeurs de la ligne 2 mais les champs de la ligne 1 et à la ligne 2 je n'ai pas de valeur affiché mais bien les champs du deuxième enregistrement .

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
 
<?php use_stylesheets_for_form($form) ?>
<?php use_javascripts_for_form($form) ?>
 
<div class="sf_admin_form">
  <?php echo form_tag_for($form, '@groupasset') ?>
    <?php echo $form->renderHiddenFields(false) ?>
 
    <?php if ($form->hasGlobalErrors()): ?>
      <?php echo $form->renderGlobalErrors() ?>
    <?php endif; ?>
 
<?php 
	$infoGal='<table>';
	$listAsset='<table>';
	foreach($form as $widgetName=>$widgetschema)
	{
		if ($widgetName!='listasset')
		{
			if(!$widgetschema->isHidden()) $infoGal.= $widgetschema->renderRow();
		}
		else
		{	
			$listAsset.= '<tr><td>&nbsp;</td><td>Type</td><td>value</td>';		
			foreach($form['listasset'][1] as $field)
			{
				if(!$field->isHidden()) $listAsset.= '<td>'.$field->renderLabel().'</td>';
			}
			$listAsset.= "</tr>\n";
			foreach($widgetschema as $assetNum=>$subForm){												
				$asset = $form->getObject()->getListGroupAsset()->get($assetNum);
 
				$listAsset.='<tr>
								<td>'.$assetNum.'</td><td>'.$asset->getType().'</td><td>'.$asset->getValue().'</td>';				
 
				foreach($subForm as $field){
 
					$listAsset.= '<td>'.$field->render().'<br>'.$field->renderError().'</td>';
				}
				$listAsset.= "</tr>\n";
			}
			$listAsset.= '</table>';
		}
 
	}
	$infoGal.='</table>';	
?>
	<table>
		<tr>
			<td><?php echo $infoGal ?> </td>
			<td><?php echo $listAsset ?></td>
		</tr>
	</table>
    <?php include_partial('groupasset/form_actions', array('groupasset' => $groupasset, 'form' => $form, 'configuration' => $configuration, 'helper' => $helper)) ?>
  </form>
</div>

le getListGroupAsset() vient de mon schema, c'est mon ForeignAlias, un getListasset qui irait récuperer les différents embed form ne marche pas.
mon configure:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
$wrapperForm=new sfForm();
 
    $listasset = $this->getObject()->getListActiveGroupAsset();
    $i=0;
    foreach($listasset as $asset)
    {
    	$i++;
    	$assetForm = new AssetForm($asset);
    	unset($assetForm['groupasset_id']);
    	$wrapperForm->embedForm($asset->getId(),$assetForm);
 
	}
	$this->embedForm('listasset',$wrapperForm);

[Michel Rotta]

Je passe vite et j'espère ne pas répondre à côté.

Dans un form, il faut utiliser les nom des sous objets déclarés dans le form (le embed) et non les objets du modèle. Je ne sais pas pourquoi j'ai l'impression d'y être, à côté.

Tu peux aussi faire un nouveau widget qui hérite de sfWidget et pour lequel tu redéfini la méthode render. Méthode qui retournera de quoi afficher et non pas un champ. Un peu plus lourd (quoique) mais très réutilisable.

[erictomcat]

pour ton premier cela ressemble a la proposition de vivien sauf que apparemment je n'ai qu'un tableau et plus de référence à l'objet.

pour le deuxième.. en y réfléchissant plus, c'est loin d'être idiot et pas si lourd que ça puisque, au lieu de devoir réécrire tout les _form où je fait référence a cette table, les valeurs seront automatiquement affichées...

Sauf que construire un widget à partir de rien, j'en suis encore très loin

[Michel Rotta]

Tu n'as pas à réécrire à partir de rien.

Fait un widget que tu dérives à partir de sfWidgetForm.

Je pense que tu n'as que le render à modifier.

Jette un oeil à sfWidgetFormInput, tu verras, il y a très peu de chose.

Tu as plusieurs méthode renderTag qui ne conviendra pas et renderContentTag pour rendre un tag html. A partir de celui-là, le reste devrait être simple.

Utilise le site de sensio, page documentation, tu as un truc api où tu peux retrouver pour chaque objet les méthodes, les parents et les enfants. Tu peux aussi rechercher pour une méthode où elle est définie.

Et n'hésite pas à aller sur browse code où tu as souvent de l'aide en en tête de chaque fonction pour les paramètres et options.

Et suivant l'IDE que tu utilises, il peut être assez simple de remonter le code des objets parents directement et donc de faire de l'introspection du framework.

[erictomcat]

erf mes connaissances en POO et de symfony ne vont pas jusque la malheureusement.
j'ai créé un fichier dans lib/widget sfWidgetFormDisplayText.class.php par copy sur sfWidgetFormInput.class.php.

cette classe n'a que 2 methodes configure et render.

dans la methodes render, j'ai juste fait un return $value qui effectivement me retourne que la valeur....

Sauf que bien sur quand je valide le formulaire je me retrouve avec un champ null.

il n'y aurait pas a créer aussi un validator ?

PS: j'ai pas vraiment d'IDE, j'utilise juste geany pour modifier mes fichiers.

[Michel Rotta]

Tu y es presque, il suffit de rajouter un "spam" ou un "p" pour rendre la donnée, j'utiliserais un "spam" qui est une balise en ligne comme l'imput. Il y a alors peu de modifications à porter dans le CSS de la page et rien dans le template.

C'est la que la méthode renderContentTag peut aider.

Il faut se méfier des objets, la subtilité est dans le extand, en effet, un objet est souvent enfant d'un autre, il hérite de toutes les propriétés et méthodes de son parent. Ce n'est pas parce qu'un enfant n'a que deux méthodes modifiées par rapport au parent qu'il n'a que deux méthodes... ton objet sfWidgetFormDisplayText dispose de toutes les méthodes et propriété de son parent...

Si tu utilises cet objet dans un form, il ne faut pas avoir de validator puisqu'il n'y a aucun retour de valeurs.

Tu peux utiliser un éditeur avancé, mais un bon IDE, quant tu travailles toute la journée sur de code, c'est un confort inimaginable. Tu as dans EDI sur le site tout une série d'informations sur différents éditeurs. Personnellement j'utilise NetBeans qui va te permettre, entre autre chose, l'autocomplétion des fonctions, des variables, des propriétés et des méthodes des objets, l'accès directe au code d'une méthode ou d'un objet parent, la vérification de la syntaxe, la vérification d'erreurs courantes (genre variable non renseignée par erreur de nom), la mise en forme du code, la gestion des projets et de l'historique des versions, la gestion de la base de données, l'accès directe à une méthode dans ton fichier, le test directement dans l'ide, le débug,... Et NetBeans est interfacé avec symfony ce qui fait disparaître la ligne de commande. Je pense que le gains à moyen terme mérite qu'on y perde quelques heures.

[erictomcat]

hu !! mais comment lui dire alors de garder la valeur puisque apparemment quand il sauvegarde il me vide le champ !!!

Pour l'EDI, il fut un temps où j'avais essayé eclipse, mais j'avais perdu plus de temps a le debugger qu'a l'utiliser, ça m'avait refroidi.

Je vais tester netBeans, des fois qu'il s'installe sans problème sur mon PC.

[Michel Rotta]

Eclipse est bien, mais pas simple à installer et configurer.

NetBeans est un peu (très peu) moins complet, mais plus simple à mettre en œuvre.

Pour ton code, tu dois, au retour de l'objet, commencer par le lier à l'objet du modèle correspondant avant de le binder aux données revenues. Si non, effectivement, il ne peut retrouver les données qui ne sont pas revenue. Mais, dans le fonctionnement normal d'un doctrine form, tu commences par le lier à l'enregistrement déjà sauvegardé avant de le binder au données retournées. Donc, rien ne change.

[erictomcat]

Envoyé par Michel Rotta

...
Pour ton code, tu dois, au retour de l'objet, commencer par le lier à l'objet du modèle correspondant avant de le binder aux données revenues. Si non, effectivement, il ne peut retrouver les données qui ne sont pas revenue. Mais, dans le fonctionnement normal d'un doctrine form, tu commences par le lier à l'enregistrement déjà sauvegardé avant de le binder au données retournées. Donc, rien ne change.

bon je l'ai relu et relu et ça me parle pas du tout.
Je doit au retour du formulaire, donc surcharger la méthode save ?. Bein non puisque tu dis que le fonctionnement d'un form doctrine le fait par défaut.

Donc je n'ai rien à faire.... sauf que ça marche pas

[Michel Rotta]

On a des différences de vocabulaire...

Au retour du post, dans le contrôleur de l'action (executeTrucMachinChose où TrucMachinChose et le nom de ton action ).

La manière de récupérer les données doit être :
1) retrouver l'enregistrement d'origine (soit par un doctrine_query, toi par la route doctrine.
2) initialiser l'objet form et le lier a l'objet de données récupéré au 1
3) liée (mathode bind du form) les données récupérée du post.
4) vérifier si l'objet est valide
4.1) objet valide, save et afficher ce que tu veux
4.2) objet non valide, renvoyer le form pour modifications

Quant tu fais l'étape 2, tous les champs de ton form sont liés, donc pas de problèmes de champs vide si tu dois faire l'étape 4.2.

Suis-ja moins obscure ?

[erictomcat]

erf, c'est bien ce que je craignait.

ça reste assez simple tant que tu fonctionne avec un module normal, mais déjà ça se complique si tu travailles avec un module admin, puisque tes actions sont générées automatiquement.
Et avec des formulaires embarqués dans un module admin, ça devient très coton.

Je ne vois pas plus d'avantage à juste modifier le template pour afficher les données que j'aurai désactiver dans le formulaire.

[Michel Rotta]

Le module admin fonctionne suivant le même principe, mais tu as moins d'accès au code.

Tu peux ne travailler que sur une partie de contrôleur.

Mais il est sur que quant un module admin devient trop compliquer, il est parfois plus simple de faire un module dédié entièrement, même si, au départ, cela peut sembler plus compliqué !

[erictomcat]

je travaille sur un intranet avec peu de chance d'attaque de hacker.
Je pense que je me contenterai d'un champ text disabled.

un autre voie ne serait pas de créer un widget qui emporterai a la fois un champ hidden pour conserver la valeur et un label pour afficher la donnée ?

[Michel Rotta]

je travaille sur un intranet avec peu de chance d'attaque de hacker.

C'est là où, statistiquement, j'ai eu le plus de tentatives explicite de piratage...

Je ne vois pas l'intérêt de passer la moindre information par un champ caché dans le formulaire, hors éventuellement un numéro d'enregistrement qui est bien mieux dans l'url de retour et le jeton CSRF. Hors cela, les données affichée sont présente dans la base, donc récupérable dans la même requête que celle qui a permis de récupérer les données initiales d'affichage et qui sera donc nécessaire pour retrouver les objets à mettre à jour.

Mais je n'ai pas rencontré tous les cas de figure, loin de là...

[erictomcat]

en faites 80% des données sont chargées a partir de systéme disparate et donc non modifiable via l'interface.
Seul l'état (validé, pas validés) ou bien le propriétaire de la données est a modifier.

pour cela que je cherche un moyen pratique et rapide pour décider de n'afficher en "modification" que les 2 ou trois champs. Le reste seulement en affichage.

La fonction configure du form du modèle étant repris dans dans tout les cas de figure, je trouvai pratique d'indiquer à son niveau quels sont les champs modifiables et quels sont les champs en affichage. Plutôt que d'avoir a chaque fois que j'appelle un form de cette table à avoir a modifier le template.

template qui est différent a chaque fois que tu fait appel a cette table, via un embed dans un admin module

[Michel Rotta]

Là je n'ai pas de réponse magique

Si tu as réellement beaucoup de table a générer, tu peux modifier le générateur d'admin, pour qu'il génère un autre schéma et indiquer dans la config de cette admin qu'il doit générer autre chose.

Avec les champs envoyé dans un widget particulier d'affichage, ça devrait fonctionner en admin généré même au retour, vu qu'il suit le schéma normal. As-tu testé ? Si tu as des problème là, je jetterais un œil plus approfondi cette semaine.