Get notified on changes related to a topic

benel commented 5 years ago

Description

A given user, interested in a topic, could register to a topic in order to be notified whenever a new item is described by this topic or one of this children.

What is the valuable outcome that cannot be achieved with current features?

For which stakeholder (people, role, project, domain) is it important?

Suggested by @heliacerbonne for the open-access project.

Which user action should be enabled (or restricted)? For who?

Additional details (solutions you think about, or workarounds you tried)

Deliverables status

Phase 1

[x] Scenarios (Gherkin)
[ ] Mockups
[ ] Implementation strategy

Phase 2

[ ] Acceptance tests (Capybara)
[ ] Implementation

Phase 3

[ ] Screencast

garnier5 commented 4 years ago

For "studies abroad" project, it would be interesting to be informed at the end of each semester when new courses have been add to a topic (by school, or by spacialization), especially by e-mail.

Gaetanherry commented 4 years ago

Cela peut être utile pour les retours d'expérience pour ne rien rater sur un topic donné

YaellePihan commented 3 years ago

Cela peut être utile pour les retours d'expérience pour ne rien rater sur un topic donné

Besoin identique

benel commented 3 years ago

Besoin identique

@YaellePihan @Hypertopic/cite-du-vitrail Pourriez-vous expliciter une situation concrète dans votre domaine ? Qui ? À propos de quoi ? Pourquoi ?

paasshme commented 3 years ago

Pour le groupe "EUT+" nous pensons qu'il serait intéressant de suivre des formations (exemple ISI, RT, ou autre à l'étranger) ou des domaines (informatique,...) de cette manière il pourrait on pourrait voir les ajouts de matières ou les modifications dans une formation/un domaine qui nous intéresse.

YaellePihan commented 3 years ago

Projet Cité du vitrail (Orienté communication) : Nous pensons que ce ticket permettant de s’inscrire à un thème ou sous-thème de Porphyry serait intéressant pour tous les utilisateurs à la recherche de vitraux sur des thèmes spécifiques. Ils pourraient ainsi être notifiés de l’ajout de vitraux dans le portfolio.

benel commented 3 years ago

Nous pensons que ce ticket permettant de s’inscrire à un thème ou sous-thème de Porphyry serait intéressant pour tous les utilisateurs à la recherche de vitraux sur des thèmes spécifiques. Ils pourraient ainsi être notifiés de l’ajout de vitraux dans le portfolio.

@YaellePihan @Hypertopic/cite-du-vitrail Effectivement... Pourquoi pas... D'ici la prochaine semaine, pour votre maquette, il faudra que vous réfléchissiez à un exemple de sujet qui pourrait de manière réaliste intéresser les gens qui suivent la Cité du vitrail sur les réseaux (inspirez-vous peut-être de leurs commentaires sur Facebook ou Instagram... mais j'ai l'impression qu'ils sont assez timides et discrets...).

lildelfino commented 3 years ago

Pour "graine d'artiste" cela permettrait aux "spectateurs" d'être notifié que lorsque le sujet de l'oeuvre les intéressent.

benel commented 3 years ago

Pour "graine d'artiste" cela permettrait aux "spectateurs" d'être notifié que lorsque le sujet de l'oeuvre les intéressent.

@lildelfino @Hypertopic/graines-d-artistes-1 D'accord. N'oubliez pas de trouver un exemple (plus l'exemple sera bien choisi et plus votre fonctionnalité aura des chances d'être bien classée).

theobour commented 3 years ago

Maquette Adobe XD

Avec @cedfre, nous avons réalisé une proposition pour le design de cette fonctionnalité. Tout d'abord un écran sur lequel se trouve un bouton "s'abonner" à côté du topic :

171291607_1110325306100502_4225035683500703296_n

Après le clique, le bouton se changer en "se désabonner" : 171197652_180524890457289_4673081951926669795_n

Le dernier écran est celui avec l'ensemble des topic auquel l'utilisateur est abonné :

171586479_469943914224565_6007318464234799716_n

paasshme commented 3 years ago

Avec @Anas9820 nous avons réalisé une proposition pour le design de cette fonctionnalité. Tout d'abord un écran sur avec un bouton "s'abonner" sur le topic:

Web 1920 – 1

Une fois abonné, le bouton devient gris, et on peut se désabonner en cliquant dessus

Web 1920 – 2

