Ajax et DOM - Page 2

Spipu (./29) :
certaines applications métiers mettent plus d'un 1/10 de seconde à être généré... exemple : le CMS typo3... 500ms par page, à 1000 utilisateurs... il vaut mieux ne regenerer que ce dont tu as besoin !

Ah c'est sûr, mais là je parlais d'application à l'échelle de ce que je voudrais faire, donc un tout petit truc.

ben par forcement, quand ce selec est utilisé des centaires de fois dans l'application, c'est bien pratique d'avoir un truc qui te les génère automatiquement...

C'est bien pratique, je suis d'accord, et c'est aussi probablement ce qu'il y a de plus efficace, mais c'est tellement orienté vers une technologie que c'est complètement inutilisable sans Ajax, par exemple. C'est pour ça que je trouve ce type de conception mauvais par construction.

d'experience, ca se fait très bien

Avec du code partout dans tes templates alors ? Parcequ'avec un template qui peut modifier complètement la disposition et l'apparence des éléments de ta page, je vois difficilement comment tu peux isoler les blocs manquants et garder quand même toute la liberté dans ton template (le code prévu pour me remplir un <select>, si mon template affiche ça sous la forme de boutons radio, il est inadapté).

Zephyr (./31) :
C'est bien pratique, je suis d'accord, et c'est aussi probablement ce qu'il y a de plus efficace, mais c'est tellement orienté vers une technologie que c'est complètement inutilisable sans Ajax, par exemple. C'est pour ça que je trouve ce type de conception mauvais par construction.

Ca depend des donnée en meme temps. Si c'est du XML que tu envois (XHTML ou autre format XML) ça peut tres bien etre exploité par une autre application (genre native en C#/C/C++ & co)

C'est ce qu'on apelle vulgairement les "Web Services"

Mais ça dépend des données répondues

Zephyr (./31) :
(le code prévu pour me remplir un , si mon template affiche ça sous la forme de boutons radio, il est inadapté)

heu, peut-etre qu'on a une vue différente, mais les inputs, select, et autre champs de formulaire, c'est pas du template ca, c du contenu, non ? du moins je le vois comme ca... un radio n'accepte qu'une seul valeur, le select non...

Zephyr (./31) :
Avec du code partout dans tes templates alors ?

non, pas forcement... tu peux très bien préparer complètement tes traitements dans un premier temps, préparer tes variables, puis charger des fichiers .tpl.html et remplacer des "balises" prédéfinits par le contenu

Godzil > Hmm les webservices y'a justement tout un tas de formalismes derrières qui vont s'assurer que la communication est possible (SOAP, WSDL & friends), mais dans l'idée je reste d'accord qu'avec du XML il y aurait moins de problème. Justement là, ce qui circule contient à la fois des données et de la présentation, le tout mélangé, et c'est ce qui pose problème :/

Spipu (./33) :
heu, peut-etre qu'on a une vue différente, mais les inputs, select, et autre champs de formulaire, c'est pas du template ca, c du contenu, non ? du moins je le vois comme ca... un radio n'accepte qu'une seul valeur, le select non...

Pour moi "demander à l'utilisateur une valeur", c'est du code. En revanche, "afficher un <input type=text>", c'est de la présentation et ça n'a sa place que dans un template (le code n'a aucune raison d'imposer la façon dont la donnée doit être saisie, je peux vouloir passer par un textarea, ou même complètement autre chose qu'un formulaire, pourquoi pas).

non, pas forcement... tu peux très bien préparer complètement tes traitements dans un premier temps, préparer tes variables, puis charger des fichiers .tpl.html et remplacer des "balises" prédéfinits par le contenu

Heu... Tu aurais un exemple (court) de ce que tu appelles template ? Parceque j'ai l'impression qu'on ne place pas la limite contenu/présentation au même endroit, et c'est peut-être pour ça que tu ne vois pas où je distingue un problème.

(ça passera peut-être pour une évidence, mais je tiens à le préciser : pour moi une feuille de style CSS ne prend en charge qu'une très petite partie de ce que j'appelle "présentation", et est loin de constituer un template à elle seule)

