Hello Cyril.

Cette source c'est vraiment la première brique d'un developpement que je suis en train de faire pour un client... et comme je l'ai dis, d'autres posts vonts suivre (et les résultats sont vraiment sympas, un peu de patience).
Pour ta pub, tu as bien raison : je l'avais faite sur mon blog concernant ce sujet : http://blogatik.com/blogs/tik/archive/2007/01/25/open-xml-package-explorer-le-couteau-suisse-pour-d-velopper-en-openxml.aspx (j'en profite pour faire la mienne ;-) ).

Bon code à tous
TiK

Bonsoir,

C’est effectivement très sympathique comme résultat… mais je reste toujours sur ma faim pour le chargement de plusieurs fichiers en html pur. Je rêve toujours de pouvoir sélectionner plusieurs fichiers d’un coup, ou un répertoire, ou de faire un glisser déposer comme ou peut le faire dans les sites de photos en installant un activex… elle va évoluer quand cette balse <input type= "file"/> !!!

Hello,

J'ai pas regardé en détail, mais l'ASP propose des fonctions sur les dates, et autant les utiliser.
En utilisant la fonction DateDiff, ta fonction peut devenir la suivante :

function age(dat)

dim vAge
dim vNow
dim vDateNaissance
vDateNaissance = cdate(dat)
vNow = Date
vAge = clng(datediff("yyyy",cdate(dat),vNow))
'on enlève un an si la bougie n'a pas été soufflée dans l'année en cours
if DateDiff("d",DateSerial(year(vNow),Month(vDateNaissance),Day(vDateNaissance)),vNow) > 0 then
vAge = vAge - 1
end if
age = vAge

end function

Bon code,

Christophe

Bonjour,

En fait j'avais un peu la fleme d'utiliser l'éditeur html. Dès que je retrouve un peu de courage, je referai une version plus ASP.NET en version tutorial et je te fais signe.

Hello,

Je vais faire ce qu'il faut pour les \bin et \obj
Pour la traduction, c'est extactement la même que google ou altavista. Je pense que tout le monde doit se servir du même moteur qui doit être ici je pense : http://www.systranbox.com/

Merci à vous pour vos commentaires, et pour cette note digne de l’école des fans.
Et très honoré d’avoir attiré l’attention du maitre des lieux.
Pour ce qui est de la compatibilité avec les différents navigateurs, la source du problème est clairement identifiée… et j’avoue que je rechigne un peu à mettre les mains dans le cambouis (je vais peut-être laisser Cyril le faire ;-)).
Pour la lenteur… l’url de test est hébergée sur ma machine (un P3 733 avec 512Mo) derrière une Freebox. C’est certain que si tu arrives pendant que je suis en train de compiler ça va être un peux lent, mais sinon ça reste quand même « acceptable ».
Pour le préload, c’est justement ce que l’on veut éviter afin de limiter les transferts. Donc c’est vrai que quand tu arrives sur un item sur lequel tu n’es pas encore allé ça prend un peu de temps pour charger.

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

Première remarque... change le niveau de la source, j'aime pas me faire traiter de débutant parceque je dois lire plusieurs fois la source avant de la comprendre ;-)
Deuxième remarque, ça fait longtemps que je n'avais pas utilisé de Handler (depuis que je ne bosse plus sous J2EE en fait)... j'en ai déclaré un hier avec Ajax, et aujourd'hui tu me montres comment faire les siens déjà ça c'est cool.
Pour la fonctionnalité, ben moi pour l'instant c'est pas certain que ça puisse me servir et je ne savais même pas que l'interface IUCStandAlone existait... ça doit être u truc réservé aux amateurs du "ClientSide" ça ;-) ... allé pas de 10 parceque j'ai du faire du copier/coller

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

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