Reprise du message précédent :
ah oui je pense aussi que tu t'es trompé faut ouvrir avec FireFox...

Tout a fait gros lapsus    
 

Le xslt ça te permet de transformer un flux XML en "n'importe quoi"...
Si tu sais faire XML->HTML pas de raison que tu n'arrives pas a faire XML->XUL.
La seule chose c'est qu'il faut que tu apprenes la syntaxe XUL
 
 

bon déjà imaginons que j'ai fait une feuille XSLT, comment je fais pr l'associer au fichier xml (ou xul, je sais pas) pr qu'elle transforme l'xml en xul

ouais c'est ce que je fais la j'a ideux pages Firefox ouvertes : tuto xslt et tuto xul mais alr comment je fais pr voir si ma feuille marche???

apprends déjà a faire xml->quelque chose via xslt...
C'est la 1ere étape, si tu ne sais pas faire ça le xul te seras inutile!

ba ca va j'ai un bon tuto je vois comment faire à peu près mais je demandais juste un exemple au cas ou quelqu'un en aurait (ex XML->XUL via XSLT).
mais anapajari peut tu me répondre à la question d'avant, celle ou on imagine (je sais c'est dur) que j'ai un fichier xml une feuille xslt et comment j'associe tt ca pr en faire un xul.

tu as déjà la réponse à cette question ici:

mais no (je m'exprime mal ou quoi) j'ai deux fichier un fichier xml(1) et l'autre un fichier xslt(2)  comment je fais pr dire aux fichiers 2 detransformer le fichier 1 pr créer un fichier xul (3)..
 
 
je vais manger....

En lisant ce topic, ça me fait penser à la chanson "prendre un enfant par la main"...  
 
Franchement, t'as toutes les billes en mains maintenant. D'abord, tu dois connaître les spécs du XUL (->google). Ensuite, par rapport à ton flux xml (celui qui sort de l'appli serveur) tu dois réaliser une feuille XSL afin de transformer ton XML en XUL. Enfin, tu dois utiliser côté client un outil pour réaliser cette transformation XSLT
 
Par exemple, si c'était en php, voilà un exemple pour réaliser cette transfo xslt : http://www.php.net/manual/en/function.xslt-process.php
 
Tu peux aller voir sur le W3C : http://www.w3schools.com/xsl/default.asp
et ici aussi peut-être : http://www.xml.com/pub/at/16
 
Mais normalement, les navigateurs modernes (dont Firefox) sont capables d'effectuer des transfos XSLT via Javascript (par contre,,je me rappelle plsu le nom de l'objet qui fait ça) -> cf. google

allez Kdo

Mais ça sert à rien, a mon avis impossible de faire ta transformation coté client.
Voila ce qu'il devrait se passer:
- Demande de la "page de départ de l'appication" par FF
- Appli. Serveur retourne un flux xml
- FF l'interprete  
-dans le cul
 
Donc en mélangeant avec AJAX on pourrait obtenir ça:
- Demande d'une page HTML "ajaxienne"
- lancement d'un xmlhttprequest sur la "page de départ"
- Appli. Serveur retourne un flux xml
- Transfo xslt via js en XUL
- dans le cul ( tu peux pas balourder du XUL dans du HTML)
 
La seule solution que je vois:  Création d'un "moteur" coté serveur qui fait les transfos XML->XUL via XSLT
ça donnerai ça en gros
- Demande du moteur avec les paramètres par defaut dans FF
- Moteur "demande" la "page de départ"
- Appli. Serveur retourne un flux xml au moteur
- Moteur transforme xml en xul
- Retour du flux xul au navigateur...
Mais alors je peux absolument pas garantir que ça marche ... je connais pas assez bien xul pour savoir si on peut faire ça .
Et après ça risque d'être encore plus compliqué vu que tu as tous les traitements "clients" ( par exemple les actions sur les boutons) qui doivent être codées en js(like pour les puristes) et je vois mal comment tu vas faire(en fait il faudrait voir le flux xml de l'appli pour en savoir plus...)!!!
 
Mais c'est sympa comme sujet de stage, si tu trouves des solutions, pense à venir les poster ici!!!

C'est vrai qu'on a laissé un peu de côté l'aspect "gestion des actions de l'utilisatreur". L'activeX faisait que présenter l'ihm provenant du flux xml et envoyait au serveur les actions de l'utilisateur (clic sur un bouton,...) où il réalisait aussi des traitements?

je suis vraiment pas un pro du web tt ce que je sais c'est que quand on clique sur un bouton (qui est ds l'activeX) ca envoie un requete au serveur le serveur répond et ca affiche coté client ce qu'on veut

Apparemment, pour les événement, y'a XBL qui est fait pour ça quand on a une IHM en XUL : http://developer.mozilla.org/fr/docs/XBL

 
 
