Get notified on corpus changes #501
Comments
|
Dans le cadre de Graines d'artistes, cette fonctionnalité permettra en quelque sorte de fidéliser le visiteur en lui permettant d'être informé lorsqu'un changement a été fait sur le corpus comme par exemple l'ajout d'une nouvelle œuvre. |
|
Dans le cadre de Graines d'artistes, ce ticket est assigné aux binômes: |
|
Pour le groupe graines d'artistes : Les scénarios "Etre informé de l'ajout d'un item" et "Etre informé de la modification d'un item" ont pu être validés. Cependant dans un soucis de cohérence avec le second ticket "Subscribe to a topic" de notre groupe, nous devons encore ajouter un scénario correspondant à l'abonnement de l'utilisateur à un corpus, avant de passer au livrable suivant. Concernant les maquettes, il faudra rajouter une maquette utilisant un autre lecteur RSS. Enfin la rédaction de la stratégie d'implémentation n'est pas encore achevée, il reste à déterminer la meilleure manière de récupérer les attributs d'un item notamment la date de modification du dernier contributeur. |
|
@cedricleandres @sarah-ngn 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é. |
|
Ancienne version des scénarios : Fonctionnalité: S'abonner à un corpus
Scénario:
Soit l'utilisateur sur la page d'accueil
Et l'utilisateur s'abonne au corpus “Dessins”
Alors l'utilisateur est abonné au corpus “Dessins” dans son client RSSFonctionnalité: Être informé de l'ajout d'un item
Scénario :
Soit l'utilisateur est abonné au corpus "Dessins"
Quand l'item "1994_6-9_11_ROM_R_C" est ajouté au corpus
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
Fonctionnalité: Être informé de la modification d'un item
Scénario :
Soit l'utilisateur est abonné au corpus "Dessins"
Quand l'item "1994_6-9_11_ROM_R_C" est modifié
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 |
|
Nouvelle version des scénarios : Fonctionnalité : Etre informé, recevoir une notification
Scénario 1 : Être informé de l'ajout de l'item
Suite à l'abonnement au corpus "Dessins"
Suite à l'ajout de l'item "1994_6-9_11_ROM_R_C"
Alors l'utilisateur sera informé par une notification dans son client RSS
Scénario 2 : Être informé de la modification d'un item
Suite à l'abonnement au corpus "Dessins"
Suite à la modification de l'item "1994_6-9_11_ROM_R_C"
Alors l'utilisateur sera informé par une notification dans son client RSS |
|
Voir commentaires dans l'autre discussion... |
The prefix in the object can be changed in settings. No prefix means no accountability. Needed for Hypertopic/Porphyry#152, Hypertopic/Porphyry#501, Hypertopic/Porphyry#219.
Integration of Hypertopic/AAAforREST@141cbf3 and Hypertopic/Argos@2b4e72b Needed for #152, #501, and #219.
|
Bonne nouvelle : pour vous faciliter le travail, j'ai développé la partie backend (Argos) de votre fonctionnalité : Ça ressemple à cela : Vous retrouverez donc dans la vue du corpus ces données pour tout item modifié (à partir de maintenant). |
Integration of Hypertopic/AAAforREST@141cbf3 and Hypertopic/Argos@2b4e72b Needed for Hypertopic#152, Hypertopic#501, and Hypertopic#219.
Je copie la discussion ici, je vous ai également répondu tout en bas de cette publication : Bonjour, voici la stratégie d'implémentation à laquelle nous avons réfléchi avec @ThomasSobrecases : L’idée générale pour implémenter cette fonctionnalité serait de créer un flux RSS pour chaque corpus du site, afin que n’importe qui puisse les récupérer et le consulter via des sites comme Feedly, The old reader, etc… Créer notre propre lecteur RSS semble trop compliqué à implémenter en même temps, mais pourrait faire l’objet d’un autre ticket. 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. Le bouton donne un lien comme https://dessins.porphyry.org/corpus.xml, lien vers le fichier XML lié au flux RSS de notre corpus entier. Ensuite il faudra : Si le code est fonctionnel, le 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. Existe-t-il des bibliothèques qui pourraient simplifier l'implémentation ? 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. Probablement que ce code XML devra être stocké dans la bdd aux côtés des items, et non dans les fichiers source du projet React. Sinon il ne pourrait pas être récupéré et mis à jour facilement pour le client. 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é) ? Il faudrait tester en amont la librairie de création de XML pour obtenir le rendu que l’on souhaite facilement en terme de flux RSS, une fois satisfait du rendu on pourra implémenter ce que l’on a fait dans le code final.
Nickel merci pour ça. Je pense que la date et le contributeur de la dernière modification seront considérés comme des attributs d'un item. Dans ce cas une requête GET /item/ID/"attribut"/ pour obtenir un attribut lié à un item me parait adapté.
Sur la page principale on a : GET https://argos.utt.fr/corpus/Graines%20d'artistes et GET https://steatite.utt.fr/corpus/Graines%20d'artistes qui semblent permettre de récupérer l'ensemble du corpus dans un fichier JSON. Grâce à votre modification du back-end (merci pour ça) on pourra récupérer les infos sur les contributeurs et les dates de modifications, et donc organiser correctement notre fichier XML pour le flux RSS. Maintenant qu'on sait comment récupérer la date de modification et les attributs, il faudrait trier le corpus par date de modification pour pouvoir récupérer seulement les derniers items dans notre flux RSS. Je pense que la manière la plus logique pour ne pas ralentir porphyry est de le faire en back-end à chaque modification. Cependant je ne sais pas si cela est possible, qu'en dites vous ? |
|
Merci @lildelfino @ThomasSobrecases pour cette mise à jour de votre stratégie d'implémentation.
Je ne sais pas si vous avez vu les recherches du binôme qui travaille sur les maquettes, mais il est possible aussi de référencer les flux RSS dans l'entête du fichier HTML (ce qui présente une petite difficulté avec React mais pas insurmontable). Du coup, vous n'avez pas besoin de modifier le design de votre page. C'est le navigateur qui gère lui-même l'affichage du menu RSS (en général à droite de la barre d'adresse).
Bien sûr. L'intérêt des standards, c'est que l'on peut être compatible avec des outils qui existent déjà.
Si vous choisissez de générer votre RSS avec React, elle aura sa propre URI. Donc a priori ce ne sera pas dans la même "page". Vous partirez donc directement de ce que vous récupérez dans le backend... Je l'ai déjà écrit quelque part (ça m'inquiète, je ne le retrouve plus), mais si vous voulez que ce soit l'URI du flux d'un corpus. Il va falloir absolument que vous ayez l'identifiant de ce corpus dans l'URI...
Du coup (voir plus haut), vous allez vous appuyer directement sur la vue "corpus" produite par Argos.
Pas à proprement parler. Un attribut est de la forme
À ralentir quelque chose, il vaut mieux le faire sur une requête qui sera utilisée peut-être une fois par jour (RSS sur le frontend) plutôt que sur qui est utilisée toutes les minutes (corpus sur la backend).
Je ne comprends pas cette phrase. Par ailleurs, j'ai un doute sur l'intégration de votre bibliothèque dans React. Une autre alternative serait de générer le RSS directement dans CouchDB... Si certains d'entre vous ont fait LO10, c'est comparable à ce que l'on avait fait ensemble. Si vous avez besoin d'aide, on peut regarder ensemble... |
|
Pour le front-end : link rel="alternate" type="application/rss+xml" href="https://www.lemonde.fr/entreprises/rss_full.xml" title="Test2" Pour la back-end : Voilà ce qu'on a compris avec les nouveaux assignés à la stratégie d'implémentation : il faudrait déjà classer la base de données par date de modification, pour simplifier la récupération des items qui nous intéressent. Ensuite on utilisera la librairie JS dans argos pour générer le fichier XML lié à un flux RSS, en fonction du corpus. On créera ensuite une vue pour récupérer le lien du fichier généré sur le coup. |
|
@Hypertopic/graines-d-artistes-1 <link rel="alternate" type="application/rss+xml" href="https://www.lemonde.fr/entreprises/rss_full.xml" title="Test2"/>Il faudrait faire un petit test (avec du HTML statique en local) pour voir :
OK.
On avait dit qu'on générait le XML dans CouchDB... Vous avec regardé la documentation des listes CouchDB ?
C'est une autre fonctionnalité de CouchDB : réécrire une URI sur mesure pour la faire correspondre à une URI interne Pour la partie vue CouchDB. On peut le faire ensemble, si vous voulez... Je suis encore là jusqu'à midi... |
Pour Argos plutôt ? Vous faites bien de vous poser la question, mais la réponse est plutôt non :
Aujourd'hui, la solution la plus simple est de le faire avec CouchDB. C'est pour cela que je vous oriente vers ce choix technologique. |
Ça vous va si on le fait en tout début de matinée ? Ça vous laissera du temps pour avancer avant la réunion de suivi... Quel est votre sujet exactement ? Est-ce réellement le lien entre backend et frontend ? Ou est-ce la partie backend ? |
|
Je vois dans votre compte-rendu (qui vient d'arriver) que vous étiez affectés au backend. Donc j'imagine que c'est bien sur cela que vous voulez être briefés. |
Il faut d'abord installer Pour la version de |
|
Merci @therealdarkflamemaster pour cette partie de stratégie d'implémentation. Par contre, j'imagine que vous avez lu la discussion à propos de la gestion devenue très chaotique dans les navigateurs des |
|
Stratégie d'implémentation backend :
Pour ce qui est du lien du corpus dans le titre, nous continuons de chercher un moyen de le récupérer de manière dynamique. Nous nous posions la question s'il n'existe pas déjà un attribut qui permettrai de récupérer le nom du corpus ou bien si l'on pouvait directement récupérer l'URI vers la page de l'item en attribut ? @benel |
|
Merci @sarah-ngn et @lildelfino pour ce début de stratégie d'implémentation (et même un début d'implémentation !).
Ne perdez pas de vue le problème à résoudre. Dans votre flux (
Or vous voulez générer un lien de votre flux RSS vers https://dessins.porphyry.org/item/Graines%20d'artistes/379c510401214c97968b15affb6eba1ed6a03db0 Donc, ce qui vous manque c'est La solution la plus simple est, comme je vous le disais la semaine dernière, est de passer cette chaîne de caractères en paramètre à l'URI de votre liste. Elle deviendrait par exemple Avant d'y arriver, vous avez deux informations à chercher dans la documentation de CouchDB :
|
D'après ce lien : https://guide.couchdb.org/draft/transforming.html, il semblerait que via le paramètre req, on peut récupérer les requêtes http :
https://docs.couchdb.org/en/1.5.1/api/ddoc/rewrites.html : D'après l'exemple suivant il semblerait que les "queries" non-considérées dans le rewrites sont gardées à la réécriture : J'ai malheureusement pas pu tester ces solutions car j'ai un problème avec argos et couchdb : quand je modifie un fichier js en local et que je fais docker-compose up --detach, rien ne se met à jour sur couchdb. Je n'arrive donc pas à créer la fonction liste. D'ailleurs cette fois-ci, quand je "up", les items modifiés restent modifiés (avant ça les remettait à l'état initial). Je ne comprends vraiment pas d'où vient ce problème sachant que je vérifie à chaque fois que couchdb est éteint avant de up. |
Tout à fait !
C'est bien ce qu'il me semblait. Heureux que vous ayez trouvé confirmation dans la documentation.
Vous pouvez réinitialiser vos données de la manière suivante :
|
|
@benel
<header className="row align-items-center">
<div className="col-lg-4 d-none d-lg-block logo"></div>
<h1 className="col-lg-4">
<Link to="/">{this.state.user}</Link>
</h1>
<div className="col-lg-2">
<Rss/>
</div>
<div className="col-lg-2">
<Authenticated conf={this.props.conf} />
</div>
</header>Pour le button RSS, il y a deux parties :
class Rss extends Component {
constructor(props) {
super(props);
this.state = {rss: ''};
}
render() {
return (
<div className="rss-btn">
<Link to="/rss">
<div className="rss-icon">
<RssIcon/> // l'image svg
</div>
<Trans>Flux RSS</Trans>
</Link>
</div>
);
}
}
export default Rss;
<Router>
<Switch>
<Route path="/item/:corpus/:item" component={Item} />
<Route path="/viewpoint/:id" component={Outliner} />
<Route path="/rss/topic/" component={RSSTopic} /> // nouveau
<Route path="/rss/" component={RSS} /> // nouveau
<Route path="/" component={Portfolio} />
</Switch>
</Router>En outre, j'ai quelques problèmes sur le style de button Rss que j'ai fait et la transciption de textes en anglais. Ces problèmes ont été résolus par @TristanGdc |
|
@benel
Merci à @therealdarkflamemaster de m'avoir aider pour l'écriture du CSS et l'utilisation des Link. |
|
OK, merci pour vos traductions @TristanGdc. |
&& Get notified on changes related to a topic (Hypertopic#152)
&& Get notified on changes related to a topic (Hypertopic#152)
&& Get notified on changes related to a topic (Hypertopic#152)
&& Get notified on changes related to a topic (Hypertopic#152)
&& Get notified on changes related to a topic (Hypertopic#152)
&& Get notified on changes related to a topic (Hypertopic#152)
benel
unassigned therealdarkflamemaster, ThomasSobrecases, TristanGdc, lildelfino and sarah-ngn
Description
A given user, interested in a corpus, could register to a corpus in order to be notified whenever something has been modified in this corpus.
What is the valuable outcome that cannot be achieved with current features?
For which stakeholder (people, role, project, domain) is it important?
Which user action should be enabled (or restricted)? For who?
Additional details (solutions you think about, or workarounds you tried)
Deliverables status
Phase 1
Phase 2
Phase 3
The text was updated successfully, but these errors were encountered: