Re: [sdx-developers] Interface d'administration

[Frédéric Glorieux]

| Frédéric Glorieux a écrit:
|
| >     Pour ma part je vois la question ainsi
| >
| > - sdx/ , un accueil avec la liste d'applications, sans boutons
| > d'administration
|
| Oui.
|
| > - sdx/sdx/admin/, on montre la liste des applications avec boutons
| > d'administration
|
| Note en passant : pourquoi un deuxième sdx ?

C'est vrai, c'est lourd, mais si un original voulait faire une appli qui
s'appelle admin ? Le premier sdx peut être appelé de n'importe quel autre
nom (nous avons sur nos serveurs des sdx-new, sdx-old, sdx-fred), selon le
nom que l'on donne au war (ou le répertoire enfant de webapps). Le dexième
est un nom réservé, une sorte d'application système entièrement contenue
dans un répertoire. Elle peut être supprimée, laissant les autres
applications fonctionner (sauf qu'il n'y a plus d'admin, d'api-url, et de
resources partagées).

- à ce propos sur le dernier CVS il y a eu une sévère réorganisation de
cette partie. Etant donné que l'import d'xsl ne peut pas être fait à travers
WEB-INF, on rangera quelques outils bien agréables, des templates
importables pour les tags SDX (navigation page par page, termes), des css
génériques, du javascript pratique...

 Ceci rejoint ton cas

| Oui... mais : qu'est ce que l'administration d'une appli ? Dans mon
| appli sribzh, sous SDX 1, cette partie est complètement encapsulée dans
| le code de l'appli elle-même. En gros, c'est l'appli qui s'administre
| elle-même :-)

C'est certainement le mieux, mais ne peut probablement s'exiger de tout le
monde.

| Certes, on peut revenir à l'interface administrative pour vider la base
| ou faire un backup, mais, idéalement, j'aurais préféré squizzer cette
| possibilité.

Tu n'aurais alors qu'à copier le code commun pour toi.

| > et un bouton pour le serveur.
|
| Oui.
|
| > Il est exclus de
| > s'identifier ici, sinon comment expliquer que l'on peut être su, ou
| > administrateur de telle appli ?
|
| OK.
|
| > Je pense que l'identité sous laquelle on est
| > enregistré est moins importante que ce à quoi l'on accède.
|
| Mmmh. Je penche plutôt pour l'inverse... selon moi, le comportement
| normal de SDX, c'est de rechercher/afficher des documents dans un
| contexte toatalement anonyme. Si on veut faire plus, il faut montrer
| patte blanche.

Tout à fait d'accord, mais je veux dire que la question essentielle n'est
pas "qui je suis", mais "qu'est-ce que peux faire" (philosophique non?
Préférer l'existence à l'essence...). En conséquence, l'utilisateur peut
garder une idée confuse de ses droits, pourvu qu'il voit les bonnes
barrières au bon moment, et des boutons qui s'ouvrent (comme tes conseils
précédents, scrupuleusement suivis).

| > pour lisibilité on pourrait ouvrir l'administration d'une appli selon
les
| > les urls suivantes (plutôt que par paramètres du genre
| > login.xsp?app=fr.gouv.culture.sdx.sdxworld)
| >
| > - sdx/sdx/admin/fr.gouv.culture.sdx.sdxworld/
| >      login.xsp | identities.xsp | bases.xsp
| > La tâche d'un administrateur d'application est d'administrer les
identités
| > (utilisateurs et groupes), ainsi que les bases (réindexer, vider...).

| Le parti me semble très intéressant.


Le sitemap permet de le faire facilement, mais il faut bien réfléchir à
l'url que l'on veut. Choisir l'identifiant développé ? Mais on empêche alors
les espaces et les caractères chinois. Prendre le nom de répertoire ? Mais
est-ce que cela n'ajouterais pas de la confusion. L'idée est proposée, elle
attende des lumières.

| > - sdx/sdx/admin/sdx-server/
| >      login.xsp | apps.xsp | su.xsp
| > Le travail essentiel du su est d'ouvrir ou fermer des applications, et
| > accessoirement, dépanner l'administration des utilisateurs
d'applications en
| > cas de mots de passe perdus (d'où le droit de su d'accéder à l'admin
d'une
| > appli).
|
| Celui-ci aussi.
|
| Note : je trouve d'ailleurs qu'ils ressemblent à ceux que j'avais
| proposés :-)

Que j'ai lu après avoir écrit...

| > A l'installation, (mais n'oublions que cela n'arrive qu'une fois), il
faut
| > créer un su. Il est à supposer qu'on ne s'installe pas cocoon ou sdx
| > uniquement pour s'amuser. C'est plus un outil de travail qu'un appli
| > Wysywig. Pour un futur développeur XSL, on peut attendre quelques
tolérances
| > sur l'ergonomie (ce qui n'empêche pas d'expliquer plus).
|
| Sur le principe on est d'accord mais n'oublions pas qu'avant de
| développer, il faut évaluer. Quand je charge un war, je m'attends à ce
| que l'appli tourne. Et, comme beaucoup d'autres, je ne lis la doc
| qu'après avoir déployé le war. C'est pas bien, mais c'est comme ça...

Juste, c'est une vitrine publicitaire. Donc sorti de l'écran initial du war
(définition du SU), où renvoyer ? Il y aurait peut-être avantage à glisser
la doc directement dans le war (supprimable sans inconvénient). On aurait
ainsi de la page de texte à donner à l'évaluateur. Autre chose, en rédigeant
je verrais de l'avantage à étoffer d'exemples en contexte (testable
directement sur sdxworld). Pour version 4, il y a de quoi faire un tutoriel
en ligne.