ben dans ce cas, ça serait pas plus simple de faire une petite page html qui affiche une applet et c'est l'applet qui s'occupe d'afficher le xml? En +, j'ai vu qu'on pouvait utiliser xul avec Java (http://developpeur.journaldunet.com/tutoriel/xml/030606xml_xul1.shtml)?

tiens, je viens de trouver google en xul : http://www.google.com/mozilla/google.xul
et ici, un bon tutoriel sur xul : http://www.xulplanet.com/tutorials/xultu/

Le "moteur" dont je parlais il est faisable en n'importe quoi ... Par contre ce que tu décris c'est deux solutions différentes:
- Développer une applet java qui effectue coté client ( dans un page html) le boulot que faisait l'activeX ( c'est exactement la même chose mais dans une autre techno)...
- Développer une moteur sur le serveur qui fait la transfo xml->xul et envoie le resultat à FF.
 

• Dans le 1er cas tu n'as pas besoin de xul, tu fais toujours en java(y compris l'ihm).
• Dans le 2eme cas ce n'est pas un applet.

tout à fait. Maintenant, faut voir ce qui est le plus rapide à mettre en place par rapport à l'existant... Je serais tenté de dire qu'une applet en Java, ça serait plus multi-PF/multi-navigateurs, non?

Bin je pense que c'est le sujet de son stage
Trouver la solution la plus adaptée ... Mais honnetement sans voir l'existant c'est impossible à dire!!!

re-d'accord avec toi...

lol ok et vous voulez quoi que je vous passe un bout de code....

pr revenir a ce que t'as dit anapajari "La seule solution que je vois:  Création d'un "moteur" coté serveur qui fait les transfos XML->XUL via XSLT
ça donnerai ça en gros
- Demande du moteur avec les paramètres par defaut dans FF
- Moteur "demande" la "page de départ"
- Appli. Serveur retourne un flux xml au moteur
- Moteur transforme xml en xul
- Retour du flux xul au navigateur... "
 
c'est quoi que t'appel "moteur"...

mais sinon pr revenir à l'applet java je pense que c'est pas la bonne solution car ca demanderait beaucoup trop de temps il faudrait presque refaire tt le code, xul permettrai d'utiliser le code déjà mis en place (l'xml) mais bon après le problème c'est le moteur...

Java a des lib permettant de manipuler le XML...

J'ai l'impression que tu pars d'un postulat TOTALEMENT FAUX!!!
C'est n'est pas parce que tu as déjà du XML qu'il est facile de tout changer en XUL!!!
Une exemple: tu prends un fichier openOffice, tu le décompresses, tu extrais un fichier xml, et bin avant que t'arrives à le "transformer" en xul, tu seras diplomé depuis de nombreuses années.
XUL est un langage basé sur XML permettant de décrire les éléments composant une interface utilisateur, c'est tout!

aaa ok mais c'est un problème ca mon stage dur que 2mois...lol
 
no plus sérieusement, je sais que ca serait long mais je dois juste faire un prototype pas transformer tt le programme...dc ca devrait aller mais je voulais juste savori c'est quoi que t'appelle "moteur"

un programme qui prends le XML de ta boite en entrée et qui ressort du XUL ( en utilisant des XSLTs ou pas d'ailleurs).
Tu dois pouvoir le programmer dans tous les langages du monde, à toi de voir celui qui est le plus interessant dans ton cas!

oserais-je demander lequel tu choisirais dans mon cas....(oui je suis très conformistes, mais plus que ca à la fin de ce stage et après l'obtention ou non de mon diplome je change de voie je vais apprendre le japonais c'est pr ca que je suis une quiche en informatique...)

On peut pas te repondre comme ca. .. faut voir lesquels tu connais deja, la geometrie exacte du probleme et les contraites que peuvent t'imposer tes chefs de stage (Exemple a la con : Tu fais ca en VB et apres ils te disent que c'est destiné a des plateformes unix)

+1
C'est tout a fait le problème. Mais en gros ton stage voila ce que tu dois faire:
[1] les méthodes possibles
... toutes les solutions qu'on a envisagé, leurs avantages leurs inconvénients
... celle que tu as choisi avec le pourquoi du comment
[2] la mise en place de la solution
... les solutions techniques possibles pour la méthode choisie
... laquelle est la plus adapté ( rapidité, facilité, support toussa toussa)
... laquelle est la moins chère ( en fonction de ce qui existe déjà dans la boite : serveur, compétence technique, ... )
 
