Creer un javascript via WS-XML

Dans son message 4256a9f4$0$6565$636a15ce@news.free.fr
Delf nous dit :

Bonjour.

J'ai une page ASP.NET qui consomme un WebService.

Le WebService propose entre-autre 2 méthodes :

- GetDir(folder) : retourne le contenu (folders et files) de
'folder', - GetData(file) : retourne des informations concernant 'file'.

Au niveau de la page ASP.NET, l'utilisateur aura un menu listant les
répertoires et un cadre contenant les informations des fichiers
contenus dans le répertoire courant.

Le problème est qu'à chaque appel de GetDir/GetData, la page ASP devra
être être de nouveau chargée pour afficher le nouveau contenu... bref,
pas très adapté (note : si c'était pour moi, je m'en satisferais :)).

Je me demandais donc si je n'implémentais pas une nouvelle WebMethode
en utilisant GetDir et GetData afin de récupérer d'un seul jet
l'arborescence entière des folders et de leurs contenus. A coup
récursif, ça devrait être bon.

Le *vrai* problème maintenant est de créer un JavaScript à partir du
résultat de cette WebMethode qui retournerait un fichier XML. Je
verrai grosso-modo le fichier comme suit :

<folder name="/">
<folder name="rep1">
<folder name="subrep1"/>
<file name="subfile"/>
</folder>
<folder name="rep2"/>
...
<file name="file1"/>
...
</folder>

Voilà, en gros j'obtiendrai un tel fichier côté WebService. Il
suffirait ensuite de l'envoyer à la page ASP sous forme d'objet qui
en ferait un JavaScript. Ainsi, on n'aurait plus de chargement de
page et d'appel de WebService à chaque navigation dans l'arborescence.

J'ai simplifié le problème mais globalement, c'est ce que je
souhaiterais faire. Des conseils ? suggestions ?

Comment faire un tel JavaScript (note : je ne connais pas du tout le
monde du JavaScript :) ?

Merci d'avance.

NB : Je ne pourrais pas voir les retours ce week-end, en espèrant
avoir des indications Lundi. Bon week-end.

Bonjour,
Première impressions en voyant ton problème.
J'utiliserais un control treeview alimenté côté serveur par des appels
récursifs à GetDir.
Chaque noeud du Treeview serait un lien hypertexte vers une seconde page
aspx prenant en paramètres les infos nécessaires à la fonction GetData,
cette seconde page serait bien sûr ouverte dans ton iframe (donc pas de
rechargement du treeview)
J'ai testé ceci dans un autre contexte (BDD avec une structure
hiérarchique), cela fonctionne très bien.
Tu peux aussi, mais cela je ne l'ai pas testé, faire appel à ton WebService
côté client, lors d'un clic sur le Treeview pour appeler les infos du
fichier et remplir un div par exemple (seules les infos fichiers se
promènent dans ce cas). Mais là, je pense qu'il va te falloir programmer en
javascript, alors que la première méthode offre l'avantage d'une
programmation très simple côté serveur.
Tu parles également de XML, pense à regarder du côté des feuilles de styles
XSL et du contrôle serveur XML quelquechose.
A l'extrême, la programmation de tes pages peut se limiter à la création du
treeview.

--
Fred

Bonjour,
Quelques compléments par rapport à ce que j'ai cité.
Au cas où l'arborescence serait trop importante, j'ai regardé comment
appeler un service web côté client, qui te permettrait de la peupler
uniquement sur demande de l'utilisateur (un peu à la manière de la MSDN
Library sur internet).
Tu peux trouver quelques exemple en recherchant "WebService behavior" et
"Accessing Web Services From DHTML".
Le WebService behavior te permet de récupérer, grâce à la propriété "raw",
le retour XML de la fonction appelée. Ceci comprend toute l'enveloppe SOAP
mais en appliquant une feuille de style XSL tu dois pouvoir transformer ce
qui t'intéresse en HTML et l'intégrer directement dans ton document.
Inconvénient : cela ne sera accessible je pense qu'avec IE, cet inconvénient
présente l'avantage que tu peux programmer en VBScript.