Bon, après un petit moment de réflexion, vos commentaires me semblent très pertinents et je suis du coup complètement perdu

Loin du problème purement technique du premier post, je me demande comment organiser un site de façon à intégrer ajax, mais sans refaire toute l'architecture du site pour l'y intégrer, et en séparant complètement le code "métier" de la partie présentation. Petite précision, ce que j'ai tendance à appeler présentation, c'est ce que fait par exemple la bibliothèque Smarty : elle gère l'affichage des pages et peut même interpréter du code basique (boucles, conditions & co), mais c'est du code d'affichage (par opposition au code métier, qui lui manipule les données).

Pour l'instant, voilà tout ce que je sais :
[ul][li]Il me semble qu'Ajax est utilisé actuellement de deux façons différentes, bien qu'à mon avis la majorité des gens n'aient pas cherché à faire la différence : pour récupérer uniquement des données, issues par exemple d'un fichier XML (à la Google Suggest, même si il doit y avoir une légère partie présentation également vu que je ne sais pas comment s'en abstraire complètement), ou bien pour récupérer carrément tout un bloc d'une page web (comme les widgets de Netvibes, ou de Google ou autre)[/li][li]Comme expliqué plus haut, je ne vois pas comment intégrer proprement un concept Ajax sans être obligé d'adapter la conception. Si je vais chercher des données brutes dans un XML, je les récupère coté client et je ne peux donc plus passer par la couche de présentation (coté serveur). La solution utilisée actuellement consiste à présenter les données avant de les envoyer au client, mais c'est ça qui impose à un site web d'être capable de s'afficher "par blocs". Je trouve que c'est une contrainte énorme et qui n'a pas lieu d'être.[/li][li]Je ne vois pas de solution à ce problème pour l'instant, mais il en existe forcément une ^^[/li][/ul]
Si l'un de vous a des suggestions, je suis preneur

Je vois pas ton probleme la. Si tu veux passer a Ajax, biensur que ca aura une consequence sur le design applicatif.
Ajax, c'est pas comme faire un site normal et on se dit "tiens j'vais utiliser Ajax, c'est cool" et paf! tout marche...
D'ailleurs heureusement sinon, tu risques d'avoir des belles surcharges (cf le nombre de requetes avec un site Ajax et un site sans).
Idealement, meme si c'est chiant, tu te fais des petits scripts/single functions qui vont te faire une action qui te sera utile directement dans ton interface (et pour communiquer, c'est pas mal d'utiliser JSON, c'est relativement leger comparer a XML)

ps: c'est p-e un hors sujet complet, j'ai pas lu avant ton dernier post

Bon, en version simple : je suis pas d'accord ^^

Mais j'ai déjà expliqué avant pourquoi donc flemme de réécrire. C'est juste qu'a priori, je ne vois pas de raison pour laquelle Ajax devrait avoir une conséquence sur le design applicatif (et que la solution des "petits scripts" me semble très mauvaise). D'ailleurs je viens d'avoir un exemple à l'instant, merci yAro : en C#/Ajax.Net, modifier un élément d'une page pour le faire fonctionner avec Ajax prend à peu près 2 lignes et ne remet absolument pas en cause le reste. Je ne sais pas comment ça fonctionne derrière, mais ça prouve simplement que c'est possible ^^

C'est pas impossible, c'est juste que ca surcharge pour rien je trouve...

Bah ça dépend, pour moi une solution générique ne pourra forcément pas être aussi efficace que le bricolage qui consiste à plier sa conception aux contraintes d'Ajax (c'est une évidence), mais elle restera infiniment meilleure à mes yeux ^^

normalement si tu as bien concu coté serveur justement, tu peux appeler des fonctions qui pondent uniquement les infos dont tu as besoin pour un truc spécifique, genre remplir un select, donner une liste d'utilisateur, etc.

apres, tu peux faire une page interface.php qui include et appelle ces fonctions en fonction d'un paramètre action=....
non?

edit: au fait, si cest pour transmettre des données, vaut mieux envoyer du JSON comme le propose neuroo.

