Reprise du message précédent :
Nan, c'est la vérité, arrête d'être de mauvaise foi comme ça

Attends, c'est quand même toi qui essaie de faire croire qu'il y a eu une phase de conception impliquée dans la création du parseur PHP je rappelle

Et franchement, quand je vois ça en me balladant sur l'internet:

http://www.sitepoint.com/blogs/200 [...] mment-1961

lol quoi. Ca a sûrement été corrigé depuis (ça a été posté en 2005), mais ça va un peu à l'encontre de ta déclaration que le parser PHP est "le plus efficace possible"

No comment.

Bah déja le fait que le parseur parse les chaines entre quotes est une connerie, avec la concaténation t'as pas ce genre de problème, ou alors y'a une syntaxe/fonction particulière (genre printf) pour explicitement parser la chaine.
 
En dehors de ça, le langage n'a aucune souplesse parce qu'il n'a pas de grammaire,et à l'inverse tu peux écrire plus ou moins n'importe quoi des que la chaine commence par un "$", parce que finalement un fichier php c'est une enorme chaine de caractère

Ca tu le retrouves quand-même dans d'autres langages, hein... Faut arrêter de toujours blâmer PHP pour des choses qu'on retrouve ailleurs. Y'a exactement la même chose en perl, et là bizarrement personne vient critiquer.
 

C'est justement ce que je dis : leur parser pourri n'autorise rien. Il auraient dû tout de suite mettre un opcode cache, ça aurait permis de faire un parser beaucoup plus complet avec plus de fonctionnalités/possibilités. Vu la nature ultra-dynamique du langage, les possibilités pourraient être beaucoup plus grandes... Mais nan, rien à faire

Oui mais non, ça c'est une fonctionalité potentiellement intéressante, en Ruby c'est super pratique pour formatter lisiblement des chaînes.

Nan mais le problème c'est que tu pars des mauvaises hypothèses, ce qu'ils auraient dû faire c'est surtout embaucher des gens qui savent écrire des parsers, ou créer une grammaire solide pour utiliser un des gigazillions de parser generators du marché (à noter que la première option n'exclut pas d'écrire une grammaire), et c'est pas parce que t'as un opcode cache que t'as le droit de faire un parser pourri, et enfin c'est pas parce que le parser a plus de possibilités qu'il est nécessairement plus lent

Ah nan mais je suis d'accord avec toi
 

Bah devine quoi, ils utilisent justement YACC pour leurs parsers      
 
PHP : we don't just use existing technologies, we use them badly

 
Masklinn, ou l'art de ne jamais être d'accord !
 
Y'avait une offre promotionnelle sur les esprits de contraction ?
 
BOn en tout cas je ne suis pas d'accord, si tu veux faire une chaîne formatée proprement tu utilise sprintf (et ses variantes) qui sont faites pour ça...
 
Je trouve ça d'un déguelasse de foutre directement des variables dans une chaîne entre quotes

Oui et non, ça permet aussi de savoir directement ce qu'on insère sans avoir à faire des allers et retours entre la chaîne et les paramètres.
 
En Ruby, ça marche vachement bien

Masklinn entrein de dire du bien d'une des fonctionalités (c'est un bien grand mot) de base de php?
Je pensais pas voir ça un jour.

C'est sûr, mais y'a pas la concat pour ça ?

Enfin bon, en ce qui me concerne je trouve 10 fois plus clair de faire ça :

$var = 'Ma super phrase pleine de ' . $variable . ' qui en a une par ' . $ici . ' et une autre par ' . $la . ' et une ' . CONSTANTE . ' et une ' . $derniere_variable;

Ou ça :

$var = 'Ma super phrase pleine de ' . $Class->variable . ' qui en a une par ' . $Class->ici . ' et une autre par ' . $Class->la . ' et une ' . CONSTANTE . ' et une ' . $Class->derniere_variable;

Que ça :

$var = "Ma super phrase pleine de $variable qui en a une par $ici et une autre par $la et une " . CONSTANTE . " et une $derniere_variable";

Ou ça :

$var = "Ma super phrase pleine de {$Class->variable} qui en a une par {$Class->ici} et une autre par {$Class->la} et une " . CONSTANTE . " et une {$Class->derniere_variable}";

(bien que je trouve la dernière assez lisible et moins crade que la précédente)

Mais bon, quand je reprends un code avec toutes les variables directement dans les chaînes, ça me gave... et en plus t'es obligé de concaténer quand même les fois où tu utilise des constantes.

Edit : Tiens, je me croyais dans le topic blabla en plus

La dernière est pas mal et pas trop lourdingue

A moins qu'il y ait une autre manière que

d = 6
puts "ok #{d}" //ok 6

parce que

d = 6
puts "ok d" //ok d

on parle pas de la même chose.

Ruby utilise une syntaxe particulière à l'interieur de la chaine de caractère pour le formatage en question, alors que php utilise la même syntaxe pour les chaines à l'intérieur et à l'extérieur des quotes (un simple $var donc)

FlorentG : Je fais pas de perl
DJYell : Je pense que la coloration syntaxique joue beaucoup. Même dans Notepad ++