Après avoir posté mon premier message j'ai pensé que dans le cas où
j'utilise le treeview, je le peuple avec des données locales. Ce qui n'est
peut-être pas ton cas ? La création du treeview va multiplier les appels du
serveur du site vers le serveur du webservice.



--
Fred

Fred wrote:

> [...]

Merci pour ta réponse.

Tu peux trouver quelques exemple en recherchant "WebService behavior" et
"Accessing Web Services From DHTML".
Le WebService behavior te permet de récupérer, grâce à la propriété "raw",
le retour XML de la fonction appelée. Ceci comprend toute l'enveloppe SOAP
mais en appliquant une feuille de style XSL tu dois pouvoir transformer ce
qui t'intéresse en HTML et l'intégrer directement dans ton document.
Inconvénient : cela ne sera accessible je pense qu'avec IE, cet inconvénient
présente l'avantage que tu peux programmer en VBScript.

Il ne faut pas que je me cantonne qu'à IE...

Après avoir posté mon premier message j'ai pensé que dans le cas où
j'utilise le treeview, je le peuple avec des données locales. Ce qui n'est
peut-être pas ton cas ?

C'est-à-dire ?
Les répertoires et fichiers à afficher sont ceux du serveur sur lequel
sont stockés ces documents.

Et j'ai encore une contrainte en plus, possibilité d'ajouter, effacer,
renommer, etc des fichiers/files...

Ca va être une vraie galère...

--
Delf

Fred wrote:

J'utiliserais un control treeview alimenté côté serveur par des appels
récursifs à GetDir.

Quel contrôle Treeview ? En ASP.NEt ? Je n'ai rien trouvé de tel...

Chaque noeud du Treeview serait un lien hypertexte vers une seconde page
aspx prenant en paramètres les infos nécessaires à la fonction GetData,
cette seconde page serait bien sûr ouverte dans ton iframe (donc pas de
rechargement du treeview.
J'ai testé ceci dans un autre contexte (BDD avec une structure
hiérarchique), cela fonctionne très bien.

Et si les données à afficher peuvent changer ? Est-ce que l'affichage
est dynamique ?

--
Delf

Dans le message:425a678e$0$10738$626a14ce@news.free.fr,
Delf écrit :

Fred wrote:

[...]

Merci pour ta réponse.

Tu peux trouver quelques exemple en recherchant "WebService
behavior" et "Accessing Web Services From DHTML".
Le WebService behavior te permet de récupérer, grâce à la propriété
"raw", le retour XML de la fonction appelée. Ceci comprend toute
l'enveloppe SOAP mais en appliquant une feuille de style XSL tu dois
pouvoir transformer ce qui t'intéresse en HTML et l'intégrer
directement dans ton document. Inconvénient : cela ne sera
accessible je pense qu'avec IE, cet inconvénient présente l'avantage
que tu peux programmer en VBScript.

Il ne faut pas que je me cantonne qu'à IE...

Je crains que toutes mes suggestions ne tombent à l'eau. Il me semble que
seul IE comprends l'attribut behavior dans une feuille de style CSS (je n'ai
pas trouvé cet attribut dans la norme CSS2)
Le treeview dont je te parlais n'est pas inclu dans Studio .NET, il est en
téléchargement chez MS, mais sous le nom IE WebControls, donc toujours le
même problème par rapport à d'autres navigateurs.

Après avoir posté mon premier message j'ai pensé que dans le cas où
j'utilise le treeview, je le peuple avec des données locales. Ce qui
n'est peut-être pas ton cas ?

C'est-à-dire ?
Les répertoires et fichiers à afficher sont ceux du serveur sur lequel
sont stockés ces documents.

Oui, mais est-ce le serveur qui héberge l'application ?

