UTILISATION D’AJAX ET D’UN WEBSERVICE POUR LA GÉNÉRATION D’IMAGES À PARTIR DE TEXTES

Commentaire de tikrimi le 03/10/2005 11:50:22

Kikoo,

Effectivement, ça ne sert à rien de passer pas l’Ajax dans ce cas, il y a juste à changer l’url de l’image avec l’url qui va bien, je n’y avais même pas pensé. Enfin bon, ce que je voulais moi c’est que l’url provienne d’un code exécuté par le serveur.

Par contre pour ce qui est du composant, je pense que l’on n’a pas la même vision.
Ce que je trouve génial avec la librairie ajax.net, c’est que moi en tant de développeur « ancienne génération » qui a une profonde allergie à tout ce qui est JavaScript, Css et tout ce qui ce passe coté client, cette librairie permet de laisser la frontière entre les deux métiers : le développeur métier et le mec qui s’occupe de faire des trucs jolis sur la page (c’est pas du tout du mépris, c’est que suivant les boites il n’a pas le même nom).
Tout en laissant cette frontière, on peut maintenant discuter autrement qu’en postant les pages grâce au <Ajax.AjaxMethod()>.
Ca ne change pas la manière de travailler du développeur : il doit juste ajouter une ligne avant les méthodes qu’il veut proposer au monteur (dans mon ancienne boite c’est le nom que l’on donnait au mec qui s’occupe de faire des trucs jolis sur la page).
Ca ne change pas non plus la manière de travailler du monteur, sauf que en plus il peut demander au développeur de lui faire des fonctions (que lui va voir comme une fonction javascript) qui vont exécuter du code sur le serveur et lui renvoyer une valeur sans poster sa page (il va être super content lui).
Ensuite, moi je ne fais de l’Ajax que depuis hier ;-), donc tu as beaucoup plus de recul que moi là-dessus, mais dans mon cas je n’ai vraiment rien à reprocher à cette librairie

Je suis allé voir les urls, effectivement c’est beau, mais voilà c’est du javascript et c’est pas mon métier (libre ensuite au monteur de l'utiliser ou non).

Pour le ClientSide qui est l’avenir du web, pourquoi pas si j’ai pas à y mettre les mains dedans ;-) : c’est pour ça que j’aime bien développer en .net … c’est le framework qui s’occupe de générer la majeure partie du code client.

Bosse bien, et merci pour tous tes articles et commentaires

TiK

Commentaire de tikrimi le 03/10/2005 15:00:51

Je suis entièrement d’accord avec toi, le code Html généré n’est souvent pas optimisé, il est lourd, mais ça ce n’est pas une nouveauté et ça ne va pas changer.
C’est vrai que 100ko c’est gros pour un menu et que 20ko c’est mieux… mais il n’y as pas si longtemps, 20ko c’était aussi énorme. Il y’a seulement 1 ans et demi j’ai bossé pour la société générale, et pour être validées, nos pages devaient faire moins de 60ko (includes js, images, flash, … compris).
La personne qui arrive actuellement pour la première fois sur www.codes-sources.com avec son modem 56k (l’adsl n’est arrivé dans ma campagne qu’en Avril de cette année donc ce n’est pas un si vieux souvenir) va mettre plus de 30 secondes pour télécharger les 171ko de la page (si l’intégralité de sa connexion est dédiée à cette tache… il va mettre en fait plus de la minute pour afficher la page). Il y a même pas deux ans tu aurais été le premier à hurler en disant « mais c’est n’importe quoi ce menu, à chaque page on recharge tout le contenu du menu alors que pratiquement rien ne change et qu’on aurait pu faire ça avec un include navigateur pour ne le charger qu’une fois ».
Tout ça pour dire que peut-être que dans un an ou deux ça sera la norme d’avoir un menu de 300ko … tu seras encore là pour l’optimiser et en faire un menu de 100ko … mais pour une fois Microsoft aura été visionnaire en étant les premiers à faire des menus de 100ko !!!
C’est normal à ton âge de vouloir tout optimiser (moi je faisais ça en assembleur), c’est très formateur, et on a raison d’être fier du résultat. Pour avoir pas mal cherché de menus multi hiérarchique, je peux te dire que le tien visuellement est une vrai réussite, et rien qu’à voir le html généré pour la rubrique Emploi… un 3ème niveau de ul, je suis certain qu’il est super propre et qu’il a été généré à partir d’une structure arborescente… je n’aime pas prendre les sources sans demander, donc si tu m’y autorises je suis preneur.
Sinon, tu as (a mon avis) une très bonne vision du .Net… oui ce n’est pas à la porté de tout le monde, et c’est vrai que Microsoft est « limite » dans sa communication en faisant croire qu’en lisant .Net pour les nuls en une semaine on sait développer en WinForm et en WebForm.
Dans l’absolu tu as raison d’avoir peur que l’on risque de déporter vers le serveur des opérations qui peuvent être effectuée par le client… mais il faut aussi te placer dans des contraintes de projets.
Imagine un calcul d’amortissement financier. Pour réaliser ce calcul on a besoin de quelques paramètres, et ce calcul existe et est effectué par une classe .Net (une bonne méthode Shared comme tu les aimes ;-)). Il a fallu un certain temps pour écrire cette fonction, mais maintenant elle tourne super bien.
On peut tout à fait réécrire cette fonction en JavaScript pour que le navigateur calcule lui-même son tableau d’amortissement… mais si tu es chef de projet vas-tu consommer du budget pour réécrire cette fonction (sachant qu’ensuite il y aura deux codes à maintenir dans deux langages différents), ou bien va tu gaspiller un peu de bande passante (ce qui n’est d’ailleurs pas certain car du coup le JavaScript n’est plus à charger par le client), et un peu de temps CPU sur le serveur ?
Voilà, désolé de faire aussi long, mais je pense que nos conversations sont de bonne qualités et peuvent intéresser donc je laisse tout le monde en profiter.

