Zend FR

que si que si  tu peut très facilement récupérer tes tableaux
il arrive souvent dans un formulaire de véhiculer des informations qui concerne directement l'objet que l'on manipule et d'autre qui sont plutôt du contexte

par exemple un formulaire pour éditer un objet client et un champ hidden qui dit si c'est un nouveau client ou une mise à jour

dans ce cas il est pratique d'utiliser les nom comme
method
et pour les info client
client[name]
client[phone]

quant au check box pas de problème
client[checkgroup][valeur1]
client[checkgroup][valeur2]
etc.
du coup tu peux très bien récupérer ton client d'une seule opération

$client = $this->_getParam('client');

personellement je n'aime pas utiliser les tableau pour mes objets je fais donc

$client = (object)$this->_getParam('client');

ainsi $client est un objet que je peux manipuler sans difficulté

 $client->name;
$client->phone;
foreach ($client->checkgroup as ckeckname => $value) {
  do();
}

je n'hésite pas nom plus à mettre plusieurs objets dans un formulaire
par exemple j'ai des clients qui on une adresse
mais j'ai aussi des partenaires qui ont une adresse et des fournisseur
un adresse est donc quelque chose d'indépendant d'un client donc dans mon formulaire client je mes les champs
client[name] client[firstname] etc et address[street] address[city]

ça facilite grandement la lecture du formulaire. et son traitement.

j'ai des collègues qui ont pris un convention
oClient sera un objet client alors que aClient sera un tableau
ainsi il ont écrit une methode qui récupère un élément du formulaire en fonction de sont type

$client = $this->_getParam('Client');

retournera un objet si oClient est dans les variables du formulaire
et retournera un tableau si aClient est présent
pour cela il suffit de surcharger _getParam()

mais on peut aller encore plus loin en fournissant un constructeur adapté pour ses objet métier

$client = $this->_getParam('Client', 'Myapp_Model_Client');

qui me retourne un objet de la classe Myapp_Model_Client
il ne me reste qu'à faire

$method= $this->_getParam('method');
$client = $this->_getParam('Client', 'Myapp_Model_Client');
if ($client->isValid()) {
   $client->save($method);
}

Alors oui moi je dis fonce sur cette approche elle à pleins d'avantage.

par contre le code html du formulaire n'est pas exploitable avec d'autre langage que php par exemple c'est plus difficile de prendre le formulaire tel quel pour porter l'appli en java

il faut aussi penser à utiliser des id sur les input de ton formulaire. quand tu veux les manipuler en javascript. en effet sans id le name de l'input est suffisant pour le manipuler. mais en javascript client[name] est un tableau
par habitude je fai sainsi

<input id='client_name' type='text' name='client[name]' value='' />

ça permet d'avoir un ensemble cohérent et de ne pas mélanger les noms de variable de formulaire qui sont à destination du serveur des objets d'édition qui sont à destination du navigateur

A+JYT

<input name="client[checkgroup][box1]" value="toto" type="checkbox"/>

ou

<input name="client[checkgroup][]" value="toto" type="checkbox"/>

dans le premier cas tu obtiends une hashtable les valeurs peuvent donc être identiques client[options][emailInfo]=1 et client[options][newsletter] = 1
dans le second un tableau indicé les valeur son nécessairement différentes
client[options][]=emailInfo et client[options][]=newsletter

il est possible d'imbriquer autant de niveau que l'on veut

<input name="client[person][name]"            value="Sekaijin"   type="text" />
<input name="client[person][firstname]"       value="Jean-Yves"  type="text" />
<input name="client[person][bird]"            value="08/12/1948" type="text" />
<input name="client[address][street][number]" value="6"          type="text" />
<select name="client[address][street][type]">
   <option value="rue" selected="selected">rue</option>
   <option value="bd">boulevard</option>
   <option value="imp">impasse</option>
</select>
<input name="client[address][street][name]" value="Beethoven"       type="text" />
<input name="client[address][postnnumber]"  value="12130"           type="text" />
<input name="client[address][city]"         value="Sainte Affrique" type="text" />
<input name="client[options][emailInfo]"    value="1"               type="checkbox" checked="checked" />
<input name="client[options][newsletter]"   value="1"               type="checkbox" />

mais je n'aime pas trop multiplier ainsi les niveaux ça de rends que très rarement les choses plus simples
A+JYT

Dernière modification par sekaijin (31-08-2007 20:19:42)