et

ne sont pas rendu pareil

Yo
Dans mon site j'ai ça :

Un script "controler.php" sur laquelle arrivent toutes les pages à afficher (avec des paramètres différents)
Un script par page, ex "page_panier.php", contenant une seule classe, qui elle contient
- Une méthode "métier" qui prépare les données à afficher (c'est bien ça une couche métier ? )
- Une méthode "affichage"
J'ai aussi des scripts du même genre que "page_panier.php" pour les menus.

Au final, controler.php appelle toutes les méthode métier, puis toutes les méthodes d'affichage, dans l'ordre voulu.

Est-ce qu'on peut appeller ça un MVC ?
Ou est-ce que j'ai rien compris et que le but d'un MVC n'est pas simplement de séparer temporellement le traitement des données et leur affichage ?

C'est à peu près ca, mis à part que la couche métier (le modèle) n'a pas de rapport avec la vue et vice-versa

C-a-d ? ils devraient ou pas ?

Ta méthode métier et ta méthode affichage ne doivent pas être liées.
 
Par exemple ton panier tu peut très bien l'afficher en petit sur toutes les pages du sites (accueil, produits etc) et donc devoir charger le modèle panier tout le temps, mais tu chargera la vue panier uniquement pour la page panier. C'est le controlleur qui choisit quels modèles et quelles vues charger selon la requete.

Ici c'est bien le cas, seulement il est vrai que dans mon truc une vue X est forcément attachée à un modèle X, puisque ce modèle à pour rôle de préparer la vue
 
Donc en fait je vois pas ce qu'est un modèle si c'est pas un truc qui prépare une vue...

Le modèle doit simplement charger des données, depuis la bdd par exemple.

Ici on peut dire que le controlleur va charger le modèle, lui demander de créer un array avec le panier, puis passer cet array à la vue qui elle va boucler dessus pour créer la liste de produits par exemple.

Edit : bien sur c'est aussi le modèle qui va créer les données, les modifier, etc...

C'est là qu'est l'erreur, c'est au controller de faire ça (il transmet les données tirées du modèle à la vue)

C'est le gestionnaire des données métiers, c'est souvent un ensemble de classes gérant un accès DB par exemple, mais ça peut tout aussi bien être une autre source de données (feed, interface SOAP ou autre, ...)

Ah Ben ça j'ai aussi, j'ai un ensemble de classes regroupées contenant toutes mes requetes, appelées depuis mes méthodes metier(). Du coup ce serait ça mon modèle

Ca ferait :
- mes classes BDD = Modèle
- mes méthodes affichage() + fonctions/classes html regroupées = Vue
- tout le reste = Contrôleur

Ce qui est bizarre c'est que ok les 3 sont bien séparés, mais ils ont des formes et des tailles carrément différentes

Alors MVC ou pas ?
En fait la séparation M/V/C, c'est une séparation "physique" et non pas forcément "chronologique" ?

En gros, sachant que les "méthodes d'affichage" c'est principalement les méthodes de rendu des templates pour du web.

Ben c'est un peu normal, vu qu'ils font pas la même chose

C'est une séparation logique entre des "composants" n'ayant pas de raison d'être fortement couplés.
 
Mais franchement, ce serait probablement plus simple si tu utilisais un framework existant.

Nan mais c'est trop tard de chez trop tard, le site est énorme et déja en ligne

Simplement j'aimerais avoir les mots pour expliquer son fonctionnement (doc + embauches futures + culture perso), d'où mes questions ici.

Ouaip, chez moi c'est quasi ça, mais le language de template c'est php. Mais transformable très facilement.

Grâce à la séparation logique de la couche présentation.

D'ailleurs pareil pour l'accès aux données, j'ai juste à changer le contenu de mes classes BDD pour les faire passer en XML (ou juste changer de SGBD), grâce à la séparation de la couche données.

j'ai tout compris je crois

Enfin nan, c'est quoi la différence entre une Architecture trois tiers et une archi MVC ?

Le plus simple dans ce cas c'est probablement d'aller directement à la source: MVC at XEROX PARC (78-79), Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC) et GUI Architectures dans Patterns of Enterprise Application Architecture Dev de Fowler me semblent être de saines lectures

Que en pratique le model et la vue peuvent communiquer plus ou moins directement (un MVC est en triangle avec des communications possibles sur les axes Model <-> Controller, Controller <-> View et Model <-> View, alors qu'un three-tiers est pûrement linéaire, les seules communications autorisées étant data tier <-> middleware (ou logic tier) et middleware <-> client (ou presentation) tier, bypasser le middleware n'est pas permis)

En général, pour tout ce qui est informatique je conseille d'ailler voir la wikipedia en, et le cas ne déroge pas à la règle: Multitier architecture est simple et clair, et inclus une comparaison Three Tier - MVC

C'est marrant souvent les textes originaux sont bien plus fun et clairs que certains tutos sur le sujet   bon, à part que c'est de l'anglais.

Ca ça veut dire que les données peuvent être parfois préparées par le controleur, parfois par la vue ? Ca n'est pas sale ?