Dans ce cas là, une pop-up s'ouvre, si l'on clique sur "Oui", on se désabonne (et on revient donc à l'état de la première image) et sinon on reste abonné (et on revient à l'état de la seconde image).

Web 1920 – 3

paasshme commented 3 years ago

@cedfre @theobour @Anas9820 @PSalembier @benel On a quelque chose de similaire, nous n'avions pas du tout pensé à la liste d'abonnements, je pense que c'est une très bonne idée ! Qu'en pensez-vous pour la version finale ?

benel commented 3 years ago

@theobour @cedfre @JacquesMironneau @Anas9820

Votre option d'abonnement est positionnée dans les maquettes de vos deux binômes à côté de l'élément graphique correspondant au corpus. Du coup, comment choisissez-vous la catégorie ( topic en anglais) dont parle la fonctionnalité ?

@JacquesMironneau @Anas9820

Est-ce volontaire de votre part que le nom du corpus soit le même que celui d'une des catégories ?
Est-ce volontaire de votre part que le point de vue (unique) porte le nom de "topics" ? Est-ce que ça ne prête pas à confusion ?

cedfre commented 3 years ago

@cedfre @theobour @Anas9820 @PSalembier @benel On a quelque chose de similaire, nous n'avions pas du tout pensé à la liste d'abonnements, je pense que c'est une très bonne idée ! Qu'en pensez-vous pour la version finale ?

Oui c'est assez similaire ! Je pense qu'on peut combiner nos deux maquettes en garder l'idée de la popup que vous avez tout en gardant la liste d'abonnements.

benel commented 3 years ago

@theobour @cedfre @JacquesMironneau @Anas9820

Dans la discussion d'une des équipes projets, nous avons parlé ensemble de l'intérêt que pourrait avoir l'abonnement à une requête plutôt qu'à un thème... Ça pourrait être intéressant d'y réfléchir comme d'une "négociation" possible.

benel commented 3 years ago

@theobour @cedfre @JacquesMironneau @Anas9820

Avez-vous fait une petite recherche sur la manière dont les flux RSS ou Atom sont intégrés (visuellement) aux navigateurs ou plus artisanalement dans les pages Web ?

paasshme commented 3 years ago

Du coup, comment choisissez-vous la catégorie ( topic en anglais) dont parle la fonctionnalité ?

Dans notre idée, le panel de gauche permettait de sélectionner une formation, et les détails (les UE) seraient affichés sur le panneau de droite.

Est-ce volontaire de votre part que le nom du corpus soit le même que celui d'une des catégories ?

Oui, cela l'était en prenant en compte notre choix expliqué ci-dessus.

Est-ce volontaire de votre part que le point de vue (unique) porte le nom de "topics" ? Est-ce que ça ne prête pas à confusion ?

Nous sommes d'accord, nous allons le changer.

nous avons parlé ensemble de l'intérêt que pourrait avoir l'abonnement à une requête plutôt qu'à un thème.

Qu'entendez vous par requête ? Est-ce une catégorie ? Comment voyez-vous le fait de s'abonner à une catégorie ?

Avez-vous fait une petite recherche sur la manière dont les flux RSS ou Atom sont intégrés (visuellement) aux navigateurs ou plus artisanalement dans les pages Web ?

Pas encore, nous allons regarder.

benel commented 3 years ago

Dans notre idée, le panel de gauche permettait de sélectionner une formation, et les détails (les UE) seraient affichés sur le panneau de droite.

Vous devez absolument vous fondre dans l'interface existante. La sélection d'une catégorie entraîne une mise à jour du panneau de sélection et non du panneau du corpus.

benel commented 3 years ago

Vous devez absolument vous fondre dans l'interface existante. La sélection d'une catégorie entraîne une mise à jour du panneau de sélection et non du panneau du corpus.

Je pense que ces problèmes de repérage des zones de l'interface viennent du fait que dans votre preuve de concept il n'y a encore aucun exemple complet...

benel commented 3 years ago

En attendant d'avoir une preuve de concept utilisable, prenez celle de l'an dernier comme exemple : https://abroad.porphyry.org

Sélectionnez la catégorie "Jonköping University" et repérez où elle est affichée.

theobour commented 3 years ago

En attendant d'avoir une preuve de concept utilisable, prenez celle de l'an dernier comme exemple : https://abroad.porphyry.org

Sélectionnez la catégorie "Université de Jonköping" et repérez où elle est affichée.

