Discussion :

[devlop78]

Oui enfin pour _get et _set c'est pas la réponse pour $view ?

C'est un peu bizarre d'avoir $this->view alors que view devrait être privée ou protégée donc $this->_view et si on veut l'avoir depuis l'extérieur $controllerX->getView() ou $controllerX->getResource('view') mais Zend Fmk est très bien foutu il y a quand même des choses pas cohérentes. Un coup on a des accesseurs getX un autre un accesseur direct simulté avec __get(), bref j'espère avoir bientôt la version 2 qu'ils enlèvent les méthodes magiques.

A part ça, certaines briques sont très agréables.

$form->addValidator(new ...);
$this->getBaseUrl();

Et aussi le toString implicite ça fait bizarre mais c'est pas anormal. Mais par exemple echo $form; je préfère echo $form->render(); ...

[5h4rk]

Un Controller sous Zernd hérite de Zend_Controller_Action et c'est cette classe qui possède l'attribut $view qui est de visibilité public, cela est donc normal que tu puisse y accéder simplement dans les controllers avec $this->view.

Les accesseurs c'est quand on accède à des attribut du autre classe pas quand il y a de l'héritage, ce n'est pas spécifique à Zend.

Pour le toString implicite je trouve cela tout à fait normal, car comme en java il y a des toString implicite, mais attention ce n'est pas tout le temps le cas comme en java

[devlop78]

le toString implicite n'est pas critiquable en soit, ca fait juste vraiment bizarre. Les placeholders, c'est pire

public $view;

Ooooh, je suis choqué. En gros, depuis un plugin, je pourrais faire $controller->view = "coucou".

Impossible, il y a anguille sous roche ... Ils le disent eux mêmes :

/**
* View object
* @var Zend_View_Interface
*/

Il est sensé être une instance de Zend_View_Interface ou spécialisée. Non vraiment, je ne comprends pas ...

[devlop78]

Je cite http://framework.zend.com/manual/fr/...nventions.html :

Pour des méthodes d'objet qui sont déclarées avec la construction "private" ou "protected", le premier caractère du nom variable doit être un tiret bas simple ("_"). C'est la seule utilisation autorisé d'un tiret bas dans un nom de méthode. Les méthodes déclarées "public" ne devraient jamais commencer par un tiret bas.

Je cite Zend_Registry :

public static function _unsetInstance()
{
self::$_registry = null;
}

Trouver l'erreur ? Ok, ce n'est pas une méthode d'objet mais une méthode de classe, mais quand même ...

[5h4rk]

Merci d utiliser l option éditer à l avenir

Ton exemple n est pas bon du fait que ce soit une methode static du cout une methode static n a aucun interet d etre private ou protected, et sa visibilité n est pas vraiment public protected ou private c est un cas à part, par contre si tu trouve une methode simplement public avec une telle notation c est qu il y aura confusion

[devlop78]

Là je ne suis pas d'accord, la visibilité d'une méthode ou d'une propriété n'est pas influencée par le fait qu'elle agit sur la classe ou sur l'instance. Et je suis tombé d'accord tout de suite sur la convention de nommage de Zend, et ce serait bien jouer avec les mots que de ne pas inclure les statiques dans leur règle de nommage.

Du par le principe qu'à part l'interface de la classe je mets tout le reste en privé ou protégée, pour éviter la redondance du code, j'aurais obligatoirement un moment donné une méthode statique privée ou protégée.

De plus le langage le permet, ce n'est pas pour rien. Et j'ai fait l'effort de chercher un exemple :

Zend_Crypt :

protected static function _detectHashSupport($algorithm)
{

Ici, on a bien le underscore. Il est possible que ce soit une erreur sur l'autre, pour moi ça n'a pas de sens. Evidemment, il faut s'adapter à la fois aux choix des développeurs et à la fois aux erreurs surtout si elles ne provoquent pas de beug. Je ne cherche pas non plus à avoir raison absolument, mais à faire triompher la vérité ^^

Oui, je n'ai pas pensé à éditer (là j'ai tort ).