Moi je préfère le 3-tier j'ai choisi mon camp, pis tfaçon quelque part c'est une sorte de MVC

Sinon thanks you pour les ninfos.

Niveau pédagogie : http://www.symfony-project.org/boo [...] ony-s-Code

Nouvelle version de codeigniter : http://codeigniter.com/news/codeig [...] e_streets/

 
Intéressant à lire : http://pookey.co.uk/blog/index.php [...] -mail.html
 
Nos implémentations de la design pattern MVC sont-elles complètement nazes ?

C'est masculin ? Ou tu veux dire que MVC n'est pas vraiment un(e) design pattern... Plutôt une architecture qui va englober plusieurs patterns.
 
Bon sinon faut lancer le débat. Même si sa rant est assez mal argumentée, la vraie question est : est-il possible de faire du vrai MVC dans le domaine du web ?  
 
Quel est le vrai rôle de chaque composant ? Le Controller doit-il passer les données à la View, ou seulement le model ?

Probablement nazes, oui.
D'ailleurs perso dans l'optique où je fais des devs très spécifiques, je préfère faire ma popote approchant vaguement d'un MVC que du vrai MVC - ce qui em ferait perdre du temps plus qu'autre chose...

...en tout cas il a pas tort, le monsieur - perso ce que j'ai vu des gens utilisant symfony par exemple, c'est qu'il ne mettent quasiment plus rien dans le modèle - en-dehors de ce que génère l'ORM, et la vue accède directement aux membres des controleurs...je trouve pas ça super clean.

Ah ouais quand-même
 
Moi j'ai essayé de séparer le plus possibles les différents composants. Genre dans la plupart des cas, le Controller ne fait qu'instancier un Modèle et le refile à une View. La View ensuite sélectionne et prépare les données, qui seront filées à la template.
 
Alors c'est sûr, c'est super-séparé. Au final, la template n'a accès qu'aux données que la view lui a transmise. Y'a plus du tout de notion de Controller ou de Model dans notre template. Juste des données à afficher.
 
Après c'est parfois un peu lourdingue, faut à chaque fois créer une classe View qui souvent ne fait presque rien. Je me demande si je ne vais pas passer à un truc du style Passive View, où le controller peut s'interfacer directement à une template sans passer par une View
 
Finalement le problème vient du Controller : quel est son vrai rôle. Médiateur entre le modèle et la view ? Peut-il s'interfacer directement avec une template ? Quelle est alors la vraie distinction View/Template... Est-ce que la template du coup est considérée comme une View ?
 
Y'a donc déjà un problème de vocabulaire. Par quoi designe-t-on Model, View, Controller et Template. Si on définit déjà bien leur rôle, tout sera plus clair.
 
Messieurs, débattons

Perso j'ai squeezé la partie Vue. J'en utilisais une au départ, mais ça avait tellement peu d'intérêt que je balance tout aux templates à-partir du contrôleur, maintenant.
C'est mon moteur de templates, ma Vue, en gros.

Chuis content de lire l'article parce que je vais assez dans la même direction que le mec
 
* le contrôleur lit les inputs et les passent au modèle
* le contrôleur demande au modèle de traiter les données (charger, valider, sauver)
* le contrôleur file le modèle à la vue
* le contrôleur demande à la vue de produire une sortie (que ce soit un e-mail ou une page web)
 
Concernant la vue, il m'arrive de créer une seule classe pour produire plusieurs outputs parce que les données requises peuvent être les mêmes.
 
J'ai bon jusque là?

Ouais, ça ressemble alors à la Passive View de notre ami Fowler. Maintenant ce qui est assez relou, c'est qu'un paquet d'article sur MVC sont difficilement applicables au web, faudrait presque renommer tout ça en quelque chose plus en rapport.
 
Dans mon framework, parfois la View a un interêt minime. Soit elle refile à la template ce que le controller lui a donné, soit elle ne fait que récupérer un truc dans le model. Je pourrait la schunter sans problèmes.
 
Parfois aussi, elle a un rôle important, parce qu'elle prépare les données. Genre dans une boutique en ligne, affichage d'une liste de catégorie, on refile le model et la catégorie en cours à la view, et elle se charge de préparer un fil d'ariane, de sélectionner les sous-catégories et les sous-produits, etc. Elle peut aussi sélectionner les catégories soeurs suivant une option de configuration. C'est un peu moins le rôle du controller dans ce cas là, vu que les données sont préparées spécifiquement pour une view au format HTML.
 
On arrive à une autre question, est-ce qu'il est vraiment possible de faire un Controller totalement indépendant du résultat final. Genre dans l'article que j'ai posté, y'en a qui ont critiqué le fait qu'on puisse faire une redirection vers une autre page dans le Controller. Or, une redirection implique le format de destination.
 
Ou alors est-ce qu'on jette tout ça, et un Controller se verrait lié au format final ?

 
A mon avis le monsieur aurait un soucis dès le premier point.
Dans la théorie à moins que je me trompe l'input utilisateur est traité par la vue.
Ca change pas énormément, mais normalement le controleur doit instancier la vue, et lui demander de lui fournir l'input utilisateur.