mailRe: [Galette-discussion] Question de débutante : uti liser les classes et Zend DB


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Johan Cwiklinski on September 24, 2011 - 10:27:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

Le 24/09/2011 09:33, Mélissa Djebel a écrit :
En fait, je viens du C#/.Net, donc ça me change beaucoup le PHP Objet.
Ma 1ère difficulté a été de trouver un éditeur PHP avancé, mais j'ai
trouvé NetBeans et j'en suis pour l'instant assez content. Il supporte
même le debug, c'est pas top, mais ça marche bien quand même.

J'utilise Netbeans aussi ; il y a des imperfections, mais ça fonctionne
pas trop mal :)

//les champs désactivés (les mêmes que sur self_adherent) - optionnel (à
priori)
$inactifs = $a->disabled_fields + $a->edit_disabled_fields;

Là, j'ai été obligée de faire un $inactif = array(); car sinon les
bonnes valeurs passées n'étaient pas stockées (justement les valeurs que
l'utilisateur n'a pas le droit de changer). Sauf que j'initialise ou
créé un utilisateur, donc j'ai besoin de pouvoir les écrire.

Oui, en effet, je n'ai pas regardé assez attentivement :-)


$ok = $member->check($valeurs, $requis, $inactifs);

Je l'aurais jamais trouvé cette méthode!
J'ai l'habitude du C# où l'on a des propriétés publiques avec des
champs privés:
private int id_adh;
public int AdherentId{
get{ return id_adh; }
set{ id_adh = value; }
}
On peut affecter des valeurs à un objet, finir avec objet->store() et
les valeurs affectées sont stockées en base comme on s'y attend. Avec
adherent, ce n'est pas le cas, si on affecte des valeurs à ce qu'on
suppose être les variables, il se passe rien, ça reste vide :-(

Dans Galette, c'est voulu. Pour qu'on ne puisse pas attribuer de valeur
arbitraire à une variable de classe, ces dernières sont toutes déclarées
privées ; toute tentative d'assignement lèvera une erreur dans le log
d'apache (lorsque l'on développe en PHP, il est important de conserver
régulièrement un oeil sur ces logs ;)). Il n'est d'ailleurs pas possible
non plus de lire directement ces variables en fait.

Il ya a donc plusieurs solutions utilisées dans Galette pour assigner
des valeurs aux variables privées des différents objets (en fonction des
cas) :

1- l'utilisation, comme en Java, d'un getter et d'un setter par variable :
private $_nom;
public function getNom() { return $this->_nom; }
public function setNom($s) { $this->_nom = $s; }

2- l'utilisation des méthodes "magiques" __get et __set. La logique est
la même que pour le 1- ; sauf qu'on a pas a déclarer un setter/getter
par variable ; tout passe par la même fonction.

Dans l'objet adhérent ; on a un __get qui permet de récupérer les
valeurs des variables ; mais aucun setter, c'est la fonction check() qui
se chargera de ça. Ce n'est peut-être pas la meilleure idée, puisque ce
n'est effectivement pas comme ça que c'est fait ailleurs ; mais c'était
le plus simple pour moi sur le coup ;)


Bref, je n'arrivai pas à comprendre quelles variables étaient utilisées
dans l'application et quelles variables étaient utilisées par Zend DB
pour faire les insert/update.

//si tout est OK, on peut enregistrer dans la base
if ( $ok === true ) {
$member->store();
}

J'ai enfin réussi tard hier soir à faire mon insert depuis mon import.
Il me manque juste un p'tit problème : les accents ! Ah! Ah! Ah! Les
bons vieux problèmes d'encodage d'accents !

J'ai un "é" dans la base, et ça me donne "�" à l'écran !

Là je sors mon joker :-D

Tu ne précises pas l'encodage dans le script de création de la table que
tu as envoyé hier ; regardes comment sont crées les tables (cf.
install/sql/mysql.sql) ; il y a des chances que ça vienne de là.


Le système de plugins tel qu'il est implémenté actuellement reste très
rudimentaire ; je me suis cantonné à implémenter des fonctionnalités
complètement annexes, rien encore qui modifie ou étende la fiche adhérent.

Exact, dans notre cas, on aurait besoin de pouvoir dire si un champ est
modifiable ou non par l'utilisateur. Par exemple, le login ne devrait
pas pouvoir être modifiable, le reste pourquoi pas, mais le login non.
Si on pouvait ajouter la fonctionnalité à l'admin de choisir quels
champs sont modifiables ou non, ça serait cool ;)

Pour le moment, ce n'est pas prévu ; j'avais voulu un temps faire
quelque chose de plus poussé que les seuls champs requis, mais ça posait
des problèmes que je n'ai pas eu le temps/le courage de résoudre :/

En attendant, dans la classe Adhérent, il suffit d'ajouter les champs à
ne pas modifier dans le tableau edit_disabled_fields.


En espérant que ça aide un peu :-)

Ben oui, j'aurai jamais trouvé la bonne méthode au milieu pour stocker
mon adherent, maintenant c'est fait, je vais pouvoir faire la même chose
avec le complément spécifique.

Merci,

Mélissa

Bonne journée,
Johan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk59lHwACgkQ7N2B+4uln5QONwCg6UeUWzB47ovIR7OERWq8w7qq
SfIAoKg+OL6j8FB7AZ0/bghP81IMstSV
=MzP1
-----END PGP SIGNATURE-----




Related Messages


Powered by MHonArc, Updated Mon Sep 26 15:00:11 2011