Discussion :

[vg33]

Je fais quelques require_once dans des vues, vers des fichiers présents dans le même répertoire que la vue.
Avec ZF 1.5.3, pas de problèmes.
Avec ZF 1.6.0 RC1, échec de tous les require_once().
Qu'est-ce qui a changé dans ce domaine entre les 2 versions ?
Le message d'erreur en 1.6.0 RC1:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Warning: require_once(DisciplineViewForm.php) [function.require-once]: failed to open stream: No such file or directory in zend.view://..\application\modules\manager\views\scripts\discipline/add.phtml on line 2

Si je provoque une erreur de même type dans la 1.5.3 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Warning: require_once(Discipline2ViewForm.php) [function.require-once]: failed to open stream: No such file or directory in C:\Program Files\wamp\www\eclipse\osiris\application\modules\manager\views\scripts\discipline\add.phtml on line 2

[cuisto44000]

essaie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

require_once("DisciplineViewForm.php")

oubien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

include 'DisciplineViewForm.php';

J'espere que sa t' aidera

[vg33]

Je n'ai pas un problème de require (puisque ça fonctionne avec le ZF 1.5.3), mais avec le path utilisé pour les scripts de vue dans le ZF 1.6.0 RC1.

[cuisto44000]

oui mais peut etre que les 2 n'interpretent pas pareil ces fonctions, enfin bon, apres, rien ne coute d'essayer, le probleme ne vient surement pas d'ici, mais essaie quand meme

[vg33]

Ce n'est pas le ZF qui interprète ces fonctions, c'est PHP.
Cela dit, j'ai essayé par acquis de conscience, et cela ne change rien.

[cuisto44000]

ok hihi, je ne voulais pas t'importuner mais parfois on cherche des erreurs bien loin alors qu'elles sont si simples ...

Sinon, es tu sure que le chemin vers ton fichier est bon ? sinon, verrifis que ton fichier ne soit pas protegé en lecture/ecriture/etc... dans les propriétés de celui-ci .

[vg33]

Non, tu ne m'importunes pas, je te remercie de ton aide.
Le chemin est bon, puisque je n'ai pas changé mes scripts mais uniquement la version du ZF. Avec 1.5.3 => tout baigne. Avec 1.6.0, tout bloque.
Je pense que c'est un changement de la façon dont Zend_View intègre les scripts de vue (peut-être un include ?) qui modifie les require dans ces scripts. Mais je n'ai pas vu trace de cette modification dans la release.

[Eusebe]

Bonjour,

est-ce que tu peux vérifier le chemin d'exécution de ton fichier phtml, par exemple en faisant un echo __FILE__ dans ta vue ?

[vg33]

En effet, le chemin a changé.

Avec ZF 1.5.3 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
C:\Program Files\wamp\www\eclipse\osiris\application\modules\teacher\views\scripts\lesson\edit.phtml

Avec ZF 1.6.0 RC1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

zend.view://..\application\modules\teacher\views\scripts\lesson/edit.phtml

[Eusebe]

Oui, il y a bien un changement dans la méthode run() de Zend_View :

Dans la 1.5.2 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
    protected function _run()
    {
        include func_get_arg(0);
    }

Et dans la 1.6.0RC1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
    protected function _run()
    {
        if ($this->_useViewStream && $this->useStreamWrapper()) {
            include 'zend.view://' . func_get_arg(0);
        } else {
            include func_get_arg(0);
        }
    }

Je ne sais pas ce que sont les ViewStream et StreamWrappers...

[vg33]

En effet. Et la doc n'est pas à jour : http://framework.zend.com/manual/fr/....abstract.html

[Yogui]

Salut

En général, dans la vue, pour inclure un autre script on utilise plutôt :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo $this->render('script.phtml');

Le stream wrapper a été introduit dans ZF 1.6 afin de permettre l'utilisation des short tags même si short_open_tag est désactivé

[vg33]

Tu as raison, mais mes require servent à inclure des classes perso de génération de formulaire. Donc je ne peux pas faire un render, à moins que je ne me trompe ?

[Yogui]

En ce cas, ne serait-il pas judicieux de faire un helper ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo $this->nomDuHelper()

[Edit] Pour rappel, Julien Pauli a traduit un article sur le sujet : http://julien-pauli.developpez.com/t...actionhelpers/

[vg33]

C'est une bonne idée.
Mais concrètement, avec cette nouveauté de Zend_View, comment écrire le path pour accéder à un fichier présent dans le même répertoire que le script qui l'appelle ?

[Yogui]

Je ne sais pas, puisque ZF n'a jamais été prévu pour faire comme cela

[vg33]

J'ai une classe de génération de formulaires en XHTML (qui s'appuie sur les données de Zend_Form). Pour chaque controller, j'étends cette classe pour factoriser les formulaires add/edit. Je crée donc une classe que j'enregistre dans le dossier des vues (/view/scripts/) du controller (cela me semble plus logique) => donc autoload impossible => donc require obligatoire.
Est-ce que ce n'est pas une bonne pratique ?

[Yogui]

De mon point de vue, un formulaire est bien plus qu'un script de vue : c'est un modèle. Le formulaire a certes une partie visible (XHTML) mais il a aussi et surtout des interfaces complètes de validation et de filtrage.

De mon côté, je mets les formulaires dans :

application/modules/*/models/Form/*

Avec un PluginLoader, j'ai accès à mes formulaires depuis n'importe quel endroit de l'application.

[vg33]

En fait, j'ai 2 classes par formulaire, pour essayer de séparer au maximum les couches.

Un ControllerForm, placé dans les modèles, qui étend Zend_Form, et qui ne comprend que les données (champs, filters, validators...), aucune info de vue (pas de label, d'exemples, de bouton submit...).
Un ViewForm, placé dans les vues, qui étend ma classe perso de rendu des formulaires, qui ne contient aucune donnée, que les infos de vue (rendu des erreurs, labels, exemples, liens d'aide...). Les données (value, checked, error...) sont extraites de l'objet ControllerForm passé en paramètre au constructeur du ViewForm.

Vue et métier étant complètement séparés, on peut donc faire 2 rendus tout à fait différents du même ControllerForm.

Je sais que ça dépasse le sujet de ce post, mais qu'en penses-tu ?

[Yogui]

Non, je ne suis pas en faveur de cette approche. Pour moi, les contrôleurs dénotent vraiment une interaction directe avec l'utilisateur. S'il y a un contrôleur, c'est qu'il y a des actions (et donc des URLs) accessibles par l'utilisateur et qui lui permettent d'agir sur les modèles.

Si tu as besoin d'un formulaire, je crois que le mieux adapté est de faire comme le suggère Matthew, à savoir d'utiliser un plugin de chargement de formulaires.
Tu peux aussi utiliser des plugins pour décorer les formulaires dans ta vue, si tu souhaites séparer les concepts.