Zend FR

Bon je continue ma petite réflexion...et je vous en fait part (suis sympa heing  ?? )
Alors en fait je vais partir du principe que le format des dates par défaut c'est le format Francais.
Mon modèle parle en anglais donc c'est a lui de faire le formatage.
Voila !

Dernière modification par bertra (25-04-2008 11:00:04)

Bah tout depend non ? Moi j'ai eu à le faire dans une vue. Je devais utilier isToday() et isYesterday(), suivant cettecondition je devais formaté la date

Sans aucun doute c'est dans le contrôleur

la raison est simple le modèle dois rester indépendant de tout le reste en théorie il doit être utilisable en dehors de l'appli.

La vue travail dans le format de l'utilisateur elle détient donc la langue utilisée. mais elle n'a pas à savoir comment est codé l'information dans le modèle. (si un jour le modèle change de format internet cela ne doit pas impacter la vue) Donc la vue ne peu et doit pas connaître le format de date du modèle? Elle ne peut donc pas assurer la conversion.

reste le contrôleur qui lui connaît la vue et le modèle. lui seul à toute la connaissance nécessaire de faire le formatage.
dans l'idéal il devrait pouvoir demander à la vue le format de date à utiliser et au modèle le format qu'il utilise.
et donc faire quelque chose comme

$this->view->birthDate = $this->_convertDate(
   $this->model->getDateFormat(), 
   $this->view->getDateFormat($this->view->getLocale()),
   $this->model->getUser()->birthDate
);

a+JYT

Je répondrais les trois mon général

le modèle doit s'assurer que les dates sont au format attendu par la ressource (I.E. la base de données, l'annuaire LDAP, le fichier xml, etc)

la vue doit s'assurer que la date est affichée dans le format lisible par l'utilisateur.

reste le contrôleur.
lui n'a pas à connaitre de format de date qui lui est propre.
par contre les échangent entre le contrôleur et le modèle se font au travers d'une API, qu'on l'ai explicitement définie ou pas. en clair l'ensemble des méthodes que le modèle mets à disposition du contrôleur ou des autres modèles. ces méthodes si elle utilise des date dans les objet retournée ou les paramètre doivent spécifier comment est défini une date. mieux vaut utiliser le même format pour toute l'API mais on peut choisir d'en utiliser plusieurs.

de même dans ses échange avec la vue (placement de valeur dans la vue ou lecture de donnée issue de l'utilisateur) il peut y avoir échange de dates. là encore il est préférable d'utiliser un seul format mais ce n'est pas toujours possible.

mieux vaut aussi choisir si possible le même format dans l'API avec le modèle que dans les échange avec la vue.

qui convertit quoi
le modèle convertit si nécessaire les données de la ressource dans le format de l'API. de même il convertit du format de l'API vers celui de la ressource.

la vue convertit les données de l'échange avec le contrôleur dans le format attendu par l'utilisateur.
dans la théorie ce devrait être la vue qui fournit au contrôleur des donnée dans le format d'échange mais dans ZF c'est le contrôleur qui récupère ces valeur et non la vue c'est donc lui qui devra se substituer à la vue.

le contrôleur quant à lui en théorie doit convertir dans les deux sens le format de l'API vers celui d'échange avec la vue.

on vois vite que si la théorie offre une solution qui garantie le maximum involutivité elle n'est pas très efficace.

+------------------------------------------+
|   vue format d'affichage et de saisie    |
+------------------------------------------+
                   ^
                   | format d'échange
                   v
+------------------------------------------+
|     contrôleur pas de format propre      |
+------------------------------------------+
                   ^
                   | format de l'API
                   v
+------------------------------------------+
|      Modèle format de la ressource       |
+------------------------------------------+

déjà on peut en réduire beaucoup
utiliser le même format dans la ressource l'API et le format d'échange
avec la vue c'est moins simple car il faut que ça reste lisible pour l'utilisateur et il peut y avoir du multilinguisme

on peut aussi choisir la stratégie inverse si la ressource le permet le contrôleur dans l'api transmet le format dans le quel travail l'utilisateur et la ressource format les donnée dans ce format

pour ma part j'utilise ExtJS dans mes vue et celui-ci offre l possibilité de définir dans la vue le format d'échange indépendamment de la langue utilisée les donnée date monnaie etc sont automatiquement convertie les champs utilise le format définie pour la langue de l'utilisateur

du coup j'utilise soit le format SQL de bout en bout soit le format iso8601 de bout en bout
je n'ai donc pas de conversion de date.

pour finir on peu noter que le modèle peut fournir un service de conversion qui peut alors être utilisée par le modèle ainsi que par le contrôleur.

A+JYT