onur (./41) :
normalement si tu as bien concu coté serveur justement, tu peux appeler des fonctions qui pondent uniquement les infos dont tu as besoin pour un truc spécifique, genre remplir un select, donner une liste d'utilisateur, etc.

apres, tu peux faire une page interface.php qui include et appelle ces fonctions en fonction d'un paramètre action=....non?

En théorie ça semble vrai, mais en pratique le moindre élément de chaque page peut être "ajaxifié". Ça veut dire qu'il faudrait une page pour chaque petit élément, et une grosse page "full.php" qui ne s'occuperait que de les réunir toutes ?

Je crois que le détail qui me gène le plus dans tout ça, c'est que j'essaie de trouver une justification autre qu'ajax pour structurer un site de cette manière, et je trouve pas... pourtant si c'est bien ça la solution, alors elle a forcément d'autres avantages.

onur (./41) :
edit: au fait, si cest pour transmettre des données, vaut mieux envoyer du JSON comme le propose neuroo.

Je viens de jeter un oeil à Wikipedia, mais je suis pas sûr d'avoir compris l'intérêt de JSON ?

Zephyr (./42) :
mais je suis pas sûr d'avoir compris l'intérêt de JSON ?

principalement : c'est (bien) moins lourd à manipuler, côté JS, que du XML
(vu que c'est déjà du JS valide)

Zephyr (./42) :
et une grosse page "full.php" qui ne s'occuperait que de les réunir toutes ?

non tu fais des includes dynamiques des fichiers avec requiere_once ou un truc du genre, c'est l'avantage d'etre interpreté et tu regroupes tes fonctions similaires par fichier. Par exemple, les fonctions concernant un utilisateur, tu les fous dans utilisateur_requests.php etc..

Zephyr (./42) :
Je viens de jeter un oeil à Wikipedia, mais je suis pas sûr d'avoir compris l'intérêt de JSON ?

En fait, tout est dictionnaire en javascript. Tout est une collection de clé, objet. Quand tu écris:

var a = { a: "a",
b: 784,
c: function() { .... }
};

les clés sont a,b et c. Tu aurais pu aussi écrire "a":"a","b":784,"c":function.. mais cest moins lisible.
Ensuite tu accèdes par a.a à "a", a.b à un entier et même par a.c à une fonction que tu as crée en plein milieu comme ca! L'intêret c'est que par le serveur tu envois un text/plain qui contient le json (à partir de "{a:"a"... ) et coté serveur tu fais a= eval(responseText); et ca revient à ce que j'ai écris plus haut, et c'est tout en natif.

et c'est exactement comme cela qu'on se retrouve avec un web avec des putains de vulnerabilities partout

a partir du moment où il y a un eval, faut prendre les précautions coté serveur... Dans un cas comme dans l'autre

oué c'est pour ça que l'avantage me semble pas si évident que ça en fait (sachant que parser un XML en js, ça prend une ligne :/), et sur Wikipedia les avantages ne sont pas flagrants non plus

Bon je reviens sur ta solution onur : en gros tu regroupes par thème les différentes parties d'affichage, admettons. En revanche pour les "includes dynamiques", je vois pas trop : à un moment où à un autre il faudra indiquer la structure complète de la page (sous la forme d'une liste de modules à afficher, a priori).

Je me retrouve donc avec deux éléments : d'un coté des scripts capables d'afficher toutes les informations sur les données dont elles ont la responsabilité, d'un autre des schémas qui contiennent des "listes d'affichages" : quelles scripts appeler pour arriver à une page complète. Il me semble qu'il y a encore deux problèmes : le découpage de l'affichage ne me semble pas naturel (il ne répond à aucun besoin autre que les contraintes liées à ajax, on tourne en rond), et la granularité de ce qu'il est possible de faire en ajax est limitée par celle des scripts d'affichage (un truc en ajax ne pourra pas être "plus fin" que ce qu'un script pourra afficher).

Exemple pour le dernier point : mon script users.php peut afficher une liste d'utilisateurs, par exemple. Mais je voudrais pouvoir éditer inline le nom d'un seul utilisateur de la liste, et donc ne rafraichir que celui-ci (admettons qu'une communication avec le serveur soit indispensable ici, même si ce n'est pas le cas). Problème : je ne peux pas afficher un seul utilisateur à la fois. Je pourrais rendre mon script plus fin et lui faire afficher les utilisateurs un par un, mais alors je perds des choses qui m'auraient été possibles en manipulant la liste entière (afficher les utilisateurs avec un dégradé de couleur par exemple. si je manipule un seul utilisateur à la fois, je perds la notion de liste et donc d'emplacement, et donc je ne peux plus faire mon dégradé en fonction de l'emplacement de l'utilisateur). Quelle est la bonne granularité du coup ? Chaque fois qu'on sépare, on perd des possibilités :/