C'est de cette façon aussi que nous avons imaginé le fonctionnement : l'utilisateur clique sur la gauche sur une catégorie -> elle s'affiche sur l'élément centrale -> il peut cliquer sur le bouton "s'abonner"

Pensez-vous que déplacer ce bouton "s'abonner" à côté de chaque formation dans le corpus est plus pertinent ?

benel commented 3 years ago

Pensez-vous que déplacer ce bouton "s'abonner" à côté de chaque formation dans le corpus est plus pertinent ?

Notez bien que le logiciel est générique mais que votre usage est spécifique. Si vous ajoutez un bouton ce n'est pas pour chaque "formation", mais pour chaque "catégorie".

Donc essayez de trouver une manière générique de vous abonner dans ce cas spécifique à la catégorie "Jonköping University".

benel commented 3 years ago

nous avons parlé ensemble de l'intérêt que pourrait avoir l'abonnement à une requête plutôt qu'à un thème.

Qu'entendez vous par requête ? Est-ce une catégorie ? Comment voyez-vous le fait de s'abonner à une catégorie ?

La requête c'est aussi ce que j'ai appelé "sélection". C'est ce qui est tout en haut au centre. Ça correspond au titre de la page, ce que l'on est en train de voir.

Dans le cas de la copie d'écran ci-dessus c'est une sélection d'une seule catégorie. Mais le cas est plus général puisqu'on peut combiner plusieurs catégories (ou attributs) avec des opérateur logiques.

paasshme commented 3 years ago

D'accord merci cela est plus clair.

Nous avons donc pensé que à chaque catégorie sélectionnée, nous pourrions ajouter un bouton "s'abonner" dans le corpus. Exemple: Si on sélectionne Polytech Mons: un seul bouton "s'abonner" apparaîtra dans le corpus Si on sélectionne 2 catégories, 2 boutons apparaitrons dans le corpus.

benel commented 3 years ago

Pensez-vous que déplacer ce bouton "s'abonner" à côté de chaque formation dans le corpus est plus pertinent ?

Ce qui m'étonne c'est que vous avez placé le bouton à côté des corpus. Dans ma copie d'écran ce serait à côté de "Abroad_courses UTT_courses". Du coup, il est très peu probable que cela permette de s'abonner à "Jonköping university".

benel commented 3 years ago

Si on sélectionne 2 catégories, 2 boutons apparaitrons dans le corpus.

Désolé, je ne comprends toujours pas le placement de votre bouton... Vous allez être obligé d'afficher "Jonköping unicersity" une troisième fois dans une troisième zone alors qu'elle est déjà présente à deux endroits dans l'écran ?

paasshme commented 3 years ago

Nous pensions sinon à le mettre dans la partie catégorie à côté de chaque nom de catégorie, qu'en pensez vous ?

benel commented 3 years ago

benel commented 3 years ago

Nous pensions sinon à le mettre dans la partie catégorie à côté de chaque nom de catégorie, qu'en pensez vous ?

Je ne vois effectivement que deux endroits pour mettre un tel "bouton" :

