Interface Windows Mobile (pocketPC)

Hello !

Petite question, il me semble que nos appli XMLRAD sont capables de gérer différents mode "d'affichage" selon le type de client. Si je veux qu'une partie de mon appli soit utilisable depuis un palm (windows mobile, IE Mobile), qu'elle est la solution prévue ? J'imagine qu'il faut jouer avec Devices.xml et le XMLC_Formatter, etc. ... (d'ailleurs c'est bien dommage que celui-ci ne soit pas dans les xmlc_params!)
Dans les grandes lignes, un petit how to sur les "bonnes pratiques" et les "choses à savoir" (support du javascript, css, etc..) ?

Michael

Tout à fait, devices.xml et XMLC_Formatter sont prévu pour.

En 2 briques (toudoudoudoudouuuu) :

XMLC_Formatter : champ du Context utilisé pour switcher dynamiquement le document XSL utilisé pour la transformation.

J'ai par exemple le service ListORGANIZATION avec le fichier ListORGANIZATION.xsl et j'ai mis dans le Context XMLC_Formatter=PDA.

Apres l'execution du XMLGram, l'application verifie si Context.XMLC_Formatter <> ''. si oui, elle change l'extension du fichier XSL pour obtenir ListORGANIZATION.PDA.xsl et regarde si elle trouve le fichier sur disque. Si elle le trouve, elle utilise ce fichier là, sinon, elle utilise le fichier par défaut.

Pareil pour les locales, où on va chercher un fichier ListORGANIZATION.PDA.Locales.xml. Si pas trouvé, on prend celui par défaut.

Cette technique est utilisé pour changer l'interface utilisateur, sans changer le backend (XMLGram, Code, etc...). Typiquement pour les PDA, Smartphone, ou encore pour un export CSV, par exemple...

Devices.xml : etablit un mapping entre un UserAgent et un XMLC_Formatter.
Si un navigateur se présente avec un user agent reconnu, l'application va mettre dans le Context le XMLC_Formatter correspondant.

Dans la version courante du Framework, du Pattern Matching est utilisable en plus (si 'iPhone' est trouvé dans le User Agent, mettre dans Context XMLC_Formatter=PDA). Dans les versions plus anciennes, il faut spécifier chaque UserAgent manuellement (pas très pratique).
On peut trouver un UserAgent facilement avec le XMLService XMLC_GetUserAgent.

Recommendation pour les PDA :
le plus gros problème qu'on rencontre avec les PDA n'est pas le débit, mais plutot la latence : une fois la connection établie, ca roule, mais cet établissement prend beaucoup de temps. Pour une interface qui booste, il faut absolument eviter de faire des requetes HTTP, donc :

• le moins d'image possible : utiliser un image strip (= CSS Sprite) pour concatener les images en une seule, avec du CSS pour afficher celle qu'on veut
• fichiers JS et CSS minimisés, concaténés
• contenu GZIP (automatique avec XMLRAD)

Sinon, l'iPhone dispose d'un navigateur incroyable. Les autres PDA sont à la ramasse (peu ou pas de CSS, peu ou pas de JS).

Merci Nicolas pour cette eclairecisement,
dans mon cas de figure j'ai la meme application pour 2 sociétés societe1 et societe2 dans 2 répertoires IIS virtuels: societe1bin et societe2bin avec les memes fichier .xmlgram et .xsl.
L'ennui c'est que par exemple la société1 veut sur certain écran des champs en plus ou en moins.
Est-ce que je peux gérer cela en utilisant dans l'INITPARAMS XMLC_Formater=societe1 pour la sociéte1 par exemple?

Est-ce que cela ne risque pas de poser des problèmes si par la suite les sociétés 1 et 2 veulent gérer des PDA (ou autres) ?

Merci pour cette réponse claire, et rapide! ;)

Pour ton problème, powerlog, je ne suis pas sur que le Formatter y réponde. L'objectif est de ne pas toucher au backend, or si tu rajoutes des champs, celui-ci doit en tenir compte et même si c'est possible, ca complique (un peu) la chose et surtout ca détourne l'usagé prévu.
J'ai une appli qui répond à ce besoin, chaque écran peut etre différent d'un utilisateur à l'autre, et surtout d'un client à l'autre (champs, droits, préférences, ....)... Il faut pour cela rajouter une "couche" et mettre dans la "partie backend" une description de l'écran (sans que celle-ci ne soit induite par le XSL, mais au contraite que ton document xsl affiche un champ ou un autre en fonction que ce qu'il voit arriver comme données). Enfin en tout cas c'est mon point de vue ;)

Michael

Michael, comment as-tu gérer la chose?
+une base de données pour gérer les champs de tous les écrans avec les droits de visu, maj du champ par utilisateurs/ groupes utilisateurs?
+dans le xsl: un test pour définir soit -pas d'affichage, -un affichage visu, -un affichage de maj pour le champ?

Est-ce que cette "couche" supplémentaire n'est pas trop gourmande en tps?

La technique de Michael est la bonne, surtout "ton document xsl affiche un champ ou un autre en fonction que ce qu'il voit arriver comme données", j'adore :)
Et donc non, XMLC_Formatter n'est pas la solution pour ca.

C'est exactement la philosophie XSL, qui ne permet qu'une transformation du document XML, dirigée par le contenu meme du document.

Rapidement, et sans aller trop avant dans cette technique (la meilleure, mais pas la plus simple), je pense qu'un simple document XML supplémentaire décrivant les champs à afficher pourrait suffire dans ton cas.

Tu importes ce document (instruction File dans ton XMLGram) et le XSL s'appuie sur ces nouvelles données pour modifier l'affichage.
Il te reste le problème du backend, qui doit construire les requetes SQL fonction de ces nouveaux champs, mais là aussi, le document XML permet de créer ca.

Effectivement, une instruction file va chercher la bonne "description" de mon écran (un peu sur le principe des Profiles.xml). Ensuite pour poster les données, il y a un peu plus de gymnastique à faire, comme le dit Nicolas. Il faut qu'a son tour, le backend réagisse en fonctionne des données qu'il voit venir ( et la boucle est bouclée! lol! )
Michael

Merci pour les réponses.
Je vois que j'ai encore du pain sur la planche...



"Joyeuses Pâques à toutes et tous"