Arg

Tu vas t'en sortir

pour les fichiers à inclure, effectivement cest une suite else if, un gros switch, un tableau tout ce que tu veux.. qui prend en parametre.. bah le parametre, qui inclut et qui appelle les fonctions en fonction de ca. En gros, full.php comme tu appelles, il sait ce qu'il faut faire mais il délegue le boulot aux autres. D'où la proposition "interface.php", interface au sens interface du coté serveur.

En fait, je vois pas en quoi le découpage est un problème en soi? Si tu as besoin de tous les éléments, bah tu fais une fonction qui appelle une par une toutes tes "petites" fonctions. Ca permet de (et ça te force à) structurer chaque info envoyable.

et enfin, la granularité c'est un choix difficile et tu as l'air de pas vouloir faire ce choix mais en gros, tu peux renvoyer une liste d'utilisateur et n'envoyer les détails que quand c'est nécessaire... mais trop d'ajax tue l'ajax, si les détails ne sont pas énormes et/ou la liste n'est pas grosse tu peux tout envoyer, après c'est au cas par cas.

pour l'histoire du rafraichissement, j'ai pas bien compris. éditer inline, tu veux dire par l'utilisateur? ou toi dans le javascript avant de l'afficher? En tout cas, pour le coup, les histoires de MVC conviennent pas mal et deviennent vite nécessaires si tu veux faire une grosse appli sérieuse en ajax. Tu fais communiquer ton objet model js avec le serveur pour les mises à jour etc. et tu update la vue etc.. Mais je suis pas sur d'avoir compris la problématique de ce coté là.

Bah en gros c'est pas la mise en place de ton idée qui me pose problème, je pense avoir à peu près saisi où tu voulais en venir, mais il reste encore quelques détails qui me gênent pas mal malgré tout ^^ (mais auxquels je n'ai pas trouvé de solution)

Tout se résume à la granularité en fait. À granularité nulle, le site est fait d'un seul bloc, comme dans la solution que je décrivais au début de ce topic. Mais quand on commence à découper, je ne vois aucune métrique permettant de dire "là c'est bon, on s'arrête", et pire : comme je l'ai expliqué dans le ./46, on perd des fonctionnalités au fur et à mesure qu'on en gagne. Comme j'aime toujours avoir le beurre et l'argent du beurre, c'est dommage ^^

C'est ici que vient se placer mon histoire d'edit inline (par le mec qui surfe sur le site), qui aurait besoin de pouvoir afficher les utilisateurs un à un, donc une granularité très fine. Mais cette granularité est tellement fine qu'elle en deviendrait handicapante à mon avis :/ (plein de toutes petites fonctions communicant difficilement entre elles, et chacune responsable d'une partie infime de la page).

Pour le MVC, il me semble que ce n'est pas applicable : le "V" de ton MVC se situe sur le serveur, et quand tu récupères tes données en Ajax tu es déjà coté client. Impossible de revenir en arrière, d'où tous ces problèmes.

non pour MVC ce que je proposais c'est tout coté client. et le "C" permet également la comm' entre le "M" client avec le "M" serveur avec les requetes ajax.

pour la granularité, j'ai l'impression qu'il va falloir faire des concession d'un coté ou de l'autre mais que tu oses pas

oh c'est pas tellement une question d'oser, c'est que du coup la solution me parait pas optimale

