Salut à tous,
en ce moment Hugo travaille pas mal sur solar et pour la ZEP12 il nous a fait part de quelques difficultés pour y arriver.
VOici les solutions qu'il propose
Le premier champ sert à charger notre templates avec les données indexés.
Les autres champs de la classe, ne sont pas indexés par-défaut, et permette de servir de critaire de recherche. Par exemple, on pourrais dire qu'on veut rechercher uniquement sur le titre, ou sur la description ou sur le sha_public. Ces champs sont accessible aussi lors des résultat, ça permet d’éviter d'aller chercher les informations dans la base de données quand on affiche les résultats.
Deux méthodes sont à implémenter: get_model(self) et index_queryset(self, using=None)::
- get_model(self) renvoi un type de classe qui étend django.db.Model. On peut tricher et étendre cette classe sans être un objet de la base de donnée.
- index_queryset(self, using=None) doit renvoyer OBLIGATOIREMENT un QuerySet. Un truc de la base de donnée et j'ai ne n'est pas trouvé comment on créé un QuerySet à la main. Sachant que les parts, chapter, extract ne sont pas dans la base de données. On est eu.
La deuxième solution est d'utiliser qu'un seul objet, celui en base de donnée, ça donne ça :
La classe python
Le template
MAIS y'a un gros gros désavantage, c'est que dans les résultat de la recherche, on a aucun moyen de savoir ou est l'endroit ou le contenu recherché se trouve. On a juste l'objet content mais on ne ne sait pas dans quel extract, chapter, parts, le contenu recherché est. Pour l'utilisateur cela signifie que l'on doit obligatoirement le rediriger vers le tutoriel et non vers un extrait. Pas cool, si c'est un big tuto, l'utilisateur est obligé de chercher dans toutes les parties à la main.
La troisième solution est d'utiliser une autre API.
Perso voici ce que je propose :
Créer une classe PublishedExtracts qui se comporse ainsi :
| class PublishedExtract(models.Model):
content = models.ForeignKey("PublishedContent")
title = models.CharField()
absolute_url = models.CharField()
html_file_path = models.CharField()
|
A chaque publication et mise à jour on RAZ tous les PublishedExtract et on recrée ceux qui vont bien. Comme ça on a à la fois les extraits qui vont bien, la classe PublishedContent qui suit, et on évite de réimplémenter tout le modèle comme on faisait avant.
Par contre cela crée une table supplémentaire, et ça "recomplexifie" notre modèle.
Bien évidemment, si on change d'API pour parler à Sonar, moi ça me va, mais j'ai l'impression que ça ralentira pas mal les choses, alors qu'on a un bon workaroud possible, je pense là.
Désolé 
