Produits Entr'ouvert » Combo

Cas d'usage: page de travail RSU = trois systèmes de recherche sur une page : adult, spouse, child.

L'affichage spouse doit savoir qu'un adult a été trouvé, pour alors afficher des liens vers les formulaires en envoyant adult_id et spouse_id

Idem pour child.

La recherche d'un nouvel adulte met à zéro les autres.

(relecture sur le fond)

verbose_name = _('Backoffice Search')

Pas d'ambition pour le front ?

('auth', '0006_require_contenttypes_0002'),

Ça oblige django 1.8, on peut s'en passer.

search_url = models.CharField(, max_length=200,
help_text=('with %(q)s and %(quote_q)s'))
get_url = models.CharField(, max_length=200, blank=True,
help_text=('with %(id)s and %(quote_id)s'))

Les deux s'appellent "Search URL". Plutôt qu'un paramétrage dans l'UI, je préférerais que se définisse dans la config une liste de choix, dans l'idée que cette liste d'URL arrive derrière à être autoconfigurée.

Ça rendrait aussi l'ajout dans cette même cellule d'une recherche "interne" plus naturelle, il me semble.

varname = models.CharField(('varname'), max_length=200, blank=True)

J'aimerais bien qu'on arrive à faire sans l'ajout d'un nouvel identifiant unique, ça pourrait pas être le slug ?

Frédéric Péters a écrit :

(relecture sur le fond)

verbose_name = _('Backoffice Search')

Pas d'ambition pour le front ?

Je sais même plus d'où ça vient. Mais oui, bien sûr.

('auth', '0006_require_contenttypes_0002'),

Ça oblige django 1.8, on peut s'en passer.

C'est bien possible, j'y suis pour rien :) (makemigrations et rien regardé).

search_url = models.CharField(, max_length=200,
help_text=('with %(q)s and %(quote_q)s'))
get_url = models.CharField(, max_length=200, blank=True,
help_text=('with %(id)s and %(quote_id)s'))

Les deux s'appellent "Search URL".

Oups.

Plutôt qu'un paramétrage dans l'UI, je préférerais que se définisse dans la config une liste de choix, dans l'idée que cette liste d'URL arrive derrière à être autoconfigurée.
Ça rendrait aussi l'ajout dans cette même cellule d'une recherche "interne" plus naturelle, il me semble.

Ok.

varname = models.CharField(('varname'), max_length=200, blank=True)

J'aimerais bien qu'on arrive à faire sans l'ajout d'un nouvel identifiant unique, ça pourrait pas être le slug ?

Yep, ça doit pouvoir, je vérifie ça.

Merci.

(détail, {{item.texti}}, i en trop)

Concernant slug=varname, ça marche mais pour pouvoir jouer avec les variables dans le templates, je vais un varname=slug.replace('-','_') parce que j'aime pas trop les slug avec des _ ... mais ça peut être discuté.

Pas d'objection à ça.

def modify_global_context(self, context, request):
[...]
result = requests.get(url, cache_duration=0).json()

J'hésite là-dessus, le modify_global_context il est appelé dans le rendu d'une page et ça va donc le ralentir; je me demande dans quelle mesure cela pourrait être évité. (autrement dit, cette cellule est bloquante, quelle part de js pour qu'elle ne le soit pas ?)

M'attardant là-dessus, je me rends compte que plus important encore, et passé à côté de ça ce matin, je suis gêné par le get_url, ça transforme une cellule de recherche qui affiche les résultats d'une recherche en une cellule qui doit aussi afficher le détail d'un élément seul. Peut-être que je serais plus à l'aise avec ça en l'ayant en deux temps, avec comme premier temps la cellule de recherche, qui correspondrait à :

    {% if item.url %}
    <a href="{{ item.url }}">{{ item.text }} ({{ item.id }})</a>

Et en deuxième temps la gestion de l'affichage d'un élément,

    {% elif cell.search_service.get_url %}
    <a href="?{{ cell.varname }}={{ item.id }}">{{ item.texti }} ({{ item.id }})</a>

Je continue cependant à faire en sorte que la cellule sache à la fois propose la recherche puis afficher un résultat sélectionné (quand c'est possible ie que le get_url existe).

Je continue à trouver ça intéressant à discuter; avec comme idée alternative de permettre ...?adult_id=[adult] dans l'URL paramétrée d'une cellule JSON (en étendant #15152 pour ne pas passer juste "user" mais tout "context").

Voici donc une version simple, qui peut délèguer l'affichage du résultat à une cellule Json (suite à son amélioration #15142 + #15154 + #15152).

Pour cela, quand la page est appelée avec ?<slug_cellule_recherche>=foobar alors une variable slug_cellule_recherche est posée dans le contexte général de la page, et est donc utilisable dans l'URL de la cellule JSON via [slug_cellule_recherche]

  combo_search_input_{{ cell.pk }}.on('keyup', function() {

Faire .on('keyup change', ..., pour gérer aussi le changement de contenu qui interviendrait autrement que par le clavier. (genre clic du milieu) En fait vu le setTimeout on ne peut sans doute pas mêler les deux événements dans la même fonction. Juste un .on('change', combo_search_update_... en plus, du coup, a priori.

À part ça, peut-être avoir un test qui ajoute cette cellule dans tests/manager.py ?

J'ai pas trouvé mieux que keyup.

Pour moi il faut keyup et change.

Pour le test dans manager.py je sais pas si je t'ai bien compris, tu diras...

Yep, c'est ça.

Frédéric Péters a écrit :

J'ai pas trouvé mieux que keyup.

Pour moi il faut keyup et change.

Mais j'arrive pas à comprendre, pour "change" (il ne fait vraiment rien par rapport au clic du milieu, par exemple)

"change" sera appelé à coup sûr si le contenu du champ change, en cas de modification au clavier, ça sera lors du focus out, mais il y a d'autres interactions imaginables que le clavier. Exemple : copicollage par clic du milieu, clic en-dehors de l'<input>, un événement "change" sera lancé, aucun événement keyup.

Ce que j'exprimais mal plus haut, c'est que sur événement change, la recherche doit se faire immédiatement, pas après 300ms, que "change" et "keyup" ne peuvent pas partager la même fonction de callback.

Oh et dans le sujet des événements js, je verrais bien le <input> dans un <form>, avec aussi un <button>, et sur le <form> un .on('submit', function() { tuer le timeout; faire la recherche }). Pour les aveugles.

Yep, ça me semble bien ça. Je le teste en local demain.

Autre modif que tu avais demandée Frédéric : si q_<slug> est présent dans la query_string, alors ça initialise la recherche avec ce q. (ajouts dans models.py et search-cell.html)

Chouette, ça fait du coup un appel genre /ajax/search/1/?q_test=chat&q=chat; tu penses quoi en présence d'un slug de modifier name="q", request.GET.get('q'), etc. pour faire q → q_<slug> ? (si ça amène pas de complications, ça m'irait bien, sinon je vivrai sans)

Côté style, pour ne pas devoir surcharger côté publik-base-theme, ça me dirait bien d'avoir ça dans le markup :

--- a/combo/apps/search/templates/combo/search-cell-results.html
+++ b/combo/apps/search/templates/combo/search-cell-results.html
@@ -1,3 +1,4 @@
+<div class="links-list">
 <ul>
   {% for item in results.data %}
   <li><a href="{{ item.url }}">{{ item.text }}</a>{% if item.description %}
@@ -5,3 +6,4 @@
   {% endif %}</li>
   {% endfor %}
 </ul>
+</div>

Ack pour moi; et je verrai côté style gadjo.