v laisser ça décanter quelques jours avant de tenter quoi que ce soit, peut-être que j'aurai la révélation d'ici là :/

suis à la bourre... pas regardé internet hier soir

Zephyr (./35) :
(le code n'a aucune raison d'imposer la façon dont la donnée doit être saisie, je peux vouloir passer par un textarea, ou même complètement autre chose qu'un formulaire, pourquoi pas).

ben si... un input text, un radio, un checkbox, un select, un textarea, un file, ca ne se gère pas du tout de la meme maniere pour le traitement ! t'auras parfois des [] en plus, besoin de traitements pour empecher les balises html, relié à un tableau pour associé une clef à une valeur, ..., ... tu ne peux pas dissocier un champ d'un formulaire à la manière dont il est traité derriere. Enfin, c'est mon avis perso ! ou sinon, faut faire un code hyper générique derriere, qui du coup en devient difficile à suivre pour quelqu'un qui arrive apres toi, car pleins de choses seront inutiles

Zephyr (./35) :
Heu... Tu aurais un exemple (court) de ce que tu appelles template ? Parceque j'ai l'impression qu'on ne place pas la limite contenu/présentation au même endroit, et c'est peut-être pour ça que tu ne vois pas où je distingue un problème.

je crois que ce que toi t'appeles template, moi j'appele ca framework...

Zephyr (./36) :
Petite précision, ce que j'ai tendance à appeler présentation, c'est ce que fait par exemple la bibliothèque Smarty

la preuve, pour moi, smarty est un framework donc forcement, on peut pas se comprendre...

par contre, je viens de relire un peu tout, et je crois voire d'où vient le pb :

- tu parles de "mettre" de l'ajax dans un site internet qui n'en avait pas au départ, et qui n'en avait pas besoin, juste pour ne recharger que certaines parties. Dans ce cas, le site ne necessite pas l'utilisation d'ajax, c'est juste un confort de rapidité, et dans ce cas là en effet, il n'est pas (forcement) necessaire de refaire tout derriere, de tout eclater, mais juste d'envoyer tout le contenu, et de ne prendre côté client que la partie à mettre à jour.

- je parle d'applications web ou l'ajax est obligatoire au fonctionnement, et où tu es obligé d'eclater chaque élément et de n'envoyer que certains car les autres ne pourraient pas l'être de toute facon, car ils ont été générés élément par élément et que tu n'as pas les éléments pour les reconstruire (ex : mon client FTP en PHP que je t'avais montré il me semble, qui construit l'arborescence au fur et à mesure ou tu la développes)

c'est deux utilisations completement différentes d'ajax, l'une pouvant être rajouté apres la conception/le développement du site en bidouillant un peu, alors que l'autre necessite une conception/un developpement spécifique dès le départ.

et je rajouterais que je n'aime pas la premiere utilisation, car n'est "mettre de l'ajax" pour "mettre de l'ajax", ce que fait beaucoup de monde, et qui ne devrait pas être fait...

Zephyr (./36) :
pour récupérer carrément tout un bloc d'une page web (comme les widgets de Netvibes, ou de Google ou autre)

lol, les widgets sont juste des pages tout ce qui a de plus classic, affichés dans des iframes, avec un tout petit xml pour definir la taille de cette iframe et les propriétés des paramètres. en fait c'est hyper simple à fabriquer, et un widget attaqué avec les bons paramètres en GET peut tre bien être affiché tel quel dans ton navigateur, sans passé pas igoogle ou netvibes.

Spipu (./52) :
ben si... un input text, un radio, un checkbox, un select, un textarea, un file, ca ne se gère pas du tout de la meme maniere pour le traitement ! t'auras parfois des [] en plus, besoin de traitements pour empecher les balises html, relié à un tableau pour associé une clef à une valeur, ..., ... tu ne peux pas dissocier un champ d'un formulaire à la manière dont il est traité derriere.

Tu raisonnes beaucoup trop près du code, ce qui importe au final c'est la nature des éléments manipulés. Si ton code a besoin de recevoir une chaine ce caractère par exemple, tu n'as pas besoin de savoir précisément par quel élément cette chaine va lui être envoyé; c'est ce qui te garantit de conserver un couplage faible entre les différentes parties logiques de ton site, et donc d'avoir quelque chose un minimum modulable.

Le jour où je veux mettre autre chose que de l'HTML en frond-end (une form Windows par exemple), ça doit être possible sans rien changer à mon code métier. Si tu commences à mélanger code et présentation un peu partout, tu vas te retrouver avec un gros truc monobloc complètement impossible à utiliser d'une autre façon.

je crois que ce que toi t'appeles template, moi j'appele ca framework...
[ ... ]
la preuve, pour moi, smarty est un framework donc forcement, on peut pas se comprendre...

Tu mélanges un peu tout : bien sûr que Smarty est un framework, c'est un framework qui gère la partie présentation d'un site web, ça n'a rien d'incompatible ^^

Regarde par exemple ce qu'en dit Wikipedia : "Smarty est un moteur de template pour PHP. [ ... ] Il facilite la séparation entre la logique applicative et la présentation.". Le code que contiennent les templates ne doit (et ne peut) être utilisé que pour modifier l'aspect du site, jamais pour modifier des données; c'est uniquement du code de présentation.

- tu parles de "mettre" de l'ajax dans un site internet qui n'en avait pas au départ, et qui n'en avait pas besoin, juste pour ne recharger que certaines parties. Dans ce cas, le site ne necessite pas l'utilisation d'ajax, c'est juste un confort de rapidité, et dans ce cas là en effet, il n'est pas (forcement) necessaire de refaire tout derriere, de tout eclater, mais juste d'envoyer tout le contenu, et de ne prendre côté client que la partie à mettre à jour.

D'où mon idée initiale (post ./1), mais qui supprime quand même l'un des gros avantages d'Ajax qui était de ne pas envoyer la page entière au client. Problème : comment permettre l'envoi d'une partie de la page sans briser complètement la conception ?

- je parle d'applications web ou l'ajax est obligatoire au fonctionnement, et où tu es obligé d'eclater chaque élément et de n'envoyer que certains car les autres ne pourraient pas l'être de toute facon, car ils ont été générés élément par élément et que tu n'as pas les éléments pour les reconstruire (ex : mon client FTP en PHP que je t'avais montré il me semble, qui construit l'arborescence au fur et à mesure ou tu la développes)

Je ne vois pas vraiment de différence : ton client FTP pourrait très bien fonctionner sans ajax, en rechargeant la page quand on clique sur un lien (attention, je ne me place pas du tout d'un point de vue code : c'est pour moi complètement hors sujet ici, je parle juste de la logique et des concepts manipulés). En fait je cherche actuellement à savoir si ces deux utilisations que tu appelles différentes le sont vraiment, et à l'heure actuelle je n'en suis pas vraiment convaincu mais je manque d'éléments de réponse.

lol, les widgets sont juste des pages tout ce qui a de plus classic, affichés dans des iframes, avec un tout petit xml pour definir la taille de cette iframe et les propriétés des paramètres. en fait c'est hyper simple à fabriquer, et un widget attaqué avec les bons paramètres en GET peut tre bien être affiché tel quel dans ton navigateur, sans passé pas igoogle ou netvibes.

Heu je parle pas de l'intégration du widget dans la page, mais du fonctionnement du widget lui-même. Regarde par exemple le calendrier de netvibes : on peut changer le mode d'affichage (agenda / semaine / mois), ce qui modifie complètement les éléments et la façon dont ils sont présentés, mais ces modifications sont faites sans rechargement, donc Ajax.

Zephyr (./54) :
ton client FTP pourrait très bien fonctionner sans ajax

il faudrait sauvegarder chaque action, et en deduire les conséquences sur l'affichage, ce qui serait un peu... chiant pour le cas d'une arbo

Zephyr (./54) :
En fait je cherche actuellement à savoir si ces deux utilisations que tu appelles différentes le sont vraiment, et à l'heure actuelle je n'en suis pas vraiment convaincu mais je manque d'éléments de réponse.

ben dans un sens oui, etant donné que suivant le type de site / d'application à developper, l'une ou l'autre de ces deux utilisations sera plus adaptée.

Spipu (./55) :
il faudrait sauvegarder chaque action, et en deduire les conséquences sur l'affichage, ce qui serait un peu... chiant pour le cas d'une arbo

Bah vu que tu réaffiches tout à chaque fois, à partir du moment où tu sais quelles actions ont été faites, ça me semble pas si compliqué que ça ^^

ben dans un sens oui, etant donné que suivant le type de site / d'application à developper, l'une ou l'autre de ces deux utilisations sera plus adaptée.

Oui mais finalement, est-ce que l'une n'est pas tout simplement un sous-ensemble de l'autre, sans le sens où tout ce que fait l'une peut être pris en charge par l'autre ? Il me semble que oui ^^

Tiens, je suis globalement d'accord avec la vision du développement qu'a Zephyr

Zephyr (./56) :
Oui mais finalement, est-ce que l'une n'est pas tout simplement un sous-ensemble de l'autre, sans le sens où tout ce que fait l'une peut être pris en charge par l'autre ? Il me semble que oui ^^

en théorie oui, mais en pratique, ... il y a des cas plus chiants que d'autre...

et puis concernant l'abstrasction de la couche affichage, le fenetre de passer d'un affichage web à des fenetres et form windows, et tout et tout... dans la pratique, les entreprises s'en foutent, tant que ca marche, vu que d'ici 2-3ans il y aura déjà une nouvelle version de l'application, utilisant des technologies plus recentes...

avant, y avait PHP4, maintenant PHP5, puis y aura PHP6 dans pas très longtemps... et à chaque changement de techno, soit ils s'arrengent pour que l'ancienne appli marche encore, soit ils refont tout et en profitent pour faire une nouvelle version plus complete et tout et tout...

Spipu (./58) :
en théorie oui, mais en pratique, ... il y a des cas plus chiants que d'autre...

Ça reste faisable, je vais pas aller jusqu'à le faire pour le montrer mais bon un client ftp en php sans ajax, c'est pas une prouesse technique (cf net2ftp, tiens)

et puis concernant l'abstrasction de la couche affichage, le fenetre de passer d'un affichage web à des fenetres et form windows, et tout et tout... dans la pratique, les entreprises s'en foutent, tant que ca marche, vu que d'ici 2-3ans il y aura déjà une nouvelle version de l'application, utilisant des technologies plus recentes...

Erg. Bon, le problème c'est qu'il faudrait copier-coller ici un débat qui était sur IRC y'a pas longtemps et qui pour le coup s'éloigne un peu de l'informatique. Pour résumer, il se trouve que pendant longtemps on a eu tendance à utiliser des développements exotiques en essayant de ne pas se poser de questions sur la pérennité des outils utilisés, entre autres.

Seulement la tendance actuelle en entreprise, c'est pas du tout ça. PHP est justement une catastrophe à ce niveau puisque complètement incompatible avec lui-même à chaque version. On essaie d'avoir de plus en plus de composants réutilisables, avec un couplage faible pour ne pas avoir à tout redévelopper au moindre changement; c'est une tendance qui s'observe aussi bien en architecture logicielle qu'en architecture de systèmes d'information, d'ailleurs. Enfin bref, tout ça pour dire que les développements à court terme et "tant que ça marche c'est bon", pour des grosses entreprises je n'y crois pas trop, pas plus d'ailleurs que l'utilisation de PHP dans le cadre de ces développements.

Dernière précision : je ne suis pas une entreprise, je n'ai pas à être agile et à m'adapter au marché ou réagir face à mes concurrents, donc j'évolue lentement. Une solution non pérenne m'intéresse donc d'autant moins

On va dire qu'il y a presque-retro-compatibilite entre php5/4 hein, c'est d'ailleurs le gros probleme de PHP en general (4 -> 5 ca fait merder sur des appli OO) et quand ca va passer a 6 avec l'unicode, ca va etre bien marrant aussi ca...