Reprise du message précédent :
drapal. \o/

Pour ceux qui voulaient un retour sur le Zend Framework:
 
http://snook.ca/archives/php/zend_ [...] pressions/
 
Conclusion, c'est vachement bien, il y a plein de trucs utiles, mais c'est pas un framework web (encore moins MVC) à la CakePHP ou Symphony. Par contre ça s'intégre très bien aux frameworks existants (tout du moins à Cake et Symphony, d'après le post et les commentaires), et là ça devient apparement très sympas (en bref, ZF est une sorte de grande lib d'utils)

 
c'est un peu ce que la description du bouzin sur le site laissait deviner...ça peut être sympa, mais c'est pas plus qu'un gros paquet de libs collées les une aux autres...

Disons que t'as une sorte de garantie qualité sur les libs, surtout sur les libs pour s'interfacer à des services externes où là tu peux trouver tout et n'importe quoi.

Comme je le disais, ça vient des devs de PHP, donc non t'as aucune garantie de qualité sur les libs, parce que quand tu vois la stdlib php...

C'est ce que devais être PEAR à la base. Mais le ZF est beaucoup plus consistant et mieux pensé

Pear c'est le boxon, donc heureusement.

 
Ça va encore, je pense qu'il y a pear ... ahah ... ah ah ahahahaha ahaAHAHHAHAHAHAHAHAHA
 

Je peux mourrir, j'aurais tou vu

Shinuza > Tu peux pas mourrir, t'as pas encore vu mon site.

T'as pas vu mon cul non plus

Mes templates ?

Tiens, j'ai cette methode aussi...
 
Par contre le coup du return si le fichier n'existe pas, c'est vraiment top pour le tracking

Pour les données, mon $_data squatte dans la classe. Puis un __get permet d'accéder aux variables.

Oué en fait c'était tout con, en plus je connais très bien extract ... je sais pas pourquoi j'y ai pas pensé.
 
__get est une solution aussi oui, mais je me sers de __get et __set pour balancer une erreur en interdisant d'affecter des vars non existantes
 
Au final ma classe ressemble bcp à celle de NazzTazz (et j'ai juste eu à ajouter extract($this->_vars); pour arriver à ce que je voulais, stoo
 
Merci en tout cas

Moi je trouve ca pourri a cause du simple fait que les donnees de la view sont passives.
 
Je prefere les views actives et +1 a  __get, __set et __call et plus de php !

 
C'est à dire ?

Par exemple agrementer la view des capacites suivantes:

- pre|post filtrage automatique ou controler: une couche de plus de filtrage si le modele n'a pas rempli son role ou pas completement. Ce qui est des injections XSS ... Si une transformation des donnees modeles plus importante est a faire, alors la view pourra revenir chercher ses donnees dans le modele, histoire de pas avoir a se refaire  
une dizaine de template.

- generation de code html par la view

- simplification de l integration des librairies javascript et donc d ajax

- raccourci rapide sur les objets du modele. Par exemple la traduction.

Pour cela pas besoin de detruire le design existant. Tu composes et a l'execution la view s'occupe du reste. Il faudra juste savoir s'arreter avant que les retour sur le modele ne deviennent trop important. Entre  nous je trouve ca beaucoup mieux que les plain old php templates ou le modele capable de resoudre tous les problemes.

Suggestions ?

Hum ... 'suis pas convaincu mais bon, je suis loiiiiiiiin d'être un expert en la matière donc mon jugement ne compte pas

 
La vue est active dans le sens où elle peut avoir à formater les données fournies par le controleur pour l'affichage.
Par exemple transformer un timestamp unix en "mardi 17 juillet à 07:15", c'est le boulot de la vue.

C'est pas très actif ça, c'est juste de la transformation des données fournies par le modèle et le contrôlleur à des fins d'affichage, ce qui est exactement le rôle de la vue

 
bah c'est la seule chose qui rend la vue "active" pour moi.
Par opposition avec un simple include d'un template comme vu plus haut...

Le template fait quasiment partie de la vue, d'un point de vue logique - même si ce n'est pas le cas point de vue objet.

Mais on peut imaginer que la vue dispose de fonctions pour effectuer ce genre de tâches, et qu'elles pourraient facilement être un poil plus complexes qu'un simple date().
Par exemple prendre en compte les timezones, ou la langue demandée. Si tu déportes des choses de ce genre dans le template tu as très rapidement un template imbitable...

bof, suffit d'avoir un langage templating adapté imo

 
Question de point de vue. Pour moi dans l'idéal le template doit se contenter d'afficher les données que lui passe la vue.
Et ça me parait encore plus indispensable si une personne autre que le develo peut être amené à travailler sur l'affichage via les templates et les feuilles de style.

Dans un peu tous les framework, ça s'appelle les helpers
 

Si on utilise PHP comme langage de template ?

 
Si tu veux. Mais ça change rien au problème.

J'ai parlé d'un langage adapté, ça exclus PHP de facto.

Stéfépourçakanmeme à la base, l'histoire ne parle pas du succès ou non de l'entreprise

Ouais. Quand ca devient trop complexe, on refactorise en objet model.  
 

Monsieur est au courant de tout
 
 

La reponse est donnee par florentg.  

[3615 mylife] Cette discussion est hallucinante. Je navigue continuellement entre "j'ai tout compris" et "de quoi qu'y cause". Là, j'en suis quasiment à "de quoi qu'y cause"?  
[/3615 mylife]  
 
Ceci dit : où se situe la limite entre un "helper" et un traitement mal placé?

 
un helper est là pour reformatter une donnée spécifiquement pour l'affichage. Il ne modifie en rien l'état des données.

Ca peut aussi (même si ça se rapproche assez de la partie controlleur) proposer une structure conditionelle

"Helper" designe pour moi une fonction qui a pour but de "m'aider" à afficher une données, ou bien à la formater correctement en html.  
Un Helper ne doit en aucun cas couvrir des fonctionnalités déjà offertes par le modèle ou le controlleur, car dans ce cas on duplique du code et c'est la porte ouverte à de graves problèmes d'évolution et de maintenance.

Je prefere avoir des helpers obsoletes plutot qu un modele. Et comme je l ai dit plus haut, c'est de la composition donc ya tres peu de risque d'arriver a des cas comme tu les decris.

De plus ca apprend a distinguer les bouches trous , des pieces vitales.

Une chose qui serait bien est que vous postiez des exemples car j'ai un peu de mal à concevoir tout ce dont vous racontez Je ne pense pas être le seul
 
MERCI