Discussion :

[kaymak]

J'ai vu que certains ici pensent que pour coder en MCV, donc en couche, il était important voir capital d'utiliser un framework.
A ca, je reponds NON. C'est inutile lorsque on est trop leger en MVC.
Ca me parait logique. Pour bien utiliser un outil, il faut savoir pourquoi il a été fait, et surtout, en quoi il va nous simplifier la vie.

Ah enfin. Je suis très content de lire cette phrase.
Je me permettrait simplement de rajouter que perso, par rapport à la séparation des couches et l'exemple ci dessus de l'user.
Dans l'absolu c'est la meilleure implémentation (SgbdProvider -> UserProvider -> User), car c'est tout simplement le découpage le plus poussé, et qui répartit au mieux les rôles de chacun.
Dans la réalité, comme pour le MVC, c'est une archi lourde.
Et A moins d'un besoin très particulier, je me suffit de SgbdProvider -> User.
En effet je dois rarement passer d'un sgbdr à une source xml ou 1 sgbdO (php et sgbdo ? soyons fou..).

Bref, découper, c'est TOP, mais il faut que cela réponde au besoin, et au budget. Après si c'est géré automatiquement allons y gaiement !

Fin voila, mon petit avis en passant.

bye

[Philia]

Moi à la lecture de tout ceci je me pose des questions, ou plutôt je me les posais déjà, et je viens vous les exposer.

La principale question est la suivante: Est ce que le modèle objet est adapté au web et au code interprété ?

Plus j'avance et moins j'en suis convaincu, l'objet amène une souplesse d'utilisation certes mais à quel prix ?
A chaque requête vers le serveur toutes les classes vont être reinstanciées avec toute la lourdeur que cela suppose.

J'ai une expérience personnelle sur le sujet:

Après avoir réalisé un site PHP sans framework, entièrement à la mano, rien d'extraordinaire, mais qui fonctionne bien, j'ai eu le besoin de refaire le même type de site, juste avec une présentation différente.
Pour ce faire, j'ai fais un dump de la base, ai récupéré mes requêtes sql et ai recodé le site en utilisant le framework Zend.

Complètement emballé par le modèle MVC que je trouve tellement plus compréhensible et maintenable, j'ai levé le crayon arrivé sur les Zend_Form.
Le résultat m'a semblé lent, à tel point que je n'ai pas utilisé de Zend_Form.

Une fois le site terminé, j'ai déposé le tout chez le même hébergeur et j'ai enfin comparé.. horreur la version mvc est lente, beaucoup plus lente.

Je viens de me livrer à une expérience, j'ai pris une copie du site, de laquelle j'ai retiré toute trace de connexion à la base, j'ai retiré tout le code des vues et des actions, pour ne laisser que la mise en page et le mécanisme de navigation entre les vues.

