Zend FR

Bonjour,

Là c'est une fonction qui est complètement indépendante du reste de ton appli. Tu n'as pas de raison de la lier au MVC du ZF.

Bref à mon avis tu as deux solutions :
- la version simple : tu crées une fonction globale (tu dans un fichier que tu inclus dans ton bootstrap par exemple). Là tu y as accès partout. Les puristes vont hurler parce que si tu utilise ensuite un autre programme qui définit la même fonction ailleurs, PHP va raler... mais bon, souvent ça marche bien...
- la version de puriste : tu crées un singleton avec cette fonction dedans... Je te laisse fouiller sur Internet pour voir ce que c'est. Je pense que dans ton cas, ça n'est pas forcément utile tout de suite...

A+, Philippe

Ca se défend, c'est la 3e voie, intermédiaire

Les fonctions statiques c'est pas trop mon truc (même si dans ce cas, ça s'applique très bien). A un moment où à un autre on finit par vouloir étendre sa classe ou modifier son comportement; et là avec les fonctions statiques, ça devient rapidement l'enfer (le meilleur exemple pratique étant Zend_Session qui est je pense le code le plus pourri du ZF... essayez de modifier le comportement de Zend_Session sans toucher au code du ZF pour voir)...

Bref, on a tous nos manies... moi j'aime pas les fonctions statiques... c'est pas négociable, je suis buté comme une mule

A+, Philippe

PS : ça ira peut-être mieux en PHP 5.3 avec des héritages un peu meilleurs des variables et fonctions statiques...

il y a beaucoup simple que ça
tu créé une classe Application_Action qui dérive de Zend_Action
là tu y place toute les méthodes commune à tous tes controllers
et tu fais dériver tes controllers de Application_Action ainsi ils en en hérite tout naturellement.

Tu as respecté le modèle objet, tu as conservé les design pattern MCV et tu n'as fais qu'une simple classe

A+JYT

Je complète en disant qu'une méthode statique est environ 2 à 3 fois plus rapide à invoquer qu'une méthode demandant la création d'une instance.

J'utiliserai une méthode statique aussi de mon coté, et plutôt trim() que str_replace()

Bonsoir,

quitte à être vraiment puriste, pour une méthode comme celle-ci, je dirai qu'un Zend_Filter serait tout à fait approprié, du genre :

class MyUrlFilter implements Zend_Filter_Interface
{
    public function filter($value)
    {
        // ici tes remplacements dans la chaîne $value
        // à ce propos, qu'est-ce que tu as contre urlencode() ?? ;)
        return $value;
    }
}

tu places ça dans un dossier type /lib/, ou quoi que ce soit d'autre dans ton include_path, puis tu l'utilises comme suit, dans tes contrôleurs ou ailleurs :

$filter = new Filter();
$filter->addFilter(new MyUrlFilter());
$urlFiltree = $filter->filter($urlPasFiltree);

Hello,

J'ai répondu pour ma classe "fourre-tout" (rassurez-vous elle n'a que peu de fonctions ).
Dans ce cas précis, j'aime bien le filtre en fait. Pour ceux qui trouve l'application trop verbeuse :

$filter = new Filter();
$filter->addFilter(new MyUrlFilter());
$urlFiltree = $filter->filter($urlPasFiltree);

Il y a aussi la forme courte :

$urlFiltree = Zend_Filter::get($urlPasFiltree, 'MyUrlFilter');

A+

Hello,

Ca fait un peu combat de coq votre discution

C'est vrai que vu de loin, ça peut paraître mesquin.

Mais pour ma part, comme je code toujours de la même façon (enfin presque), avoir des opinions différentes et des façons de voir les choses différentes est toujours intéressant.

Tant que cela ne tourne pas à "voici la solution miracle que vous devez tous adopter"

A+

oui tout a fait c'est intéressant de confronté les point de vus car ça permet de dégager des éléments qui ne transparaitraient pas sans ça.

ça permet aussi de voir où son propre discourt à introduit de l'ambiguïté et ainsi de mieux cerner les propositions.

Donc ni combat de coq ni querelle de chapelle juste la rencontre de plusieurs approche.

J'ai pour habitude de dire que la meilleure solution est celle que tu maitrise le mieux.

A+JYT