Incohérences dans Zend Framework

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(); ... ;)

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

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 ...

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

Citation:

---

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 :

Citation:

---

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 ...

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

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 :

Citation:

---

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 :)).

Il est vrai que certaines classes de ZF ne respectent pas complètement les conventions de nommage... pour l'exemple, il y a une 40aine de fonctions ayant une visibilité public mais commençant par un '_'... (regex : public.*function _[a-z].*())
Après, on peut remarquer qu'elles sont, pour une majorité, des fonctions liées à un fonctionnement interne mais inter-composant.
Il est donc probable que ce petit écart de nommage soit voulu pour tout simplement dissuader les développeurs d'utiliser de telles méthodes (qui ne leurs sont pas destinées).

Si vous voulez un exemple il suffi de regarder _cascadeUpdate() de Zend_Db_Table_Abstract... Elle est appelée par qui ?

Citation:

---

Called by a row object for the parent table's class during save() method

---

Après, ce n'est que ma théorie !:aie:

C'est plausible. En gros elles sont public par manque de choix mais privée dans la théorie (explication bof bof hein).

Ca me fait penser à une classe que j'avais faite. C'est un arbre. Quand tu accroches un noeud à un autre, tu dis au noeud parent d'ajouter un noeud pour qu'il devienne un noeud enfant. Le noeud parent demande donc au noeud d'être son père, mais si lui peut le faire, tout le monde peut le faire aussi, et alors qu'il y a des vérifications pour éviter qu'un noeud est plusieurs pères (ou plutot que plusieurs pères aient le même noeud) et pour éviter qu'un noeud ait un noeud descendant comme parent, il était tout à fait possible en gros de dire noeud.setParent(noeud);

Donc effectivement, ça ressemble à ce cas. Après en y repensant, peut-être qu'une méthode statique aurait permis de faire l'intermédiaire, et encore je ne suis pas sûre (mais pas du tout), qu'elle aurait pu avoir accès à des méthodes privées des instances. Bref, j'avais utilisé un autre outil (pour tracer les appels dans le code), mais ça reste moyen ;) P-e une solution à laquelle je n'avais pas pensée (mais svp ce n'est pas le débat du jour !!).

Je ne dis pas que tu as tort ou raison, ce n'est pas la question. Mais comme tu le dis ils ont pu faire une erreur ou encore cela est normal mais on ne sait pas pourquoi d'ailleurs Alcide propose une hypothétique réponse.

Ce que je veux dire c'est qu'on ne dis pas qu'ils ne respectent pas leur convention en donnant un seul exemple qui par ailleurs n'est pas un simple public static function.

Tu aurais donner plusieurs exemple sur des méthode public non static je ne dis pas mais là c'est loin d'être le cas.

EDIT: J'ai découper la discussion car elle n'avait plus aucun rapport avec celle d'origine

Il n'y a pas qu'un seul exemple mais 45 fonctions (dont 3 static) dans 32 fichiers (zf 1.11).
Pour étayer ma thèse voici ce que j'ai trouvé en commentaire de la fonction _flush() de Zend_Cache_Frontend_Capture :

Citation:

---

(shouldn't really be called manually)

---

et, cerise sur le gâteau, pour la fonction _addZendLoad() de Zend_Dojo_View_Helper_Dojo_Container :

Citation:

---

* This method is public, but prefixed with an underscore to indicate that
* it should not normally be called by userland code. It is pertinent to
* ensuring that the correct order of operations occurs during dijit
* creation.

---

Donc ma théorie n'est plus si hypothétique que ça :aie:

Donc ça rejoint bien ce que je pensais et que c'est bien voulu et surtout différent des autres méthodes public, merci des précisions que tu as apporté.

Je pense qu'on ne pouvait pas donner de plus claires explications que celles que tu viens de donner et je t'en remercie.

Oui c'est pas bête du tout, et s'ils le disent ... D'ailleurs, je me suis trompé (j'avais une grosse hésitation, pas bien ça ...) une méthode de classe peut appeler des méthodes privées d'instance de la même classe. Tu as eu raison de découper on a carrément dérivé.

En ce qui concerne la simple méthode, la thèse ne tient pas pour elle puisqu'elle est présentée dans la doc pour libérer la mémoire (si j'ai bien suivi car là je ne sais plus de quoi on parle presque). Que j'ai tort ou pas, je trouve, et j'aurais aimé savoir la vraie raison, que la méthode n'est pas logiquement nommée, tout comme je n'ai pas d'explication sur le choix de $view en public pour le controller (pour le coup la convention de nommage est respectée), alors que leurs classes sont généralement (enfin, de ce que j'en ai vu) bien encapsulées.

[..] Coupé. Je coupe le reste, je trouve que la discution est un peu stérile (faut avouer ...). On aura certainement le loisirs d'y revenir plus tard, j'ai aussi besoin d'approfondir dans le framework pour mieux le cerner. Bonne soirée.

Ce sont de tels échange qui sont constructifs pour chacun, que l'on connaisse ou non l'on cherche à comprendre.

On se contente pas d'utiliser un framework on cherche à le comprendre.
ça me fait penser, durant mes études, un intervenant donnant des cours sur cakephp nous as dit de ne jamais regarder dans le framework car c'était inutile et on mettrait les mains dans le cambouis, à chacun de mes questions, je n'ai jamais eu de réponse ...
C'est ses explications qui m'ont amené à m'interessé à un autre framework dont Zend.