J'ai ensuite réalisé la même chose en respectant l'aspect mvc, mais en bannissant l'objet et en privilégiant les fonctions et les "include".
Les deux versions possèdent le même aspect, fonctionnent avec le même type d'url (url/controller/action) possèdent des controlleurs et des vues et pourtant le temps d'affichage entre les deux à un rapport de 1 à 20, simplement sur le mécanisme de navigation (je n'ose meme pas imginer avec des zend_table, zend_Form et unZend_Registry bien gavé)


J'ai relevé le temps d'affichage des pages, en ne prenant pas en compte le premier affichage (le pire de loin pour le modèle objet)

entre 0,08 à 0,23 secondes pour la version objet
entre 0,003 et 0,013 secondes pour la version function !!!

Les temps sont relevés en début et en fin du fichier bootstrap des 2 modèles.

Ma conviction est que le modèle objet, s'il est beau sur le papier est une catastrophe au niveau des ressources.

Je vais donc garder le modèle mvc pour mon mon projet, et recoder l'ensemble à l'aide de belles functions, pensées par mes soins pour mes besoins et tacher de me souvenir que l'objet magique, s'il ne nous fait payer sa loudeur qu'une fois lors de son exécution dans un code compilé, nous la fait payer à chaque appel vers le serveur sur un code interprété.

[Fladnag]

L'objet est lourd, c'est pas nouveau ^^
C'est pourquoi il doit etre couplé a un mécanisme de cache lors de son implémentation. L'architecture Zend propose un systeme comme ca, de plus bas niveau, Smarty (basé sur les templates) propose quand a lui une solution purement logicielle en php qui est tres performante également.

Ainsi le temps d'execution sera toujours énorme... mais seulement sur la 1ere execution de la page (ou apres une mise a jour). La page étant ensuite trouvée dans le cache.

[mon_nom_est_personne]

c'est sur un objet c'est lourd. mais je pense que dans ce cas c'est surtout a cause des frameworks. Ce genre d'usine a gaze ca charge plus de chose que t'en a besoin (les windows de la prog). Du fait des projet sur lesquelles je taff (multi-lingue, multi-encodage et multi-plateforme) j'ai du ecrire mon propre framework car dans le meilleur des cas les frameworks n'arriver pas a suivre ce que je devais faire et dans le pire est le plus commun ils me cassaient tout.
Et il est rapide a la mort.
C'est toujours pareil, du sur-mesure marche toujours que de la production de serie. Une autre erreur a mon sens, avant tout, mettre en relief ses besoins et utiliser les outils adequates. Rien ne sais d'utilis un bazooka pour degommer une mouche.

[berceker united]

non mais il ne faut pas se leurrer. Le principe de framework en PHP n'est pas quelque chose de naturelle sauf si c'est sous forme de dll. Mais en PHP c'est une émulation de framework qui est faite. Il propose plus de chose que nous avons besoin mais il son but est de répondre au plus large.

Pour répondre à Philia : Utiliser un framework pour simple site est pour moi, inutile. Utiliser un framework pour faire un éditeur de site au seins d'une équipe de développeur; là c'est fort utile.

[Nicam]

Vraiment sympa ce debat

Je vais essayer de répondre à tout le monde.

L'archi que j'ai donné plus haut est presque un cas d'ecole.
C'est de la théorie.
En pratique, on est souvent ammené à factoriser, pour aller plus rapidement du point A au point B. Le truc, c'est que souvent, on est tenté de trop factoriser ...

Mais il faut remettre les choses dans leurs contexte. Une application en MVC pose des contraintes, et les ressources en font partie.
On ne code pas avec ce motif pour se faire plaisir. C'est réellement utile pour de gros projet, de grosses applications.

Pour la question de savoir si l'objet est adapté au web, je n'ai pas vraiment la réponse. Je vous conseille de lire le bouquin "Php 5 , best practice" qui donne des éléments de réponse.
D'apres l'auteur, seules les classes metier devraient être en objet.
La vue, voir le controleur ne devraint pas ou peu créer d'objet.
C'est d'ailleurs assez logique, puisqu'un ces objets sont les plus parlant.


Je pense que le meilleur moyen est d'y aller petit à petit.
Mais perso, je n'aime pas faire de l'objet avec Php ... (Il faut dire que j'ai passé plus de 4 ans à faire du C# et du Java depuis).

Quand aux differents framework PHP, je n'ai pas été emballé.
Zend me parait lourding au possible, Cake pareil ...
Tout le monde dit que Java est une horreur.
Mais en fait, lorsqu'on veut faire la même chose en PHP, c'est pire. Ca devient super lourd et super lent.
De plus, trouve que Php allie trop souvent l'objet à des Arrays ... Ca limite l'intérêt à mon gout.

Pour être honnête, si j'ai envi de faire de l'objet, je ne le ferais pas avec du PHP. Donc, ca revient à me dire que pour un gros projet, qui doit evoluer dnas le temps, par des équipes différentes ... Je m'en passerai.
Sauf si j'accouche d'un framework maison.

Je ne fais pas un troll à 2 roubles, je donne mon avis.
D'ailleurs, Java a aussi ses dérives. Les tonnes de framework, tous aussi poussifs les un que les autres ... A la limite, je suis tenté de bosser avec le minimum. Comme en PHP

PS : la question du cache est une fausse question à mon avis.
Tu peux cacher des classes, mais pas les objets (ou alors,l'intérêt est ultra minime, car il reviendrait à dire que dans 90 % des cas, ca serait pour pallier un défaut de conception).

Donc, pour en revenir au sujet.
Une petite séparation des couches est toujours appreciable, à voir en fonction de l'évolution du site, de la modularité.

D'ailleurs, pour répondre à une autre phrase.
Lorsqu'on fait une application, ou un bout d'application, on est souvent amené à concevoir dans des environnements communicants. Aujourd'hui, je stock mes users en base de données, mais si demain, je ne les stocks plus chez moi, mais que je les stocks sur un serveur distant, accessible via Webservice ?
Imaginons aussi que mes users soient repartis entre plusieurs bases/medium de stockages ? Ou coder les modifications ?
Pour le coup, si tu n'as pas découpler ton code, tu es bon pour te tapper un max de modife dans plusieurs classes )

[Fladnag]

Juste une petite réponses sur les caches.

Quand je parle de cache pour améliorer les perfs, je parle de cache de *très* bas niveau, c'est a dire cacher directement le source HTML généré par une précédente execution de PHP.
Bref, quand tu affiche une page depuis le cache, tu as juste l'instanciation d'UN seul objet eventuellement (l'objet qui gere le cache ^^) et pas plus.

Ca marchera tres bien pour les pages statiques ou qui evoluent peu. Je suis d'accord, ca ne marchera pas pour un panier virtuel ou l'affichage du cours de la bourse en temps réel ^^

Maintenant, si ton code est très bien structuré tu peux aussi gérer des caches partiels de pages, et ne "rafraichir" qu'une zone, en instanciant uniquement les objets necessaires pour récuperer les infos "manquantes".

[sekaijin]

Moi à la lecture de tout ceci je me pose des questions, ou plutôt je me les posais déjà, et je viens vous les exposer.

La principale question est la suivante: Est ce que le modèle objet est adapté au web et au code interprété ?

Plus j'avance et moins j'en suis convaincu, l'objet amène une souplesse d'utilisation certes mais à quel prix ?
A chaque requête vers le serveur toutes les classes vont être reinstanciées avec toute la lourdeur que cela suppose....

pourquoi toutes ?????
je ne fais que de l'objet et depuis très longtemps
je n'ai pas de pb de perfs et je ne charge que les classes dont j'ai besoin.

Par contre je vois trop souvent et ce n'est pas qu'en objet des façon de faire qui effectivement vont rendre le truc extrêmement lourd si on passe à l'objet.

pire certain Framework facilite cette façon de faire et la décrivent dans leur doc et vont même parfois jusqu'à faire l'impasse sur des approche beaucoup moins gourmandes en ressource.

lorsqu'on fait de l'objet pour accéder aux objets d'une table il faut deux classes et ceux même si on à 100000000 objets.

l'espace mémoire pour ces objet est exactement équivalente à un tableau associatif obtenu lorsqu'on n'utilise pas les objets + pour chacun 1 mots mémoire (un pointeur sur la classe) il faut donc charger 1024 objets pour consommer 1ko de plus que si on avait un tableau associatif.
les deux classes elles-mêmes ne prennent guère plus qu'une collection de fonctions.

ce n'est donc pas là qu'il faut chercher le problème.

en fait souvent lorsqu'on travaille à la main on vas faire une requête qui ne remonte que les champs dont on a besoin
alors que lorsqu'on utilise un mapping objet on est tenté (parfois il n'y même pas de doc pour faire autrement) de simplement demander à son objet provider de fournir les objets

le pire c'est lorsqu'il a des jointure je n'ai pas encore vu de framework qui décrive correctement une méthode pour faire du Mapping non pas sur une table mais sur une jointure

le plus souvent on accède à un objet et le framework fournis une methode pour récupérer les objets joins

pour 1000 facture de 1000 lignes on vas faire 1001 requêtes
Une vas connerie. ce n'est pas propre à la POO mais force est de constater que lorsqu'on veux faire autrement il n'y a pas beaucoup d'aide.

Faire un Mapping sur une jointure multiple demande de la programmation de haut vol dans la plus part des framework poo

Mais cela ne signifie pas qu'on ne peut pas le faire.

enfin il faut se poser la question du mapping lui même.
dans quel cas il est intéressant dans quel autre il ne l'est pas.

chaque fois que j'ai besoin de données je me demande ce que je veux en faire.

remonter toutes les factures d'un clients pour en faire un fichier excel ne demande pas de traitement "Metier" ni "DB" sur les données un tableau de donnée un resultset est largement suffisent

remonter une facture de la base pour la valider, calculer sa tva sa remise et l'enregistrer demande des traitement metier qu'il sera bien pratique d'avoir directement sous la main. un Maping est alors très pratique et peu consommateur

Je dirais donc que la POO n'est pas en elle même un facteur de lourdeur.

mais qu'il faut savoir ce que l'on veut
la POO apporte des choses et cela à un cout. il faut donc se poser la question pour chaque projet pour savoir si le projet en vaut le cout.


ne pas choisir la POO et par la suite surcharger son code pour lui faire faire ce qu'on aurait eu avec la POO n'est pas mieux
que développer une Usine à gaz pour faire "hello word"

A+JYT

[Philia]

Pour la question de savoir si l'objet est adapté au web, je n'ai pas vraiment la réponse. Je vous conseille de lire le bouquin "Php 5 , best practice" qui donne des éléments de réponse.
D'apres l'auteur, seules les classes mour le controller une etier devraient être en objet.
La vue, voir le controleur ne devraint pas ou peu créer d'objet.
C'est d'ailleurs assez logique, puisqu'un ces objets sont les plus parlant.

Par "les plus parlant" tu veux dire les plus utilisés ?
Si oui, j'adhère completement à cette vision, mais si je regarde ZF, j'ai une classe pour le controller, une pour la vue, une pour le model, les vues partielles, sans parler des classes pour lire le fichier ini, la registry ou accéder à la db.

Ce n'est pas que je sois contre la poo, c'est juste que je pense qu'elle est utlisée à outrance ou disons à mauvais escient.

Bien sur on peut compenser cette lourdeur en mettant en place un mécanisme de cache, mais comme son nom l'indique il cache la lourdeur.. il ne rend pas plus léger, c'est une illusion.

Quel est le pourcentage de sites en mutualisés par rapport à ceux sur un serveur dédié ?
Et meme en entreprise, l'heure est à la virtualisation de façon a diminuer les couts d'hergement des applications, alors justifier une surconsommation de ressources me semble à contre courant de ses tendances à l'économie

[sekaijin]

en entreprise il est parfaitement possible de mutualiser le framework lui même. donc la consommation de l'espace disque n'est pas vraiment un pb.

je le répète ce n'est pas en terme de POO ou pas POO qu'il faut penser mais en fonction des besoins de l'application.

utiliser ZF pour faire hello-word c'est débile. faire une appli conséquente peut très bien s'envisager sans framework

faire la même application dans un contexte où l'on produit des dizaine d'applications qui doivent toutes évoluer et capitaliser ses développement demande plus que de produire un code qui marche et là la POO est plutôt une bonne approche.

une foit qu'on est dans cette situation produire une petite application en POO n'est pas si aberrant car sans coût de dev on bénéficie de tourte l'expérience antérieure.

On peut noter qu'il est parfaitement possible de faire sans POO

pour ceux qui on ouvert GTK+GNOME on a là un exemple qui montre bien qu'on peut très bien se passer de POO sauf qu'en y regardant de près GTK+GNOME est un framework orienté objet développé avec un langage procédural. mais il y a d'autre exemple d'application ou d'entreprise qui n'utilise pas la POO et qui font quand même de la capitalisation de l'évolutivité car c'est plus les méthodes de travail que le langage qui font qu'on obtient cela.

un projet comme ce gestionnaire de forum est un exemple dans le quel la réutilisation des composant développés n'est pas un but aussi important que l'application elle-même à quoi servirait-il d'avoir un composant de gestion de topic hors du forum ??? dans ce projet l'utilisation de POO doit être posée.

dans une application de gestion commerciale qui devra être décliné en autant de version que de modèle d'entreprise, une gestion comptable en autant de version que de pays où elle sera utilisé etc. dans ces cas là on a tout intérêt à bien définir ses composant les rendre facile à dériver et inter opérable. là la POO est d'un grand secours (même si on peu s'en passer) elle apporte beaucoup de facilité.

enfin j'ai vu passer entre mes main beaucoup de dev en php je crois qu'on peut les classer ainsi
les scripts: code linéaire qui fait tout d'un bout à l'autre avec parfois des includes pour se faciliter la vie.
les fonctionnels: ensemble de fonctions et procédures (parfois de classes) réalisant des processus complets. (on inclus pas un script on appelle une fonction)
les multicouches: séparation structurelles des diverse étape de traitement menant à la réalisation du processus.

je dois dire que de façon générale j'ai trouvé l'approche par script la plus part du temps chez les autodidactes et les débutant.

l'approche fonctionnelle est elle utilisé par des pro du dev ou du moins des personnes ayant reçu une formation à la programmation.

l'approche multicouche et le plus souvent issu de développeur ayant eu à produire et reproduire des application et qui on fini par en venir à cette séparation pour se simplifier le travail. ou alors de personnes ayant été sensibilisé ou formé à cette approche. je ne connais pas de developpeur débutant autodidacte qui ait naturellement d'entrée de jeux utilisé cette approche.

je dois dire que j'ai vu dans ce dernier cas des développement MVC parfaitement conforme à la théorie qui n'utilisaient que des script (pas de fonction pas d'objet) j'ai vu aussi des dev utilisant nombre de design pattern sans utiliser la POO

cela ne fait que confirmer que tout cela n'est qu'une question de méthode et non de langage.

enfin coté perf je n'ai jamais eu à souffrir des perf de dev en POO mais bon mes application dépassent toutes plusieurs s dizaine de millier de ligne de code. dans une telle densité la différence s'estompe.

A+JYT

[Nicam]

+1

(et encore désolé pour mes innombrables fautes et coquilles )

[zyongh]

Les gens qui disent que PHP est simple ont dû se contenter de projets simples. J'ai déjà reprise des projets PHP en cours où le code était très bien fait et très bien indenté et après tout, assez logique... mais d'une longueur interminable par un manque de connaissance de ce magnifique langage qu'est le PHP. Je me souviens particulièrement d'une application réseaux où j'ai réduit de plus de moitié la quantité de lignes de codes en utilisant simplement cURL et quelques autres extensions.

Donc, le langage PHP a la réputation d'être facile car (probablement) beaucoup d'utilisateurs utilisent les fonctions les plus connues. Allez étudier des extensions comme runkit, curl ou crack et vous verrez que PHP peut fournir des extensions pas si simple que cela à comprendre et surtout à appliquer. Rien n'est impossible avec PHP tellement ce langage est complet et complexe.

J'ai travaillé récemment avec quelqu'un de très pro (même si sa façon de programmer est peu orthodoxe) et il m'a dit une phrase que j'ai gardé comme devise:
Si une fonctionnalité demande plus de 30 lignes de codes, c'est que je n'ai pas choisis la meilleure solution.

à méditer...

[codefalse]

Pour continuer cette très intéressante discussion, j'aimerai apporter un point à traiter.

De plus en plus de nos jours, dès que l'on parle de site web, on à tendance à faire référence à des applications utilisant un minimum de javascript (ajax, ajax ou ajax, au choix). Ce mode Web2 me pousse à une réflexion, j'aimerai votre avis là-dessus.

Actuellement, on reste "coincé" sur un modèle MVC. Okay, on a tous compris ce que c'est, c'est joli, ca rends le code plus propre car chaque tâche ne fait que ce qu'elle doit faire, etc.

Mais en mélangeant ces deux principes (mvc et web2), pourquoi ne pas considérer que la partie Vue du pattern MVC ne soit concrètement que la page html avec son javascript qui va bien, la partie controller serait géré par le php et la partie model par un Orm.

La partie vue n'aurait qu'à récuperer les données du M/C par requête AJAX ? De plus en plus de framework javascript implémentent cette solution (JQuery.chain par exemple).

Je sais que certains sont contre le tout ajax, et je le comprends, mais utiliser un moteur de template, ca alourdit aussi pas mal la bestiole. Ou est le juste milieu ??

En fait pour ma part je recherche actuellement un moyen de développer rapidement et simplement divers sites webs et ce de façon clair, propre, rapide et pérenne... c'est pas encore gagné !

Si l'on compare les deux modes, on à le traitement par template d'un coté :
_ traitement coté serveur
_ impose une couche supplémentaire lors de l'éxécution
_ peut-être amélioré en performance par la suite avec la mise en place d'un système de cache

et l'ajax based de l'autre côté :
_ Correspondrait à la partie Vue du pattern MVC
_ Impose DEUX requêtes au serveur, une pour afficher le "template", l'autre pour récuperer les valeurs

... vos avis ?

[sekaijin]

Ben non la partie html/js de l'appli n'est pas la partie VUE de MVC
C'est un peu plu compliqué.

en fait avec AJAX on change de paradigme on pas à une architecture client serveur. on a en fait deux "appli" qui dialoguent entre elles

la partie client est en HTML/JS et la partie serveur se présente comme une web App sans IHM

dans la partie Serveur on reste proche des Web App sauf que la partie Vue n'est plus en Html mais en Json ou XML. la vue dans le modèle MVC est là pour présenter les données la conversion des données de php vers Json ou XML et leur envois au client est bien la présentation de ces données.

coté client maintenant la plus par du temps les applications Ajax sont écrite en javascript (avec souvent du html) on utilise très souvent des librairies type DOJO ExtJS etc... (on appelle ça framwork mais ce ne sont la plus part du temps que des librairie) le modèle de programmation le plus fréquent est celui qu'on trouve en VB c'est à dire attacher du traitement à des partie d'interface. le code fonctionnel est le plus souvent éparpillé dans le code de l'IHM. mais rien n'empêche de travailler différemment. et là aussi de travailler en MVC. d'un coté le métier qui est un ensemble d'objet ou de fonction qui dialogue avec la ressource (le serveur) de l'autre l'IHM qui présente les données et interagit avec l'utilisateur. et entre les deux un chef d'orchestre qui organise la dynamique de l'application et assure la liaison avec le métier.

A+JYT

[mon_nom_est_personne]

J'ai travaillé récemment avec quelqu'un de très pro (même si sa façon de programmer est peu orthodoxe) et il m'a dit une phrase que j'ai gardé comme devise:
Si une fonctionnalité demande plus de 30 lignes de codes, c'est que je n'ai pas choisis la meilleure solution.

à méditer...

hehehe sympas j'ai l'habitude de tenir le meme discours sauf que je suis strict, je compte sur 100 lignes.

Et pour revenir sur cette histoire de javascript, je pense que c'est pas la peine de debattre dessus. (x)html/js/css c'est du passer, c'est bien pour l'alimentaire mais d'ici quelques annees on ne travaillera plus que sur des RI comme flash, svg, silverlight ou je ne sais quoi encore.
quel bonneur ca va etre, mes designer vont faire leur design avec leurs jolies logiciels de design et apres je vais pouvoir faire mumuse et je suis sur que personne vidra foutre le bronx dans mon appli !

[codefalse]

Ben non la partie html/js de l'appli n'est pas la partie VUE de MVC
C'est un peu plu compliqué.

en fait avec AJAX on change de paradigme on pas à une architecture client serveur. on a en fait deux "appli" qui dialoguent entre elles

la partie client est en HTML/JS et la partie serveur se présente comme une web App sans IHM

dans la partie Serveur on reste proche des Web App sauf que la partie Vue n'est plus en Html mais en Json ou XML. la vue dans le modèle MVC est là pour présenter les données la conversion des données de php vers Json ou XML et leur envois au client est bien la présentation de ces données.

coté client maintenant la plus par du temps les applications Ajax sont écrite en javascript (avec souvent du html) on utilise très souvent des librairies type DOJO ExtJS etc... (on appelle ça framwork mais ce ne sont la plus part du temps que des librairie) le modèle de programmation le plus fréquent est celui qu'on trouve en VB c'est à dire attacher du traitement à des partie d'interface. le code fonctionnel est le plus souvent éparpillé dans le code de l'IHM. mais rien n'empêche de travailler différemment. et là aussi de travailler en MVC. d'un coté le métier qui est un ensemble d'objet ou de fonction qui dialogue avec la ressource (le serveur) de l'autre l'IHM qui présente les données et interagit avec l'utilisateur. et entre les deux un chef d'orchestre qui organise la dynamique de l'application et assure la liaison avec le métier.

A+JYT

Donc en gros on se retrouve avec une web app qui possède deux mvc :

Coté serveur :
_ Modele : Mysql
_ Controlleur : Php
_ Vue : Json/Xml/quelque chose dans le même style

Puis Côté client :
_ Modele : Json/Xml ; La partie "Vue" du MVC coté serveur
_ Vue : Html/Css
_ Controlleur : Javascript

[berceker united]

hehehe sympas j'ai l'habitude de tenir le meme discours sauf que je suis strict, je compte sur 100 lignes.

Et pour revenir sur cette histoire de javascript, je pense que c'est pas la peine de debattre dessus. (x)html/js/css c'est du passer, c'est bien pour l'alimentaire mais d'ici quelques annees on ne travaillera plus que sur des RI comme flash, svg, silverlight ou je ne sais quoi encore.
quel bonneur ca va etre, mes designer vont faire leur design avec leurs jolies logiciels de design et apres je vais pouvoir faire mumuse et je suis sur que personne vidra foutre le bronx dans mon appli !

J'y crois très peut à la deuxième partie. Si nous regardons bien, le flash, l'applet, shockwave n'a pas réellement percé le marché du web. A titre personnel, j'en vois de moins en moins des sites entièrement fait en flash sauf dans des domaines très spécifiques.
l'Ajax, après une certaine euphorie, tant stagné voir reculer. Le bon vieux couple HTML/Javascript ont encore de bon jour devant lui. Ceci, principalement lié au question de coût. Généralement, le développeur coté serveur et le même coté client. Utiliser ces technologie oblige à plus de personnel. Ceci, juste pour des questions esthétique.

[codefalse]

Je suis aussi plutôt d'accord sur le fait que flash et tous ses amis n'ont pas d'aussi beau jours que le javascript.

On trouve beaucoup de flash chez les designers, les sites de films, mais en général, les webmasters préferent éviter, tout simplement pour l'attente de chargement que provoque flash, plus imposant que javascript, et la restriction au niveau de qui à flash ou qui ne l'a pas. Javascript est en standard dans un navigateur récent, flash pas.

Alors pour développer une application sur internet (au sens strict du terme, cad un logiciel), flash est peut-être adapté, mais c'est tout ! :p

Je verrai plutôt un avenir avec un nouvelle techno qui va tuer les ours en pluche, et tout le monde oubliera flash et js. et ainsi va la vie

[Pascal22]

... mais rien n'empêche de travailler différemment. et là aussi de travailler en MVC. ...

S'il est effectivement évident que c'est une bonne pratique d'un point de vue applicatif, en est-ce réellement une d'un point de vue site web (referencement par ex. ) ?
Car si je ne me trompe, plus d'url rewriting (une url unique pour l'acces au serveur)

[Nicam]

Pour moi, Php reste de mise au niveau client.
Pour la simple et bonne raison que niveau securité, coder un moteur de template en JS, c'est pas extra.

De plus, le contrôle des entrées utilisateurs (validation des champs de formulaire, des url, etc ... ) incombe toujours, d'apres moi, à la couche présentation.

Pour ce qui est de javascript, je ne suis pas trop d'accord avec vous.
Javascript est encore tributaire des differences entre navigateurs, que ce soit au niveau de la syntaxe que de l'interpretation de DOM suivant les browser.

En plus, le JS à façon, 100% mano, c'est hors de prix.
Rien de tel pour exploser des budgets.

Je ne connais pas d'IDE puissant pour faire du JS, je ne connais qu'un debuggeur (venkman) qui plante souvent sur FF.

Non, JS, c'est sympa, mais c'est un peu arriver à pied par la chine.

D'autant plus que les techno comme flex/flash ouvre des perspectives très interressante (Air y compris).
Je pense qu'on va plutot s'orienter vers des applications communicantes à gogo, plutot que rester sur le modele de page web (ce n'est que mon avis).

A mon avis, les widgets et compagnie vont exploser, tant ils ont un potentiel énorme au niveau comm, marketing et commercial.

Enfin, si flash n'est pas un standard, je veux bien me faire fouetter tout nu ^^
Avec un taux de pénétration qui frôle le 99%, une évolution perpétuelle, et des actions sécuritaires fréquentes, on peut difficilement passer à coté.
Silverlight et Javafx vont avoir beaucoup de mal à lui passer dessus.