modification d'un module admin

**finish_him** · 11/01/2010, 18h29

bonjour,

après avoir générer un module sfGuardUser et l'avoir copié dans mes modules pour l'adapter tout fonctionne. mais c'est que je commence a vouloir changer la requête de sélection des users que doctrine me génère une incohérence:

SELECT s.ID AS s__id, s.uti_nom AS s__uti_nom, s.uti_prenom AS s__uti_prenom,
s.uti_email AS s__uti_email, s.uti_tel AS s__uti_tel,
s2.user_id AS s2__user_id, s2.GROUP_ID AS s2__group_id,
s3.ID AS s3__id, s3.NAME AS s3__name, e.edi_no AS e__edi_no,
e.edi_cod AS e__edi_cod
FROM sf_guard_user s LEFT JOIN sf_guard_user_group s2 ON s.ID = s2.user_id
LEFT JOIN sf_guard_group s3 ON s2.GROUP_ID = s3.ID
LEFT JOIN eql_direction e ON s.edi_no = e.edi_no
WHERE s.ID IN (SELECT a.ID
FROM (SELECT DISTINCT s4.ID
FROM sf_guard_user s) a
WHERE ROWNUM <= 10)
la partie en souligné étant rajoutée par le pager est incorrect.

Quelqu'un a déjà réussi a faire une liste triée avec jointure ? je désespère

**Michel Rotta** · 11/01/2010, 18h59

Ben, heu, disons qu'un peu (beaucoup) plus de détail sur ce que tu veux faire, ce que tu as fais, quel sont les requêtes côté symfony, le shéma de la base, les objets utilisés...

Bon, en gros, mais quoi toi veux faire !

Après, si je peux, je t'aide !

**finish_him** · 12/01/2010, 09h17

excusez moi j'ai peut être était trop concis.

Donc j'ai une relation sur ma table SF_GUARD_USER et une table EQL_DIRECTION en 1,1 et la relation d'origine du plugin sfGuardDoctrine entre SF_GUARD_USER et SF_GUARD_GROUP de type n,n ( entre les deux , SF_GUARD_USER_GROUP).

J'ai utilisé le vjtheme plugin pour générer et modifier par moi même le module admin generator de symfony. Ayant besoin de réel besoin client très particulier, j'ai récupéré les éléments générés par l'admin generator de SF_GUARD_USER, dans le cache pour l'intégré comme un module à part entière dans mon appli (si si ça marche même très bien !!!), maintenant je souhaite alterer la requete actuelle qui est de type :
select * from SF_GUARD_USER
pour la changer en
SELECT *
FROM sf_guard_user s LEFT JOIN sf_guard_user_group s2 ON s.ID = s2.user_id
LEFT JOIN sf_guard_group s3 ON s2.GROUP_ID = s3.ID
LEFT JOIN sf_direction e ON s.edi_no = e.edi_no

(où edi_no et le PK incrémentée de ma table EQL_direction)

cela me permettra de faire des liste triées par EDI_COD ou SF_GUARD_GROUP.NAME

Car actuellement cela m'est impossible car ces champs la ne sont pas réel.