Et j'ai encore une contrainte en plus, possibilité d'ajouter, effacer,
renommer, etc des fichiers/files...

Ca va être une vraie galère...

Ta contrainte de pouvoir ajouter, effacer ou renommer des fichiers et
répertoires rend le problème beaucoup plus complexe si tu n'acceptes pas la
réactualisation de ton arborescence.
Pourquoi ne pas faire une page de navigation plus simple (sans arborescence)
à la façon de l'explorer Windows.
Quand tu cliques sur un dossier, une nouvelle page s'affiche avec son
contenu. Et tu prévois un lien pour remonter.
Je sais que ce n'est pas ton but initial, mais vu la difficulté de gérer un
treeview dynamiquement et pour n'importe quel navigateur, je ne vois pas de
solution 'simple'. Il suffit de regarder le contenu de webservice.htc ou de
treeview.htc pour s'en convaincre. Pour un début en javascript on peut
trouver mieux :-(
Une chose que je n'ai pas faite, c'est de chercher sur le web un UserControl
qui ferait cela.

Si tu acceptes les rafraîchissement de l'arborescence, alors le contrôle XML
de asp .NET serait un bon compromis. Tu génères ton fichier sur le serveur
comme tu le supposais et tu lui appliques une feuille de style pour la mise
en forme, ton fichier XML se transformerait par exemple en une imbrication
de DIVs. Côté client, tu peux replier ou déplier ton arborescence assez
simplement en jouant sur les attributs visibility. Du coup, cela nécessite
de se plonger dans le XSL.
Dans le cas du contrôle XML, le résultat serait indépendant du navigateur
puisque c'est toi qui génère le HTML par ta feuille de style.

Ton problème n'a pas suscité beaucoup de réponses. J'aurais aimé avoir
l'avis de spécialistes. Je t'ai donné des solutions que j'avais appliquées
mais je ne suis pas sûr que de meilleures méthodes n'existent pas.

--
Fred

Fred wrote:

Je crains que toutes mes suggestions ne tombent à l'eau. Il me semble que
seul IE comprends l'attribut behavior dans une feuille de style CSS (je n'ai
pas trouvé cet attribut dans la norme CSS2)

Oui, apparemment, seul IE 5+ gère cette 'chose'.

Le treeview dont je te parlais n'est pas inclu dans Studio .NET, il est en
téléchargement chez MS, mais sous le nom IE WebControls, donc toujours le
même problème par rapport à d'autres navigateurs.

Je suis passé par une table 1*2 contenant 2 datalist : une pour les
folders, et l'autre pour le contenu du folder en cours. J'arrive à
naviguer dans l'arborescence (sauf si l'utilisateur fait un GoBack sans
passer par le lien '..'). Et puis, cest du HTML chez le client,
exploitable par tous les browsers donc.

J'ai toujours le problème qu'à chaque déplacement, j'appelle le WS.
Personnellement, un échange SOAP (pour récupérer le contenu d'un
répertoire) à 90% en local consomme bcp moins qu'un GetDir récursif.

Mes tests : la consommation du WS pour 1 répertoire ne prend même pas
1sec pour lancer, récupérer et traiter la requête. Faire un GetDir
récursif m'en prend 9... et après ya tout l'aspect dynamique à mettre en
place...

Et quand je vois la RAM que prend ASPNET_WP... 30/70mo, je pense pas que
ce soit 10 échanges SOAP qui consomment le plus (j'estime que
l'utilisateur ne fera pas plus de 10 clicks en moyenne pour se déplacer
dans l'arborescence)...

Oui, mais est-ce le serveur qui héberge l'application ?

Oui.

Ta contrainte de pouvoir ajouter, effacer ou renommer des fichiers et
répertoires rend le problème beaucoup plus complexe si tu n'acceptes pas la
réactualisation de ton arborescence.

Dans le cas de la modification de l'arborescence, je devrai reconsommer
le WS, c'est sûr (dans le cas où je veux *vraiment* savoir si la
modification a été apportée...).

