Utilisation d?ajax et d?un webservice pour la génération d?images à partir de textes
0/5 (9 avis)
Vue 22 989 fois - Téléchargée 1 629 fois
Description
Ce matin, Cyril m?a donné envie d?aller voir Ajax d?un peu plus prêt, et c?est vrai que c?est pas mal de pouvoir faire du code assez lourd et coté serveur et réinjecter le résultat dans la page sans que celle-ci se recharge complètement.
J?ai donc utilisé la dll Ajax.Net que vous pouvez (et devez si vous voulez que ça marche) charger à l?adresse suivante : http://ajax.schwarz-interactive.de/csharpsample/default.aspx et un web service de Xara que vous pouvez trouver à l?adresse suivante : http://ws.xara.com/graphicrender/soap/render3d/info.asp
Au niveau du code, y?a pas grand-chose à dire, c?est du Ajax pour les Nuls avec du WebService pour les Nuls (y?a deux boutons, l?un utilise une méthode classique, et l?autre fait la même chose mais avec Ajax).
Le résultat est assez intéressant et peux donner des idées à certains d?entre vous.
La source peut encore s?améliorer en gérant les couleurs du texte et du fond ainsi que la taille du texte (le WebService le fait, je ne l?ai pas implémenté).
J?ai donc utilisé la dll Ajax.Net que vous pouvez (et devez si vous voulez que ça marche) charger à l?adresse suivante : http://ajax.schwarz-interactive.de/csharpsample/default.aspx et un web service de Xara que vous pouvez trouver à l?adresse suivante : http://ws.xara.com/graphicrender/soap/render3d/info.asp
Au niveau du code, y?a pas grand-chose à dire, c?est du Ajax pour les Nuls avec du WebService pour les Nuls (y?a deux boutons, l?un utilise une méthode classique, et l?autre fait la même chose mais avec Ajax).
Le résultat est assez intéressant et peux donner des idées à certains d?entre vous.
La source peut encore s?améliorer en gérant les couleurs du texte et du fond ainsi que la taille du texte (le WebService le fait, je ne l?ai pas implémenté).
Codes Sources
A voir également
- Utilisation d?ajax et d?un webservice pour la génération d?images à partir de textes
- Ajax synchrone - Conseils pratiques -Javascript
- Générateur de carte d identité ✓ - Forum PHP
- Diagramme de cas d utilisation - Forum Java
- Générateur de lettre ✓ - Forum VB.NET
- Generateur de facture ✓ - Forum PHP
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 :)
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
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 à 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 à 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 ;))
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.