Ensuite tu prends les deux dernières et tu fais un petit morceau(par exemple juste l'écran de login, ça suffit largement) pour faire une démo du rendu. Et zou tu en parles plus, fin du stage

c'est sûr que c'est pas en 2 mois avec un débutant que tu peux porter un progiciel tout entier. Perso, plus que l'ihm, il faudrait s'intéresser sur l'aspect communication entre l'activeX et le serveur (le genre de requêtes qui sont envoyées). Je connais peu XUL, mais de ce que j'ai pu en voir, c'est assez différent du fonctionnement d'un activeX alors qu'une applet Java s'en approche assez. En +, Java est très répendu, ça sera donc pas dur pour la boîte, une fois le protocole de portage spécifié, de trouver qq'un pour coder en Java une applet Alors que des développeurs XUL, doit pas y en avoir beaucoup aujourd'hui... Et pour la maintenance, Java me paraît plus simple. Mais ce n'est que mon avis...

aaa snif si c'était aussi simple je pourrai souffler seulement voilà à mon avis c'est plus dur que ca...je m'explique...
 
leur logiciel à l'air beaucoup trop compliqué pr moi le seul truc que je comprend c'est que y a un activex(pr moi un activex c'est un programme) qui intercepte un flux xml et va savoir comment il décrypte le flux et affiche l'ihm le problème c'est que je sais pas comment fonctionne l'activex et si je sais pas ca je vois pas comment je peux analyser les meilleures méthodes et solutions possibles à prendre et encore moins faire un prototype de solution...et question programmation technique chez eux c'est vachement pointu autant dire que moi j'suis dans un bac à sable du fait que je connais en programmation pas grand choses a part en java ou je peux faire: un JTextField jtMonTexte = new JTextField();

Bein tu leur demande ce que fait l'activeX si ca te sert a qqch

mais par exemple si je prend la solution ajax est ce que je peux récupérer un fichier xml qui m'affiche l'ihm??? et après pr les évènement c'est du javascript...
certes je pose mal ma question et ca dépend de l'existant vs allez me dire mais bon si quelqu'un me comprend...

s'ils ont bien développé ça en respectant le cycle en V, y'a forcément les spécs et le dossier de conception préliminaire et/ou détaillé. Avec ça, c'est bon, t'aura les infos. Tant que tu sauras aps ce que fait préciseemment l'activeX, je vois pas comment tu pourras répondre efficacement à leur question : vers quoi porter l'activeX...

le xml, c'est pas magique, ça n'affiche pas une ihm. Ca ne contient que des données au format texte, sous forme d'une arborescence de balises, ces balises étant porteuses d'une information sémentique. Faut donc décoder le flux xml, travailler sur son contenu et sortir le résultat désiré...
ex : un flux xml bidon

 
en sortie, tu veux un formulaire html

 
C'est bon, t'as compris?

ouais c'est bon j'ai compris, donc faut que je demande comment fonctionne l'activex après je verrais si c'est possible de faire leur truc avec soit ajax ou xul peut etre et sinon et bien y a pas de solution et je prie pr qu'il me donne quelques choses d'autres à faire qui soit plus à ma portée...

K, lol
 

C'est ce que j'essaye de lui expliquer depuis le début, mais ton explication est bien plus claire que la mienne.
Ce qu'on veut juste te dire boudoudou c'est à la limite l'activeX pourrait recevoir un flux texte ça changerait rien à ton problème. Le xml c'est juste une façon de formatter les données qui "rentrent".
 
Es-tu déjà complètement sur de l'architecture de l'existant?
Moi de ce que j'ai compris tu as ça:

 
Quand à XUL et Java (de ce que j'en ai regardé) c'est totalement différent, je rapprocherais plus XUL que Qt que de java...  
 
 

Mais attends ... si tu as le DTD du flux xml en entrée et tu sais quelle forme il doit avoir en sortie, tu t'en fous de ce que font les autre, tu le roule avec un xslt et on en parle plus

 
ça, oui, mais c'est uniquement pour la partie ihm. Après, faut voir la partie traitement/communication avec le serveur. Et là, le xul, il sert à rien.

 
 
moi, je pense pas que l'activeX génère du HTML. quel serait l'intérêt d'un activeX, si c'est pour avoir en sortie du html? Autant avoir le html directement. Je pense que l'activeX a du être codé en C++/MFC (ou pire, en VB) et qu'il a la même apparence qu'une appli windows classique (et pense aux boutons, listes déroulantes et autres contrôles) et qu'il dialogue en direct avec le serveur, ce qui évite d'avoir à recharger la page à chaque action de l'utilisateur. Simplement, l'affichage des contrôles n'est pas été prédéfini lors de la compilation de l'activeX mais qu'il se fait en live grâce au décodage du flux xml provenant du serveur. Voilà pourquoi je pense qu'il vaudrait mieux savoir ce qui se passe quand on clique sur un contrôle de cet activeX (quel genre de requête est envoyée au serveur) plutôt que de savoir comment on va recréer l'ihm. Si le mode de communication avec le serveur est "complexe", du javascript ne suffira pas alors que du java, si...

Effectivement cela parait plus logique qu'il n'y ait pas d'html mais ce n'était que des supputations!!!
 

Bin a mon avis l'activeX renvoie une flux XML au serveur, en reprenant ton exemple, si la valeur a été modifiée il renvoie:

Le mode de communication entre le serveur et l'activeX n'a pas de raison d'être plus complèxe que des echanges de flux XML, du coup du js a grand coup de DOM peut-être suffisant.
 
Bon Roudoudou plutot que de nous laisser partir dans des suppositions bancales, si tu demandais clairement à ton maître de stage ce que fait son bouzin!!!