sdx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [sdx-users] qid multi-session


From: Emmanuel Bégué
Subject: RE: [sdx-users] qid multi-session
Date: Thu, 2 Oct 2003 04:26:40 +0200

> -----Message d'origine-----
> De : address@hidden
> De la part de Frédéric Glorieux
> Envoyé : mercredi 1 octobre 2003 23:28


>  > L'utilisateur anonyme n'a pas de dossier, ça ne me semble pas un
>  > problème: s'il veut un dossier il se crée.
>
> Très bien, ce qui devient donc distinct du procédé actuel de cache de
> résultat sur la session (en sachant que la session est différente pour
> chaque fenêtre de navigateur).
>
> Donc on peut attacher cela à la fiche de l'utilisateur ?

Oui, à mon avis ça serait l'idéal.


> Reste à savoir maintenant s'il importe de stocker
>   - une requête
>   - des résultats
>   - des liens vers des documents
>
> On peut utiliser la base utilisateur SDX par défaut, mais votre idée
> d'aller écrire dans un fichier XML est probablement meilleure (ce qui
> n'empêche pas d'indexer ce fichier ensuite dans votre base utilisateur
> personalisée).

Il me semble qu'à partir du moment où l'identifiant est unique dans
la base, et le nom de la base unique pour l'application, si on stocke
l'identifiant, le nom de la base et le nom de l'application (même pas,
puisque l'utilisateur est relatif à l'application) on a toutes
les infos nécessaires? Comme de toutes façons c'est lié à l'application
SDX, on n'a pas besoin de stocker des choses qui pourraient lui survivre,
au cas où l'application et/ou la base venaient à disparaître.


>  > Justement, ne serait-il pas intéressant de disposer d'un endroit
>  > où les utilisateurs SDX pourraient échanger du code -- du code xsl
>  > en particulier (en plus de cette liste)?
>
> > J'ai par exemple écrit deux petites fonctions xsl qui sont assez
> > génériques, l'une pour afficher l'historique de la recherche,
>
> ?? Une analyse de <sdx:query/> ?

Oui mais très simple: je prends toutes les occurrences de "text" et
je les restitue de façon unique: c'est assez basique mais ça marche
(par rapport à mes besoins en tout cas).


> > les idées de chacun sont toujours "inspirantes") -- sans compter que
> > ça permet d'éviter de réinventer la roue tous les matins ;-)
>
> J'avais essayé un moment de maintenir une très générique sdx2html.xsl
> (sort le xml sdx dans un html à peu près standard avec des classes CSS
> personalisables). Je ne sais pas si beaucoup ont aprécié s'y plongé. En
> effet, il vaudrait mieux procéder par "snippets" répondant rapidement à
> une question au moment où on se la pose.

En fait je peux essayer de monter qqch dans ce sens (et l'héberger) s'il
y a un intérêt? (et que ça n'existe pas ailleurs sous une autre forme?)


> C'est en ce sens que je me demande si dans l'esprit W3C, on n'a pas
> intérêt à concevoir ses applications de telle manière que l'URI ait
> réellement une valeur absolue. Exemple, réagir en sitemap à des URL du
> genre /app/base/docId.(xml|html|rdf...)

Ah oui ça serait vraiment très bien! (mais en attendant que SDX réagisse
à ces urls, on peut commencer par les stocker telles quelles?)


> De cette manière, l'utilisateur a des URIs dans ses favoris, il peut
> citer ces URIs dans ses pages, et s'il on veut offrir un service
> serveur, on garde mémoire des URIs de documents consultés, voire, mais
> pour ma compréhension, il me faudrait un cas, des listes de résultats.

Je ne sais pas si l'utilisateur doit accéder en direct à ce qui est
stocké, mais pourquoi pas en effet?


> > Oui, je ne sais pas: l'intérêt du stockage sur le serveur c'est que
> > l'utilisateur retrouve son dossier intact quelle que soit la machine
> > avec laquelle il se connecte...
>
> Quand on se souvient de son mot de passe, c'est en effet très agréable.

En fait si on veut une vraie gestion des utilisateurs il faudrait pouvoir
mettre en place des fonctions basiques du genre: gestion d'une
question/réponse
(ce qui est peut-être déjà possible en l'état, d'ailleurs?)

Cdt,
EB





reply via email to

[Prev in Thread] Current Thread [Next in Thread]