TiK

Commentaire de arcollet le 05/10/2005 02:18:57

Bonsjour,

"jour on a vu le cas d'un upload sans rafraichissement de la page"
Please ça m'intéresse, as tu un exemple ?

Merci

Denis

PS : Puis je m'intéresser au débat ? je considère que c'est oui :°)

Il sera toujours utile d'optimiser tout code généré automatiquement. C'est le rôle des Editeurs comme Microsoft pas celui des développeurs. Néanmoins en tant que professionnels que nous sommes nous nous devons un certain degré de qualité et de clarté dans ce que nous codons. Et notre secteur professionnel doit jouer également son rôle de baromètre pour les éditeurs.

Malheureusement les contraintes de budget/temps sont là pour nous rappeller à l'ordre. Je ne t'apprend rien mais lorsque l'environnement réseau est rapide de l'ordre de 2-8Mbits/s débit minimum garantis cf BLR par exemple, que ta page fasse 20ko ou 200ko, peu importe, l'utilisateur final ne verra même pas la différence. Ce type de réseau est pourtant courant en entreprises "distantes". Evidemment des gens comme moi avec une connectique à la wanadoo de 1Mbit/s en pleine cambrousse font un peu la gu... mais bon aucune chance de voir une quelconque application de gestion à l'horizon et donc merci aux développeurs comme jesoline qui code des sites grands publics légers.

Cependant imagine toi, jesoline, en chef de projet (c'est peut-être le cas :°) où tu as la maitrise des investissements réseaux et développements pour un projet clef de l'entreprise, faut faire vite car sinon le projet ne servira plus à rien et tu n'as pas un budget à rallonge. Tu verras que le coût qualité d'un projet d'optimisation est super cher et super long par rapport au coût d'amélioration de ta bande passante. Le choix entre la stratégie "tikrimi" et "jesusonline" est vite fait, surtout si tu dis à ton big boss, cool ça coute les yeux de la tête mais on peut quand même passer de 120ko à 20ko par page, sachant que ton produit dans sa version initiale à une durée de vie de l'ordre de 1 à 2 ans et que dans 1 ans en entreprise tes 20ko n'ont pas plus d'effet que tes 120ko.

Microsoft a bien compris cet état de fait, et c'est en toute conscience qu'il a commercialisé son framework .net et ses défauts, javascript compris. L'optimisation immédiate était donc inutile d'un point de vue marketing/financier car supportable par l'évolution des réseaux, c'est moins évident en france car on as du retard au niveau infrastructure. Donc On crée la dépendance en masse et on améliore au fur et à mesure. Pourtant Microsoft avait bel et bien la capacité de lancer son framework .net 1 avec la qualité de la 3, sauf que ça aurait couté 5 fois plus cher par rapport au client initialement ciblé.

Initialement .Net est ciblé sur le marché de la PME à moyenne entreprise ou le temps de dev est court car le budget esr réduit, sachant que les grandes entreprises sont quasi inféodées à java et ne passeront probablement à .net quant version 3 ou 5. Et c'est dans le domaine des applications de gestion que .net remporte quant même un franc succès et qu'il dégage des bébéfices pas dans celui du marché des sites web grand public qui largement investi par PHP/MySQL.

Utiliser .Net 1.1 à 2 dans le dev des sites web dynamiques est un bon choix en terme de conception/maintenance donc orienté développeurs mais pas toujours pertinant pour le client (coût plus élevé) et l'internaute (bande passante).

Sinon si tu es passionné d'optimisation tu es ou seras intéressé par Rebol, côté légéreté c'est le champion !

Denis

Commentaire de tikrimi le 05/10/2005 10:26:07

Commentaire de : arcollet le 05/10/2005 02:18:57
Commentaire de : jesusonline le 05/10/2005 02:41:52

TiK ecrit le matin avant d'aller prendre un café

Nan mais franchement, c'est une heure ça pour faire de la philosophie !!!!

Dans tous les cas c'est un plaisir de vous lire... et je me prépare à faire un retour en fanfare dans cette discussion de "haute volléé" qui n'a rien à envier aux différents articles que l'on peut voir dans la presse "spécialisée".

Bon travail à tous,

TiK