soit à côté de la requête mais du coup, la fonctionnalité change un peu (mais peut-être pour un mieux),
soit à côté de chaque catégorie (mais comme la surcharge est complètement incompatible avec l'approche content-first il va falloir trouver une astuce).

benel commented 3 years ago

Nous pensions sinon à le mettre dans la partie catégorie à côté de chaque nom de catégorie, qu'en pensez vous ?

Dernière possibilité, si l'abonnement est par rapport à une requête et donc à la page affichée... renseignez-vous sur la manière standard avec RSS ou Atom de s'abonner à une page.

paasshme commented 3 years ago

Voici notre maquette finale, en prenant en compte vos modifications: @benel

Premièrement, on sélectionne les topics qui nous intéresse:

Web 1920 – 5

Un bouton "s'abonner" apparait près de la requête

Web 1920 – 1

Si l'on clique, on s'abonne à cette page

Web 1920 – 2

On peut choisir d'annuler son abonnement en cliquant sur ce même bouton

Web 1920 – 4

PSalembier commented 3 years ago

Pas mal du tout . Juste un détail : on peut reprendre les attributs graphiques (couleur) des topics sélectionnés dans la colonne de gauche et les utiliser pour la liste qui apparait dans le bandeau (à côté de la commande « s’abonner » ).

Le 9 avr. 2021 à 11:56, Jacques Mironneau @.***> a écrit :

Voici notre maquette finale, en prenant en compte vos modifications: @benel https://github.com/benel Premièrement, on sélectionne les topics qui nous intéresse:

https://user-images.githubusercontent.com/34798699/114163191-3150ff00-992a-11eb-88c7-c124853a6697.png Un bouton "s'abonner" apparait près de la requête

https://user-images.githubusercontent.com/34798699/114163225-3ada6700-992a-11eb-842a-6b56f265f9a3.png Si l'on clique, on s'abonne à cette page

https://user-images.githubusercontent.com/34798699/114163305-4e85cd80-992a-11eb-93c7-f5873aa51ad3.png On peut choisir d'annuler son abonnement en cliquant sur ce même bouton

https://user-images.githubusercontent.com/34798699/114163320-547bae80-992a-11eb-98b5-68d37dda97db.png — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Hypertopic/Porphyry/issues/152#issuecomment-816568895, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJAT34LOQ6MHNW6ACL5TKM3TH3FLNANCNFSM4G3T6WVA.

cedricleandres commented 3 years ago

Dans le cadre de Graines d'artistes, ce ticket est assigné aux binômes: Rédaction de scenario : @thomasdoublet1 et @maelht

cedricleandres commented 3 years ago

Pour le groupe graines d'artistes :

Les scénarios "S'abonner à une catégorie", "Etre informé de l'ajout d'un item dans une catégorie" et "Etre informé de la modification d'un item" ont pu être validés. @benel

benel commented 3 years ago

@Hypertopic/graines-d-artistes-1 @cedricleandres

Les scénarios "S'abonner à une catégorie", "Etre informé de l'ajout d'un item dans une catégorie" et "Etre informé de la modification d'un item" ont pu être validés.

Désolé, je n'ai pas compris... C'est l'équipe qui les a validé ? Où sont les version finales ? Il ne me semble les avoir vues ?

benel commented 3 years ago

@Hypertopic/graines-d-artistes-1

Ah, je viens de le retrouver. Ce serait bien de le mettre dans le ticket : ça documente votre fonctionnalité.

benel commented 3 years ago

@maelht @thomasdoublet1 N'oubliez pas de mettre les scénario finaux (vous auriez même pu les faire avec des brouillons), directement dans le ticket. C'est une bonne manière de documenter la fonctionnalité.

maelht commented 3 years ago

Scénarios :

Fonctionnalité:  Etre informé d'un changement dans une catégorie

Scénario: suite à une modification d'item
Soit "Lauréats" une catégorie à laquelle l'utilisateur est abonné
Lorsque l'item "1994_6-9_11_ROM_R_C"  appartenant à la catégorie "Lauréats" est modifié
Alors l'utilisateur est informé de la modification de  l'item "1994_6-9_11_ROM_R_C"  par une notification dans son client RSS

Scénario:  suite à un ajout d'item
Soit "Lauréats" une catégorie à laquelle l'utilisateur est abonné
Lorsque l'item "1994_6-9_11_ROM_R_C"  est ajouté à la catégorie "Lauréats"
Alors l'utilisateur est informé de l'ajout de l'item "1994_6-9_11_ROM_R_C"  par une notification dans son client RSS

benel commented 3 years ago

Merci @maelht pour cette nouvelle version des scénarios. C'est très bien.

Vous pouvez maintenant la soumettre sous forme d'une pull request.

cedricleandres commented 3 years ago

Ci-dessous les maquettes du ticket:

Etant donné que nos maquettes traitent de l'abonnement à des topics (Get notified on changes related to a topic), et possède des similarité avec la fonctionnalité liée à l'abonnement aux corpus (Get notified on corpus changes #501), nous avons imaginé tout d'abord une interface d'accueil.

accueil

Avec notamment un bouton du flux RSS du navigateur (correspondant à un plugin lecteur RSS installé) et aussi un lien "flux RSS" présent sur le site Porphyry, permettant de renvoyer une sorte de page intermédiaire, qui va choisir de s'abonner soit au corpus, soit au topic. Pour ce ticket nous avons choisi de nous diriger vers l'implémentation du lien dans le corps de la page car le bouton présent dans le html/header/link n'est plus très utilisé actuellement.

accueigl

Une fois que nous cliquons sur le lien "flux RSS" présent sur le site, la page intermédiaire s'affiche. Cette page présente la notion de flux, comment l'utiliser et propose à l'utilisateur de s'abonner soit à un flux de topic ou à un corpus:

toto

Ensuite focalisons nous uniquement sur la fonctionnalité "Get notified on changes related to a topic" et cliquons sur le bouton correspondant, alors une page permettant de choisir un flux dans la liste des topics:

new2

Choisissons de nous abonner au topic lauréat:

page_rss

Nous allons utiliser deux exemples de lecteurs pour observer le flux RSS présent dans "lauréat".

Le lecteur RSS Feed Reader:

Après avoir cliqué sur "lauréat", une page s'affiche pour nous confirmer notre abonnement à feed reader

Plugin_feed_1

Enfin nous pouvons observer les notifications une fois qu'un item présent dans un topic (ou catégorie) dans lequel nous nous sommes abonné sera crée ou modifié, directement depuis le navigateur.

Plugin_feed_2

Le lecteur InoReader

Après avoir cliqué sur "lauréat", nous sommes redirigés vers une page "dessins.porphyry.org/rss/topic/Laureats.xml" qui affiche l'ensemble du fichier xml correspondant au flux RSS de "lauréat". Une pop-up du plugin InoReader apparait aussi pour nous permettre de s'abonner à ce flux:

Plugin__inoreader_2

Ici aussi, nous pourrons observer les notifications une fois qu'un item présent dans un topic (ou catégorie) dans lequel nous nous sommes abonné sera crée ou modifié, depuis le navigateur.

Plugin__inoreader_3

Le plugin Inoreader possède aussi sa propre interface de gestion des flux, un peu comme une boite mail, où on pourra consulter les flux, les supprimer...

Plugin__inoreader_4

Pour finir, nous ajouterons ces maquettes dans la discussion du ticket "Get notified on changes related to a topic #152". Et nous proposerons la maquette de la page intermediaire, à l'autre ticket (Get notified on corpus changes #501) car cette interface permet de simplifier le parcours de l'utilisateur au sein du site. pour rappel:

toto

@benel

benel commented 3 years ago

OK @cedricleandres. C'est beaucoup plus clair.

Pour la présentation à l'oral, il faudra peut-être dire tout haut ce à quoi les gens vont penser, pour les rassurer : lorsque l'on voit la source XML du flux avec InoReader, expliciter le fait que l'affichage de ce XML n'est évidemment pas très parlant et que c'est un choix un peu surprenant de InoReader, mais que l'on peut être rassuré : on n'a pas besoin de le lire et qu'ensuite, une fois abonné, les données sont mises en forme dans une jolie interface...

cedricleandres commented 3 years ago

Bonjour, voici la stratégie d'implémentation à laquelle nous avons réfléchi avec @maelht :

L’idée générale pour implémenter cette fonctionnalité serait de créer un flux RSS pour chaque topic du site, afin que n’importe qui puisse les récupérer et le consulter via des agrégateurs de flux RSS comme Feedly, Ino reader, etc… .

Quelle partie du code sera impactée (classes, méthodes) ?

La première chose à faire est de créer le bouton permettant au visiteur de récupérer le flux. Il faut donc ajouter une nouvelle classe FluxRSS afin de définir les différentes méthodes du flux. On ajoutera ensuite un bouton dans la classe Header.jsx.

Le bouton donne un lien comme https://dessins.porphyry.org/rss, qui sera une page permettant de choisir de s'abonner soit à un corpus, ou soit à un topic. Ensuite si on s’intéresse uniquement à notre fonctionnalité, et si nous nous abonnons à un topic en particulier, nous aurons un lien vers le fichier XML lié au flux RSS du topic par exemple : https://dessins.porphyry.org/rss/Lauréat.xml

Ensuite il faudra : Écrire une fonction (probablement dans un nouveau fichier .js dans le dossier src) de création de flux (voir librairie utilisée) Écrire une fonction qui transforme les informations d’un items en un fichier XML compatible avec un lecteur de flux RSS (voir librairie utilisée). Ainsi à chaque création d’un nouvel item la fonction sera appelée, mais aussi à chaque modification d’un item. Cette fonction sera implémentée dans la classe Item (item.jsx) pour avoir facilement accès aux attributs et être facilement appelée quand on en a besoin. En effet, elle serait appelée dans les fonctions de construction et de modification d’un item.

Si le code est fonctionnel, un fichier xml pour le feed créé sera mis à jour à chaque modification/création d’un item, permettant, à partir d’un agrégateur de flux rss, d’avoir un aperçu de l’item et un lien vers porphyry pour constater les changements.

Y aura-t-il des difficultés d'un point de vue algorithmique ? Avez-vous des pistes pour les résoudre ?

Non, la difficulté réside plus dans l’organisation des fichiers, des classes et des méthodes que dans un quelconque algorithme.

Les données dont vous avez besoin sont-elles déjà chargées par la page ? Si oui, quelle est la structure des données et comment allez-vous récupérer précisément celles qui vous intéressent ? Si non, quelle sera la requête la plus efficace et comment allez-vous récupérer dans la structure de données précisément celles qui vous intéressent ?

Les données envoyées sont celles entrées à la création d’un item, quand l’item est créé on peut donc directement les récupérer pour créer notre flux RSS avant de les envoyer dans la bdd. Lors de la modification d'un item, nous récupérerons le ou les topics modifiés et une variable record_modified (l'heure de modification) qui permettra d'établir une classification chronologique des items.

Existe-t-il des bibliothèques qui pourraient simplifier l'implémentation ?

Il existe la bibliothèque https://github.com/phi-jp/rss-generator . Cette bibliothèque JS permet de simplifier la génération de fichier XML adaptés aux flux RSS.

Mais pour nous allons plutôt générer le XML avec le SGBD couchdb. Il faudra donc commencer par classer la base de données par date de modification des items, pour simplifier la récupération des items qui nous intéressent. Ensuite on utilisera couchdb pour générer le fichier XML lié à un flux RSS, en fonction du topic. On créera ensuite une vue pour récupérer le lien du fichier généré sur le coup.

Doit-on intégrer des services extérieurs (ex : cartographie) ? De quelles fonctionnalités en particulier aura-t-on besoin ? Est-ce que le service choisi les propose ou doit-on passer chez un concurrent ? Comment s'utilisent ces fonctionnalités ? avec quels paramètres ?

Des services extérieurs seront nécessaires pour utiliser la fonctionnalité mais ils ne seront pas à intégrer dans notre application ; on fournit simplement le fichier permettant aux services de lire notre flux.

Des étapes préalables de développement, testables, sont-elles envisageables afin de diminuer la complexité de la livraison ? Refactoring (livrable à part entière, isofonctionnel) ? Code développable et testable de manière externe au logiciel ? Étape du scénario (non livrable en tant que tel mais dont l’effet peut être testé) ?

Le développement pourra être moins complexe, avec la possibilité avec couchdb et argos de faire de faire des tests de manière locale avec notre base de donnée de test.

cedricleandres commented 3 years ago

Ci-dessous la stratégie d'implémentation du back-end:

Vue Couchdb : L'idée ici est de parcourir la base de donnée pour répérer les items modifiés et parcourir ces derniers pour récuperer de possibles topics, ainsi que la date de modification. Créer un fichier : Argos/app/views/topic_modified/map.js

function (doc) { if(doc.topics && doc.record.modified){ for (var t in doc.topics) { emit([ t,doc.record.modified]); } } }

Rewrite Couchdb : L'idée ici est de configurer le fichier qui permettre de retranscrire l'uri obtenue par couchdb Modifier le fichier Argos/app/rewrites.json

{ "from": "topic_feed/:topic", "to": "_list/topic_feed/topic_modified", "query": { "include_docs": "true", "startkey": [":topic"], "endkey": [":topic",{}] } } List Couchdb :

Créer un fichier Argos/app/list/feed/feed.js
exemple à modifier avec les balises souhaitées pour une bonne lecture rss:

function (head, req) { start({ 'headers': { 'Content-Type': 'text/xml' } }); uri = req.query.app; send(''Modification_topic''); send(uri); send('Created or updated items.'); while(row = getRow()){ send(''.concat( '', '' + row.doc.item_name + '', 'Lieu : ' + row.doc.spatial + ' créé le ' + row.doc.created + '', '' + uri + '/item/' + row.doc.item_corpus + '/' + row.id + '', '' )); } send(''); }

benel commented 3 years ago

Bonjour, voici la stratégie d'implémentation à laquelle nous avons réfléchi avec @maelht (...)

Merci @cedricleandres et @maelht pour cet essai de stratégie d'implémentation.

Cependant je suis extrèmement étonné par son contenu : c'est comme si vous ne teniez pas du tout compte :

des choix de conception (notamment les URI des flux) et des choix technologiques effectués (vues et listes) dans le ticket #517,
de ce qui a déjà été implémenté dans ce même ticket et qui serait donc mutualisable.

benel commented 3 years ago

des choix de conception (notamment les URI des flux) et des choix technologiques effectués (vues et listes) dans le ticket #517,

@cedricleandres @maelht Je vous invite fortement à vous rapprocher de @sarah-ngn et @lildelfino pour qu'ils vous expliquent comment on se sert de leur code et comment ça marche (ce qui vous permettra de voir ce qu'il faudrait changer à leur code pour monter en généralité et gérer à la fois les corpus et les topics).

