Produits Entr'ouvert » w.c.s.

[{"id": "23/10/2018", "text": "2018-10-23"}, ....]

C'est inversé ? (j'aurais plutôt vu yyyy-mm-dd comme id)

Et le rôle de "text", c'est fournir un libellé utile à l'usager, que le connecteur y mette donc le jour de la semaine, que sais-je, ça me va bien.

Après, ou avant, ça peut être utile de questionner le nombre de résultats proposés, un <select> ne va pas être idéal pour un grand nombre d'éléments.

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

[{"id": "23/10/2018", "text": "2018-10-23"}, ....]

C'est inversé ? (j'aurais plutôt vu yyyy-mm-dd comme id)

Oublie l'id ; c'est juste une copie bête-et-méchante de ce demande le connecteur IWS, mais ce qui nous intéresse ici c'est le "text".

Et le rôle de "text", c'est fournir un libellé utile à l'usager, que le connecteur y mette donc le jour de la semaine, que sais-je, ça me va bien.
Après, ou avant, ça peut être utile de questionner le nombre de résultats proposés, un <select> ne va pas être idéal pour un grand nombre d'éléments.

Justement l'idée c'est un widget "à la meetings", qui affichera un truc genre mensuel ou hebdo. Et donc, ce widget aurait en entrée un truc qui est une liste de jours (liste de jour+heure pour meetings). Mais peut-etre que le format attendu pourrait être différent que juste id/text, et plutôt id/text/date/disabled, pour faire le parallèle avec chrono (dans l'idée qu'un jour chrono propose des rendez-vous par jour, et pas jour+heure)

Et le rôle de "text", c'est fournir un libellé utile à l'usager, que le connecteur y mette donc le jour de la semaine, que sais-je, ça me va bien.

Je m'apprêtais faire ma tambouille dans le connecteur (en introduisant dépendance dans passerelle, python-babel : http://babel.pocoo.org/en/latest/api/dates.html), mais on m'a soufflé à l'oreille "fais plutôt un widget wcs, ça pourra resservir", ce que semble confirmer le commentaire de Brice.

Pas vraiment d'opinion personnelle sur le sujet (si ce n'est que je peux clore le sujet en deux lignes de codes si ça reste dans le connecteur).

Après, ou avant, ça peut être utile de questionner le nombre de résultats proposés, un <select> ne va pas être idéal pour un grand nombre d'éléments.

A priori trois ou quatre dates pas plus, à confirmer.

A priori trois ou quatre dates pas plus, à confirmer.

Je ne pige rien à cette affaire alors. S'il y a juste trois/quatre dates, il faut juste utiliser l'affichage avec des boutons radios, et le connecteur fournit dans "text" ce qu'on veut comme affichage, et rien à faire ici.

Pour aller jusqu'au bout : "Widget qui partir qui partir d'un ensemble dates au format iso, afficher des dates écrites en français, et permet à l'utilisateur d'en choisir une".

Mai vraiment je m'en fout.

J'insiste pour réfléchir et clarifier la demande.

Déjà peut-être remonter plus haut, on parle de date et on a déjà un champ de type date. Mais on n'a pas la possibilité de le limiter à certaines dates. Considère-t-on ça ?

À côté de ça on a un champ "liste" dans lequel on peut tout fourrer, pour w.c.s. ça sera du texte.

Après le type de champ, il y a la question de l'affichage, on affiche un calendrier pour les dates, c'est bien pour une sélection libre, pour une sélection fermée, moins. Pour une sélection fermée, avec un nombre réduit d'éléments, le mieux c'est des boutons radio, avec davantage d'éléments il devient utile de passer en <select> mais à un moment ça ne va pas non plus et il faut autre chose, que ça soit du <select2>, que ça soit le sélecteur de créneau qu'on a dans publik-base-theme.

Sur un champ de type liste, un template qui modifie la valeur pour la formater en date "humaine", c'est simple, vaguement :

{% extends "qommon/forms/widget.html" %}
{% load qommon %}
{% block widget-control %}
<div>
{% for option in widget.get_options %}
<input id="{{widget.name}}_{{forloop.counter}}" class="date-selection" name="{{widget.name}}" 
    {% if option.attrs.disabled %}disabled{% endif %}
    {% if option.attrs.selected %}checked{% endif %}
    value="{{option.description}}" type="radio">
<label for="{{widget.name}}_{{forloop.counter}}">{{option.description|parse_date|date:"DATE_FORMAT"}}</label>
{% endfor %}
</div>
{% endblock %}

Mais inconvénient de ce type de champ, en page de récap, c'est la valeur rélle qui est affichée, ça sera ici yyyy-mm-dd.

Et donc nécessité de passer par un vrai champ date pour contrer ça, ou d'inclure un attribut "text" dans la source de données. Mais si on en est là, autant formater cet attribut comme on le souhaite, dès le début, c'était en tout cas mon ressenti plus haut.

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

Déjà peut-être remonter plus haut, on parle de date et on a déjà un champ de type date. Mais on n'a pas la possibilité de le limiter à certaines dates. Considère-t-on ça ?

Pourquoi pas, il faudrait cependant veiller à la présentation : on est ici sur de la prise de rendez-vous, donc il faut limiter, mais surtout afficher les possibilités.

Mais en dehors de ça, en fait, la demande de tout départ du client, finalement c'est un choix sur 3 ou 4 dates, donc boutons radios et ça ira très très bien -- ce que je ne savais pas, car je pensais qu'il fallait choisir parmi 30 dates sur les mois à venir, d'où ma proposition à Emmanuel de rendre l'affaire "générique" et donc proche d'un chrono/meetings avec un choix parmi un ensemble de dates.

Vu l'âge et le dernier commentaire, je fermerais bien ce ticket. Ok ?