UTILISATION D?AJAX ET D?UN WEBSERVICE POUR LA GÉNÉRATION D?IMAGES À PARTIR DE TE
jesusonline
Messages postés
6814
Date d'inscription
dimanche 15 décembre 2002
Statut
Membre
Dernière intervention
13 octobre 2010
-
2 oct. 2005 à 23:36
zouax Messages postés 9 Date d'inscription dimanche 25 janvier 2004 Statut Membre Dernière intervention 20 janvier 2007 - 31 déc. 2006 à 10:17
zouax Messages postés 9 Date d'inscription dimanche 25 janvier 2004 Statut Membre Dernière intervention 20 janvier 2007 - 31 déc. 2006 à 10:17
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/34066-utilisation-d-ajax-et-d-un-webservice-pour-la-generation-d-images-a-partir-de-textes
https://codes-sources.commentcamarche.net/source/34066-utilisation-d-ajax-et-d-un-webservice-pour-la-generation-d-images-a-partir-de-textes
31 déc. 2006 à 10:17
Nous sommes aujourd'hui en 2007, plus d'un an après, qu'en est il ?
Je suis un bidouilleur qui cherche à me mettre au gout du jour (voire du landemain), je réalise de petits sites essentiellements graphiques,
flash, php/mysql si besoin...
dans quelle direction me conseilleriez vous d'aller? j'aime apprendre et réaliser...
merci
il serait intéressant que vous repreniez cette discussion
5 oct. 2005 à 10:26
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
5 oct. 2005 à 02:41
mais microsoft ont quand meme les moyens. Tkfé (qui a fait la partie serveur de ce menu), à surcharcher le render du control menu en très peu de temps et est tombé sur le meme résultat qu'ici tout en gardant les memes propriétés & co du controle original (cette version du controle n'est malheureusement pas en ligne). Optimisé à la base c'est pas compliqué, quand on voit ou en est Atlas, ils ont réussit à faire quelque chose d'extremement poussé en trés peu de temps... et niveau optimisation c'est beaucoup mieux ... http://atlas.asp.net et regarder les hand on labs :)
Sur le fait que pour l'instant asp.net n'est pas du tout fait pour le web grand public la je suis entierement d'accord, et l'abus de datagrid en est bien la preuve ... il aurait été pourtant pas trés compliqué de faire quelques composants grand public, l'architecture est bonne, c'est juste quelques controles, une goutte d'eau par rapport au framework.
et je pense pas que la vitesse de connexion rentre bien dans le débat, c'est vrai qu'une centaine de ko de nos jours c'est rien, mais faut quand meme penser à la surcharge des serveurs, au maintient du code final etc... ok c'est surement moins cher que faire quelque chose de propre coté client, mais tout ces détails font partie du confort de l'utilisateur, un site leger niveau code, sans postback toutes les 2 secondes sera beaucoup plus agréable pour l'utilisateur final ...
pour l'upload sans recharger la page le début est ici : http://blogs.developpeur.org/cyril/archive/2005/10/01/11883.aspx et la fin officieuse est la : http://assistedsolutions.com/Components/SlickUpload/
pour ce qui est de l'optimisation, je fais du javascript (etonnant non ? ;)) et la aussi niveau optimisation possible il y a de quoi plaire ;)
5 oct. 2005 à 02:18
"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
3 oct. 2005 à 17:06
Pour le reste, je suis pas vraiment d'accord, je pense que microsoft va revenir en arriere sur le code html de ces controles, en effet les grands dirigeants d'asp.net (Scott Guthrie et toute la bande) sont en train de travailler sur le projet Atlas , qui n'est autre que du travail coté client, j'ai pas appronfondis le truc, mais le peu de javascript que j'ai vu c'est du trés haut niveau et trés joli, et je doute qu'ils vont desormais se permettre de faire du HTML horrible ...
Pour le fait que réécrire une fonction en js c'est lourd et cher, oui je suis d'accord, après il faut faire la part des choses, comme je crois l'avoir déjà dit, moi je me concentre sur le web grand public et particulierement sur l'interface utilisateur, et c'est rare qu'on est des calculs d'amortissement & co pour le grand public. Et puis javascript je ne le vois pas comme ca, il faut que toutes les actions soient possible sans javascript, que javascript apporte juste un plus en terme de confort à l'utilisateur finale.J'ai parlé tout à l'heure de Webpart qui faisait des postback inutile, l'autre jour on a vu le cas d'un upload sans rafraichissement de la page etc... Ajax doit servir à des choses comme ca, et non a des choses complexes.
Sinon pour la taille des pages sur le net, si quand j'ai touché le code de CS j'avais eu un peu plus d'experience en terme de clientside j'aurais fait bien differement, j'aurais fait en sorte que tout ce qu'il ne change pas reste sur la page, mais seulement ce qui est à l'interieur change ...
Je pourrais trés bien modifier le menu pour qu'il ne fasse que quelques octets, mais le problème est google :( qui lui doit manger. Sur mon site perso : www.cyrildurand.net je me fou de google et je me suis fait plaisir, c'est certe petit mais le principe est là. Tu vois bien que niveau optimisation on peut faire trés fort. et je ne pense pas que dans l'avenir les pages seront de plus en plus lourde, et Atlas (qui n'est autre qu'un tout petit apercu d'asp.net 3) va faire trés fort dans ce sens. Regarde bindows.net (le forum) ou winlike.com tu vois bien que la les pages sont légères ... et pourtant trés riche. C'est vers ca que petit à petit on se tourne, en tout cas moi c'est dans ce sens que je vais, et la prochaine version de CodeS-SourceS, sera beaucoup plus legere que maintenant (si j'ai le temps de m'en occuper bien sur ;))
3 oct. 2005 à 15:00
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
3 oct. 2005 à 12:08
C'est justement pour ca que j'aime pas .net ;) oui .net nous genere plein de code HTML / javascript ... c'est une bonne chose pour ceux qui n'aiment pas ca, mais le problème c'est qu'il le genere mal. J'en prend pour exemple le triste menu d'asp.net2, Nix a voulu s'en servir pour ce site, résultat 120ko de code HTML inutile ... j'ai mis les mains dedans je suis dessendus entre 15 et 20ko (je me souviens plus exactement)
c'est bien dommage que microsoft n'ai pas fait un petit effort pour faire quelque chose de correcte :( surtout que ca va etre utilisé sur plusieurs centaines/milliers de sites ...
Autre exemple, les webparts, c'est "super" beau etc... mais 3 problèmes, le code HTML est bien sur hyper lourd, il n'y a pas le meme rendu sous Firefox et IE, des qu'on a envie de deplacer un webpart cela nous fait un postback ...
enfin un dernier exemple, le datagrid et sa pagination, il y a aucun moyen de faire ca autrement que par postback (si ce n'est de tout refaire) qui dit postback, dit javascript, donc deja ca rend les autres pages invisibles pour pas mal de personnes, on me répond souvent qu'ils n'ont qu'a avoir javacript d'installé ! je suis d'accord avec ca, si ce n'est que google lui n'a pas javascript ...
Toutes ces petites raisons me font dire qu'asp.net c'est pas fait pour faire du web grand public :( ou alors faut connaitre trés bien l'affaire.
Sinon pour la librairie ajax.net je l'aime pas, non pas parce qu'elle est pas super, au contraire, mais parce qu'elle va encore plus emmeler les debutants. Sur le forum, beaucoup de personnes n'ont pas compris la difference entre code coté serveur et code coté client (oui ca fait peur, mais vu la facon dont microsoft a voulu nous faire croire que develloper des webforms c'est pareil que dev des winforms c'est normal ...) donc avec cette librairie j'ai bien peur qu'il y ait encore plus de confusion, et aussi qu'on travaille encore moins sur le client. Personne n'aime javascript (a part quelque fou dont je fais partis ;)) donc beaucoup de personne vont preferer faire quelque chose coté serveur, avec un appel par ajax, alors que c'est inutile.
Ton exemple en est un cas concret, t'as voulu faire quelque chose coté client, tu t'ai dit que ca allait être compliqué alors que coté serveur c'etait simple, donc tu utilises cette librairie pour combler "le manque" de connaissance en javascript (y'a rien contre toi la je comprend trés bien)
Mais tout ce qui risque de se passer avec cette librairie c'est qu'il va y avoir plein de requete ajax inutile ...
Je sais, c'est bien beau de gueuler contre microsoft, mais ca n'avance pas grand chose, c'est pour ca que je fais un framework javascript, qui permet de faire des choses belles (webparts etc...) et cela avec un code correcte :)
J'espere avoir été compréhensible j'ai la flemme de relire ;)
3 oct. 2005 à 11:50
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 .
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
2 oct. 2005 à 23:36
Par contre dans ton cas il aurait suffit qu'au click sur le bouton tu changes l'url de l'image en quelque chose du genre :
image.ashx?text=coucou&couleur=rose&type=jpeg Ajax c'est trés puissant mais pas à servir à toutes les sauces :p
Je comprend bien que c'etait seulement pour montrer l'utilisation d'ajax :)
Sinon, si tu veux voir des vrais choses en Ajax, je ne peux que te conseiller d'aller faire un tour du coté de http://script.aculo.us qui se sert du magnifique framework prototype (http://prototype.conio.net/) tu peux aussi aller voir Rico (http://openrico.org/rico/) qui est un autre framework basé sur prototype
et pour finir si tu veux voir tout ca en interaction avec le .net framework : tu peux aller voir le framework HackHours (www.hackhours.com) developé par la société Wygwam (grands experts .net francophone) le framework n'est pas encore sortis mais connaissant les fous furieux et en ayant vue un tout petit peu ca s'annonce plus que trés prometteur !!! :)
Le ClientSide c'est l'avenir du web :)
PS : l'url d'ajax.net que tu donnes n'a pas l'air bonne : ici c'est la bonne http://ajax.schwarz-interactive.de/csharpsample/default.aspx :)