benel commented 3 years ago

@cedricleandres @maelht

Ci-dessous la stratégie d'implémentation du back-end (...)

Cette partie est mieux. Mais elle fait comme s'il fallait refaire "en double" pour les topics ce qui a été fait pour les corpus. Au contraire vous devez voir ce qu'il faudrait modifier dans ce qui a été fait pour les corpus pour monter en généralité et gérer aussi les topics.

cedricleandres commented 3 years ago

Bonjour, voici la stratégie d'implémentation à laquelle nous avons réfléchi avec @maelht (...)

Merci @cedricleandres et @maelht pour cet essai de stratégie d'implémentation.

Cependant je suis extrèmement étonné par son contenu : c'est comme si vous ne teniez pas du tout compte :
* des choix de conception (notamment les URI des flux) et des choix technologiques effectués (vues et listes) dans le ticket #517,

* de ce qui a déjà été implémenté dans ce même ticket et qui serait donc mutualisable.

Merci @benel pour le retour. Effectivement j'ai essayé de relire le ticket #517 pour faire un résumé de toute la discussion sur la stratégie d'impémentation, mais c'est pas encore ça. C'est pourquoi j'ai mis la stratégie particuliement sur le back end en bas, car je me suis plus appliqué a comprendre le code du back-end et l'intégrer à notre ticket avec @sarah-ngn et @lildelfino qui nous ont beaucoup aidé.