Pourquoi ne pas faire une page de navigation plus simple (sans arborescence)
à la façon de l'explorer Windows.
Quand tu cliques sur un dossier, une nouvelle page s'affiche avec son
contenu. Et tu prévois un lien pour remonter.

C'est en gros ce que j'ai fait avec les 2 DataLists.

Je sais que ce n'est pas ton but initial, mais vu la difficulté de gérer un
treeview dynamiquement et pour n'importe quel navigateur, je ne vois pas de
solution 'simple'.

C'est ce que je me dis aussi.

Si tu acceptes les rafraîchissement de l'arborescence, alors le contrôle XML
de asp .NET serait un bon compromis. Tu génères ton fichier sur le serveur
comme tu le supposais et tu lui appliques une feuille de style pour la mise
en forme, ton fichier XML se transformerait par exemple en une imbrication
de DIVs. Côté client, tu peux replier ou déplier ton arborescence assez
simplement en jouant sur les attributs visibility. Du coup, cela nécessite
de se plonger dans le XSL.

J'avais déjà fait qqchose de ce genre il y a plusieurs mois... et je
n'ai plus la source :'(

Dans le cas du contrôle XML, le résultat serait indépendant du navigateur
puisque c'est toi qui génère le HTML par ta feuille de style.

Finalement, la page ASP.NET (si je passe par un GetDir récursif) ne
recoit pas une string-XML mais un objet représentant l'arborescence
entière. D'un autre coté, j peux générer du XML au lieu de l'objet, ce
n'est pas un problème.

Je vais voir ce que je peux faire avec une transformation XSL, je
connais pas.

Ton problème n'a pas suscité beaucoup de réponses. J'aurais aimé avoir
l'avis de spécialistes. Je t'ai donné des solutions que j'avais appliquées
mais je ne suis pas sûr que de meilleures méthodes n'existent pas.

Tous les avis sont bon à prendre.
Merci bcp de ton aide.

--
Delf

"Delf" <abuse@wanadoo.fr> a écrit dans le message de
news:425a9934$0$10746$626a14ce@news.free.fr...

Fred wrote:

[]

> Oui, mais est-ce le serveur qui héberge l'application ?

Oui.

Dans ce cas, quelquechose m'échappe, pourquoi un service web ?

> Ta contrainte de pouvoir ajouter, effacer ou renommer des fichiers et
> répertoires rend le problème beaucoup plus complexe si tu n'acceptes pas

la

> réactualisation de ton arborescence.

Dans le cas de la modification de l'arborescence, je devrai reconsommer
le WS, c'est sûr (dans le cas où je veux *vraiment* savoir si la
modification a été apportée...).

Et il y a un autre problème (qui ne se pose peut-être pas dans ton cas) :
que se passe-t-il en cas d'accès simultané de plusieurs utilisateurs ?

> de asp .NET serait un bon compromis. Tu génères ton fichier sur le

serveur

> comme tu le supposais et tu lui appliques une feuille de style pour la

mise

> en forme, ton fichier XML se transformerait par exemple en une

imbrication

> de DIVs. Côté client, tu peux replier ou déplier ton arborescence assez
> simplement en jouant sur les attributs visibility. Du coup, cela

nécessite

> de se plonger dans le XSL.

