Rendre les url des applis plus simples

[bchartier]

Il serait intéressant de ne pas avoir à mettre dans l'url une option du type ?config=apps/myapp.xml.
Une solution pourrait être d'avoir un fichier html minimaliste par application. Ce fichier contiendrait le code javascript qui doit charger mviewer.js et le fichier xml spécifique de l'application.

[bchartier]

De mon point de vue, il serait utile que chaque application fasse l'objet d'un fichier .html plutôt que d'utiliser un même fichier index.html pour toutes les applications et d'utiliser un paramètre pour identifier le fichier de config.

En effet, cela permettrait :

• de simplifier les URL des applications (ne plus avoir de paramètres)
• de faciliter le travail des moteurs de recherche type Google, Bing, Yandex... pour référencer les différentes applications
• accessoirement de personnaliser les champs meta de chaque application
• éventuellement de permettre d'intégrer l'application dans une mise en page et du contenu HTML sans avoir à utiliser d'iframe par exemple

[bchartier]

Autre proposition que nous comptons appliquer pour datasud :
exploiter des URL de la forme suivante :
mviewer/#blabla/macarte
Concrètement :

1. si on détecte un # suivi de quelque chose on charge le fichier de config apps/blabla/carte.xml
2. si on détecte le paramètre ?config= on charge le fichier de config ainsi pointé
3. sinon on charge le fichier config.xml à la racine

Cela ne casse pas le fonctionnement actuel avec ?config=. Donc les applis actuellement déployées devraient continuer à fonctionner normalement.

Le répertoire apps à la racine pourra être un lien symbolique vers un autre répertoire.
Cela nous permettra d'avoir des URL plus propres et plus courtes.

Si ce mode de fonctionnement assez simple à mettre en place vous convient, on pourra aussi le mettre à l'œuvre dans la fonction de prévisualisation du studio.

[bchartier]

Pour illustrer mon propos :

• ce qui a été fait dans mviewer pour exploiter ce genre d'URL :
  neogeo-technologies@d9d22ca
  (j'ai intervertis les étapes 1 et 2 de mon commentaire précédent)
• dans mviewerstudio :
  neogeo-technologies/mviewerstudio@c0c1caa

Si j'ai un retour positif de la communauté, je pousse cela dans un pull request.

[spelhate]

Je trouve que c'est une très bonne idée. Qui plus est sans gérer des redirections côté serveur.

Si j'ai bien compris,

• mviewer/#blabla/macarte charge l'application apps/blabla/macarte.xml
• Et si je fait mviewer/#blabla/ c'est apps/blabla/config.xml qui se charge ? Ce serait vraiment top.
• Comportement inchangé avec ?config=

[bchartier]

Je trouve que c'est une très bonne idée. Qui plus est sans gérer des redirections côté serveur.
Si j'ai bien compris,

• mviewer/#blabla/macarte charge l'application apps/blabla/macarte.xml

Oui.
mviewer/#blabla/macarte.xml et mviewer/?config=blabla/macarte.xml donnent exactement le même résultat.

• Et si je fait mviewer/#blabla/ c'est apps/blabla/config.xml qui se charge ? Ce serait vraiment top.

Arg, j'avais pas prévu ça.
Pour config.xml, ce que j'avais prévu c'est de laisser le comportement actuel :
.../mviewer/ -> chargement de config.xml (celui de la racine de mviewer
Faudrait voir dans un second temps je pense.

• Comportement inchangé avec ?config=
  Oui

Ça te va quand-même ?

[bchartier]

Proposé dans le pull request #105

[spelhate]

Merged

[bchartier]

Je me rends compte que cette évolution a des effets de bords non souhaitables :

• lorsque qu'un href de type "#" est actionné on perd le contenu du fragment qui pointe vers la carte
• le lien de partage de la carte utilise des paramètres standard de l'url sans reprendre le chemin de la carte

[spelhate]

Oui mais si j'ai bien compris le principe, le fragment qui pointe vers la carte est simplement utilisé à l'initialisation. Après il n'a plus d'utilité non ?
Docn si on actionne un href de type #, c'est en principe sans conséquence pour l'application.
Sauf pour la génération du permalien peut-être ?

[bchartier]

Effectivement, dans le code que j'ai modifié c'est uniquement utilisé à l'initialisation.
Maintenant d'autres fonctions exploitent l'adresse courante ou la modifient.
La génération du permalien par exemple devient bancale.
Un href # ne nuit pas à la manipulation de l'application sauf si quand on fait un copier/coller ou quand on veut créer un permalien. Il faudrait regarder cela de plus près.

[bchartier]

Je vais regarder s'il vaut mieux créer une variable pour stocker le chemin du fichier de config afin de pouvoir le réintégrer proprement dans les permaliens ou s'il faut adapter les fonctions qui modifient le fragment courant.

[spelhate]

@bchartier Faut-il garder ce ticket ouvert ?

[bchartier]

je ferme