cedricleandres commented 3 years ago

@cedricleandres @maelht

Ci-dessous la stratégie d'implémentation du back-end (...)

Cette partie est mieux. Mais elle fait comme s'il fallait refaire "en double" pour les topics ce qui a été fait pour les corpus. Au contraire vous devez voir ce qu'il faudrait modifier dans ce qui a été fait pour les corpus pour monter en généralité et gérer aussi les topics.

Effectivement, nous avons pensé à généraliser avec ce qui a été fait pour le corpus, mais étant donné que ce ne sont pas les mêmes données qui sont retournés par exemple dans la couchdb, c'est un compliqué de tout intégrer dans la même vue, je vais tout de même continué à éssayer.

J'ai une question. dans la liste que j'ai crée, j'ai accès à ma startkey qui est un identifiant de topic. Si je veux par exemple dans la description, intégrer le nom du topic qui à été modifié et non uniquement son identifiant est-ce possible?

benel commented 3 years ago

@cedricleandres @maelht

Effectivement, nous avons pensé à généraliser avec ce qui a été fait pour le corpus, mais étant donné que ce ne sont pas les mêmes données qui sont retournés par exemple dans la couchdb, c'est un compliqué de tout intégrer dans la même vue, je vais tout de même continué à éssayer.

L'idée générale qui doit guider votre stratégie est de généraliser ce que vous aviez pour un corpus afin que ça marche aussi pour un topic. Donc, en particulier, à chaque fois que vous aviez un identifiant de corpus, vous aurez un identifiant "d'objet" (corpus ou topic).

benel commented 3 years ago

@cedricleandres @maelht

J'ai une question. dans la liste que j'ai crée, j'ai accès à ma startkey qui est un identifiant de topic. Si je veux par exemple dans la description, intégrer le nom du topic qui à été modifié et non uniquement son identifiant est-ce possible?

C'est faisable a priori avec une technique Map/Reduce appelée "collation" (on se sert du tri des clés pour mettre à côté des données provenant d'objets différents). Commencez sans le nom et, une fois que ce sera fait, je vous montrerai comment faire pour ajouter le nom.

Hypertopic / Porphyry