J'avais déjà fait qqchose de ce genre il y a plusieurs mois... et je
n'ai plus la source :'(

En fait, je voulais te suggérer le news scripting dans mon dernier post et
j'ai oublié. Là bas tu trouveras des pointures en javascript. Pour ce qui
est de l'exemple cité, cela se traduit par un événement onclick sur tes
objets du style :
<html>
<body>
<div onclick="javascript:if(this.children(0).style.display=='block')
this.children(0).style.display='none'; else
this.children(0).style.display='block';" >
En-tête
<div style="display:block;">Contenu</div>
</div>
<p>Fin</p>
</body>
</html>
Mais, bon, si tu n'a plus de treeview cela perd de son intérêt.

> Dans le cas du contrôle XML, le résultat serait indépendant du

navigateur

> puisque c'est toi qui génère le HTML par ta feuille de style.

Finalement, la page ASP.NET (si je passe par un GetDir récursif) ne
recoit pas une string-XML mais un objet représentant l'arborescence
entière. D'un autre coté, j peux générer du XML au lieu de l'objet, ce
n'est pas un problème.

La serialization XML peut te simplifier la tâche.

Je vais voir ce que je peux faire avec une transformation XSL, je
connais pas.

C'est très intéressant et assez simple pour ton problème. Tu écris des
règles de substitution de ton xml en html. Tu as possibilité d'effectuer
quelques calculs et de faire des règles conditionnelles. Un petit exemple :
<xsl:template match="rep">
<a class="lienrep">
<xsl:attribute name="href">
<xsl:value-of select="concat('taPageFichiers.aspx?param=', @nomComplet)"
/>
</xsl:attribute>
<xsl:attribute name="target">frameFichiers</xsl:attribute>
<xsl:if test="normalize-space(@infobulle)!=''">
<xsl:attribute name="title">
<xsl:value-of select="@infobulle" />
</xsl:attribute>
</xsl:if>
<xsl:apply-templates />
</a>
</xsl:template>
Dans cet exemple, je suppose que tu as des balises 'rep', munies des
attributs 'nomComplet', 'nomAffiché' et 'infobulle' (qui peut-être vide),
cela se traduit par un lien hypertexte avec une classe CSS et éventuellement
un attribut 'title'. Remarque le calcul de l'url et la condition. Ton
fichier XSL est une succession de templates comme celui-ci. Un
<xsl:apply-templates /> judicieusement placé te permet appliquer d'autres
règles récursivement. Ici, il aura pour effet d'insérer le contenu de ton
élément rep.
J'aime assez travailler de cette façon. Ta structure de données devient
indépendante de son affichage et tu peux très facilement améliorer le rendu
en ne modifiant qu'un fichier, même pas besoin de recompiler l'application.

Fred wrote:

> Dans ce cas, quelquechose m'échappe, pourquoi un service web ?

J'arrive dans le projet qui est en cours. Choix de conception des boss.
Moi je suis stagiaire, j'essaie de faire ce qu'on me demande bien que
sur certains points, je ferai pas comme ça. Bref, là je fais les 2
manières : le récursif (trop-lent) et le non-récursif (rapide), ils
choisirons.

Et il y a un autre problème (qui ne se pose peut-être pas dans ton cas) :
que se passe-t-il en cas d'accès simultané de plusieurs utilisateurs ?

Au niveau des modifications ? Comme pour un OS... l'utilisateur A fait
un 'ls' dans le répertoire /tmp. Un utilisateur fait un 'mkdir mon_rep'
dans ce meme répertoire. Tant que A ne refera pas de 'ls', il ne risque
pas de voir 'mon_rep'. S'il souhaite créer ce même répertoire sans le
voir, il aura un message d'erreur. Pareil dans mon cas.

D'autre part, c'est un site pour administrer un 'environnement' donc il
est très peu probable que *pluieurs* personnes travaillent sur le même
document. Mes WebServices utilisent des plugins, je 'pense' qu'elles ont
été codées de manière à effectuer les modifications de manière
atomique... j'ai pu voir qq fonctions lock(), unlock()...

En fait, je voulais te suggérer le news scripting dans mon dernier post et
j'ai oublié. Là bas tu trouveras des pointures en javascript. Pour ce qui
est de l'exemple cité, cela se traduit par un événement onclick sur tes
objets du style :

> [..]

Mais, bon, si tu n'a plus de treeview cela perd de son intérêt.

Pas forcement. Au contraire, je peux utiliser ce système dans mon
File-DataList.

--
Delf