(si je ne suis pas assez clair n'hésitez pas je réexpliquerai, je suis dans mon truc est s'est difficile d'expliquer)

merci beaucoup

**Michel Rotta** · 12/01/2010, 10h46

Si je comprend bien.

Tu veux étendre sfGuardUser pour y rajouter la gestion de droits par groupes, définis en dehors du module ? Il me semble que la gestion de droits par groupe est déjà géré dans sfGuardUser. De plus tu semble travailler avec propel, si non, utilise plutôt sfDoctrineGuardPlugin.

Effectivement, récupérer un module admin généré dans le cache et en faire un "vrai" module, cela marche très bien, je m'en suis déjà servi en lieu et place de la génération standard de module, ou juste pour de l'auto-formation.

Par contre, ce qui me trouble, un peu, c'est le SQL dans cette histoire, veux-tu écrire du SQL ou te sers-tu du SQL pour exprimer le résultat d'une requête DQL, et dans ce cas, est-ce en DQL que tu as des problèmes ?

As-tu défini la liaison n2n dans ton schéma relationnel ? Les méthodes de liaisons ont-elles été généré dans les objets du modèle ?

As-tu parcourus la documentation du sfDocrtineGuardUser ? Il est prévu pour être facilement extensible et personnalisable.

Mettre en place une relation n2n entre deux tables est assez simple, il faut avoir la main sur une des deux tables et sur la table intermédiaire. Il y a un autre sujet sur le forum où l'on en parle.

Qu'est-ce que tu entends par "ces champs ne sont pas réels" ?

Je commence à connaître un peu symfony, auquel je consacre pas mal de temps ces derniers mois, mais je n'ai pas encore mis le nez dans sfGuardUser et ces enfants. Vu que c'est une des choses que je comptais faire, je fini mon étude sur les relation n2n et je creuse avec toi.

Désolé, ce n'est pas très précis comme réponse, mais un début de pistes.

**finish_him** · 12/01/2010, 11h26

je reprend ton post:

Tu veux étendre sfGuardUser pour y rajouter la gestion de droits par groupes, définis en dehors du module ? Il me semble que la gestion de droits par groupe est déjà géré dans sfGuardUser. De plus tu semble travailler avec propel, si non, utilise plutôt sfDoctrineGuardPlugin.

Effectivement j'utilise bien sfDoctrineGuardPlugin, mais dans mon cas, je n'ai besoin qu'une relation 1,1 entre sf_guard_user et sf_guard_group (qui peut le plus peut le moins

Effectivement, récupérer un module admin généré dans le cache et en faire un "vrai" module, cela marche très bien, je m'en suis déjà servi en lieu et place de la génération standard de module, ou juste pour de l'auto-formation.

Par contre, ce qui me trouble, un peu, c'est le SQL dans cette histoire, veux-tu écrire du SQL ou te sers-tu du SQL pour exprimer le résultat d'une requête DQL, et dans ce cas, est-ce en DQL que tu as des problèmes ?
en fait le SQL ecrit par symfony est incorrect lorsque je veux rajouter mes fameuses jointures, regarde bien , S4 n'est pas définie dans la requête, ce S4 est produit par le pager qui limite mon nombre de ligne sur la page

As-tu défini la liaison n2n dans ton schéma relationnel ? Les méthodes de liaisons ont-elles été généré dans les objets du modèle ? le modele est tirer du plugin donc ISO avec sfDoctrineGuardPlugin

As-tu parcourus la documentation du sfDocrtineGuardUser ? Il est prévu pour être facilement extensible et personnalisable.il est personnalisable mais il y a des limites je ne peux pas faire de tri par FK

Mettre en place une relation n2n entre deux tables est assez simple, il faut avoir la main sur une des deux tables et sur la table intermédiaire. Il y a un autre sujet sur le forum où l'on en parle.ça il n'y a pas de probleme tout vas bien la dessus

Qu'est-ce que tu entends par "ces champs ne sont pas réels" ?les champs sont calculés apres la requete

exemple:

select PK,FK1,DATA1,DATA2
from sf_guard_user

Je vais tirer DATA3 d'une requête unitaire de type select DATA3 from eql_direction where PK = FK1
donc tri possible par FK1(numérique) mais pas par DATA3 (alphabétique)

or je veux un tri sur DATA3 (alphabétique)

si tu veux voir regarde dans _list_th_tabular.php du module admin ( ou pour ma part vjthemeplugin) et tu verra qu'il contrôle le fait que ton champ viens de la requête principale ou d'un calcul apres (ligne 4)

Je commence à connaître un peu symfony, auquel je consacre pas mal de temps ces derniers mois, mais je n'ai pas encore mis le nez dans sfGuardUser et ces enfants. Vu que c'est une des choses que je comptais faire, je fini mon étude sur les relation n2n et je creuse avec toi.
Moi aussi je suis noob en symfony même si mettre la main dans le pétrin ne me fait pas trop peur même si je maitrise très bien oracle.

Désolé, ce n'est pas très précis comme réponse, mais un début de pistes.

Merci de ton aide

**finish_him** · 12/01/2010, 14h42

Bon j'ai peut être trouver un problème
avec la requete:

Code :

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

1
2
3
4
5
6
$q = Doctrine_Query::create()
		->select('u.UTI_NOM, u.UTI_PRENOM,u.UTI_EMAIL,u.UTI_TEL,ug.user_id,g.NAME as profil , d.edi_cod')
		->from('sfGuardUser u')
		->leftJoin('u.EqlDirection d')
		->leftJoin('u.sfGuardUserGroup ug')
		->leftJoin('ug.sfGuardGroup g');

yml:

Code :

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

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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
SfGuardUser:
  tableName: SF_GUARD_USER
  columns:
    id:
      type: integer(4)
      primary: true
    username:
      notnull: true
      type: string(128)
    algorithm:
      notnull: true
      type: string(128)
    id_direction: integer(8)
    edi_no: integer(10)
    salt: string(128)
    password: string(128)
    is_active:
      type: boolean
    is_super_admin:
      type: boolean
    last_login: timestamp(7)
    created_at: timestamp(7)
    updated_at: timestamp(7)
    uti_nom: string(30)
    uti_prenom: string(30)
    uti_email: string(50)
    uti_tel: string(14)
  relations:
    EqlDirection:
      local: EDI_NO
      foreign: EDI_NO
      type: one
    EqlBudget:
      local: ID
      foreign: UTI_ID
      type: many
    EqlBudgetGestionnaire:
      local: ID
      foreign: UTI_ID
      type: many
    EqlDemande:
      local: ID
      foreign: UTI_ID
      type: many
    SfGuardRememberKey:
      local: ID
      foreign: USER_ID
      type: many
    SfGuardUserGroup:
      local: ID
      foreign: USER_ID
      type: many
    SfGuardUserPermission:
      local: ID
      foreign: USER_ID
      type: many
SfGuardUserGroup:
  tableName: SF_GUARD_USER_GROUP
  columns:
    user_id:
      type: integer(4)
      primary: true
    group_id:
      type: integer(4)
      primary: true
    created_at: timestamp(7)
    updated_at: timestamp(7)
  relations:
    SfGuardUser:
      local: USER_ID
      foreign: ID
      type: one
    SfGuardGroup:
      local: GROUP_ID
      foreign: ID
      type: one
SfGuardGroup:
  tableName: SF_GUARD_GROUP
  columns:
    id:
      type: integer(4)
      primary: true
    name: string(255)
    description: string(1000)
    created_at: timestamp(7)
    updated_at: timestamp(7)
  relations:
    SfGuardGroupPermission:
      local: ID
      foreign: GROUP_ID
      type: many
    SfGuardUserGroup:
      local: ID
      foreign: GROUP_ID
      type: many
EqlDirection:
  tableName: EQL_DIRECTION
  columns:
    edi_no:
      type: integer(10)
      primary: true
    edi_cod:
      notnull: true
      type: string(10)
    edi_nom:
      notnull: true
      type: string(100)
    edi_dat_maj: timestamp(7)
    edi_uti_maj: string(30)
  relations:
    SfGuardUser:
      local: EDI_NO
      foreign: EDI_NO
      type: many

il me dit qu'il ne trouve pas la propriété: edi_no

Unknown property EDI_NO

Qu'en pensez vous ???

edits : faute de conjugaison et balise code

**finish_him** · 14/01/2010, 09h47

Bon la solution pour les intéressée:

J'ai supprimé le code dans executeIndex.

J'ai fais mon propre code

Code :

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

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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
$connexion = Doctrine_Manager::getInstance()->getCurrentConnection();
 
  		$image_tag = array(
  							'UTI_NOM'				=> 'tri.png',
							'USERNAME'			=> 'tri.png',
							'PROFIL'				=> 'tri.png',
							'DIRECTION'				=> 'tri.png'
						);
  		$sort_tag = array(
							'UTI_NOM'				=> 'asc',
							'USERNAME'			=> 'asc',
							'PROFIL'				=> 'asc',
							'DIRECTION'				=> 'asc'
						);
 
		$query = "select u.ID as ID_USER,u.UTI_NOM, u.UTI_PRENOM,u.is_active,u.username as username,u.UTI_EMAIL,u.UTI_TEL,g.NAME as PROFIL , d.edi_cod";
		$query .= " from sf_GUard_user u,sf_guard_user_group ug ,sf_guard_group g, eql_direction d";
		$query .= " where u.EDI_NO = d.EDI_NO (+)";
		$query .= " and u.ID  = ug.USER_ID (+)";
		$query .= " and ug.GROUP_ID = g.ID (+)";
 
  		if($request->getParameter('sort'))
		{
			$query .= " order by ".$request->getParameter('sort')." ".$request->getParameter('sort_type');
 
 
			if($request->getParameter('sort') == 'UTI_NOM')
			{
				if($request->getParameter('sort_type') == 'asc')
				{
					$image_tag['UTI_NOM'] = 'asc.png';
					$sort_tag['UTI_NOM'] = 'desc';
				}
				else
				{
					$image_tag['UTI_NOM'] = 'desc.png';
				}
			}
 
			if($request->getParameter('sort') == 'username')
			{
				if($request->getParameter('sort_type') == 'asc')
				{
					$image_tag['USERNAME'] = 'asc.png';
					$sort_tag['USERNAME'] = 'desc';
				}
				else
				{
					$image_tag['USERNAME'] = 'desc.png';
				}
			}
 
 
			if($request->getParameter('sort') == 'PROFIL')
			{
				if($request->getParameter('sort_type') == 'asc')
				{
					$image_tag['PROFIL'] = 'asc.png';
					$sort_tag['PROFIL'] = 'desc';
				}
				else
				{
					$image_tag['PROFIL'] = 'desc.png';
				}
			}
 
			if($request->getParameter('sort') == 'EDI_COD')
			{
				if($request->getParameter('sort_type') == 'asc')
				{
					$image_tag['DIRECTION'] = 'asc.png';
					$sort_tag['DIRECTION'] = 'desc';
				}
				else
				{
					$image_tag['DIRECTION'] = 'desc.png.png';
				}
			}
		}
 
		$statement = $connexion->prepare($query);
		$statement->execute();
 
		$res1 = array();
 
		while ($resultset = $statement->fetch(PDO::FETCH_ASSOC))
		{
			$res1[] = array(
								'ID_USER'				=> $resultset['ID_USER'] ,
								'UTI_NOM'				=> $resultset['UTI_NOM'] ,
								'UTI_PRENOM'				=> $resultset['UTI_PRENOM'] ,
								'LOGIN'				=> $resultset['USERNAME'],
								'IS_ACTIVE'         => $resultset['IS_ACTIVE'],
								'UTI_EMAIL'				=> $resultset['UTI_EMAIL'],
								'UTI_TEL'				=> $resultset['UTI_TEL'],
								'PROFIL'				=> $resultset['PROFIL'],
								'DIRECTION'				=> $resultset['EDI_COD'],
							);
		}
 
		$this->utilisateur_list = $res1;
		$this->image_tag = $image_tag;
  		$this->sort_tag = $sort_tag;

j'ai adapté mon IndexSuccess.php en consequence.
je perd ma pagination mais je gagne mon sort.

merci bcp pour l'aide !!!

modification d'un module admin [1.x]

Symfony PHP

Discussions similaires

Partager

Partager