je n'utilise pas cette façon de faire. pour moi les paramètre de formulaire restent un objet standard tant que je ne le donne pas au métier (il peut ainsi être mis en session par exemple)
la méthode _getParam ne prends pas en deuxième argument un nom de classe mais la valeur par défaut si le paramètre n'existe pas.

pour ma part j'ai un constructeur d'objet métier qui prends en paramètre soit un tableau soit un objet
et qui affecte les membres.

je peux donc lui passer en argument les données du formulaire.

abstract class Fast_Db_Row implements Fast_Collectionable_Interface {
   public $data = array();

   public function __construct($object = null) {
      if (null != $object) {
         if ($object instanceof StdClass) {
            $object = get_object_vars($object);
         } elseif (is_array($object)&&($object['table'] instanceof Zend_Db_Table)) {
            $this->table = $object['table'];
            $object = $object['data'];
         }
         foreach ($object as $key=>$value) {
            $this->data[$key] = $value; 
         }
      }
   }
   public function setTable($table) {
      $this->table = $table;
   }

   public function add() {
      if (!$this->table instanceof Zend_Db_Table) {
         Zend_Loader::loadClass('Fast_Exception_Db');
         throw new Fast_Exception_Db(Fast_Exception_Db::INVALID_TABLE_OBJECT);
      }
      return $this->table->insert($this->data);
   }

   public function update() {
      if (!$this->table instanceof Zend_Db_Table) {
         Zend_Loader::loadClass('Fast_Exception_Db');
         throw new Fast_Exception_Db(Fast_Exception_Db::INVALID_TABLE_OBJECT);
      }
      return $this->table->UpdateById($this->data);
   }

   public function toStdClass() {
      return (object) $this->data;
   }

   public function __get($key) {
      if (isset($this->data[$key])) {
         return $this->data[$key];
      }  else {
         Zend_Loader::loadClass('Fast_Exception_Db');
         throw new Fast_Exception_Db(Fast_Exception_Db::UNDEFINED_KEY);
      }
   }
}

mon objet métier dérive donc de ça il est conforme à un Zend_Db_Row hor mis son constructeur qui accepte des paramètre plus large.

du coup j'instancie une classe dérivé de celle-ci

class Adm_Model_User_Row extends Fast_Db_Row {
   public $data = array(
         'usr_id' => null, 
         'usr_ident' => null,
         'usr_pwd' => null, 
         'usr_name' => null,
         'usr_firstname' => null,
         'usr_mail' => '@orange-ftgroup.com');

}

et j'utilise cette classe pour lire des objet dans ma base
pour y placer un formulaire j'ai une méthode sur ma classe table

    public function newRow($obj = null) {
      // voir $this->createRow(array)
      $row = new $this->_rowClass($obj);
      $row->setTable($this);
      return $row;
   }

je fais donc

      $formData = $this->_getParam('user');
      $data = $userTable->newRow($formData);
      $data->update();

A+JYT

Mr.MoOx a écrit:

Euh y'a que moi qui utilise $_POST et pas getParam() ???

Euh non, moi aussi
Peut-être parce que je ne connais pas getParam aussi

Ok, mais es ce que ça ne peut pas être considéré comme une faille de sécurité potentiel? Car quand je veux du post, je veux pas un param de l'url...
Mais il me semble qu'il existe un truc genre $this->_request->getPost('tavar'); Mais c'est quand même plus long que $_POST['tavar']....

Okay! Je le note dans un coin de ma 'tit tête!
Merci.

Alala. Comment aurais-je pu douter du framework sur ce niveau...

Dernière modification par Mr.MoOx (23-11-2007 10:18:50)

de faire abstraction de la couche basse du language
les variable $_POST et autre ont déjà changé au fil du temps et des version le framwork lui définit une api qui s'adaptera si besoin au nouvelles version

et si demain tu gères le verbe PUT ou autre tu n'auras pas de variable $_PUT pour récupérer tes billes
ça rend l'interface http homogène c'est tout

à ce propos tu peux surcharger le Request de ZF pour l'améliorer  tu peux par exemple faire du près traitement sur les données transmises et continuer à les récupérer de façon standard dans tes contrôleurs. c'est complètement transparent.

A+JYT

Sekaijin concernant ton input <input id='client_name' type='text' name='client[name]' value='' />
Y a t'il une raison particulière pour que ton id soit égale à 'client_name' et non à 'client[name]'  ??
Y'a t'il un réel interet a les différencier ?

Dernière modification par Moimeme (27-11-2007 09:28:29)