Produits Entr'ouvert » Intégrations graphiques Publik

Comment tu assures le changement 4 sans rien casser ? i.e. il n'y aurait pas à déplacer la reprise de l'existant avant ça ?

2- Isoler son code HTML dans un fichier propre (include) permettant ainsi plus facilement de l'insérer à d'autres endroits dans le template (Il est souvent placé visuellement au-dessus du header) mais également de retrouver plus facilement les thèmes qui le surcharge.

Ça n'est plus vraiment une question sur le plan général (qui j'imagine aura des tickets individuels par étape), mais je ne vois pas trop comment tu envisages les choses ici, j'ai l'impression que ça change juste déplacer {% block user-info }{ endblock } en déplacer un { include "user_info.html" %} ?

L'ordre n'est pas fixe, certaines étapes seront peut-être à faire avant d'autres (5 avant 4 par ex.)

Comment tu assures le changement 4 sans rien casser ?

C'est pour cela que j'ai mis un point d'interrogation à la fin :).
De visu je pensais essayer de remplacer la balise span.logged-in et la balise span.login par des balises ul, et wrapper chaque lien d'une balise li.
Puis de forcer ul et li en `display: inline` pour que le core génère le même layout en sorti.
Il y aura peut-être quelques retouches au niveau des thèmes à faire en même temps (étape 7).
Avec l'idée de faire évoluer le markup, se pose déjà le problème de la balise séparatrice `span.sep`, l'exemple suivant n'étant pas valable

 <ul class="login">
    <li>
      <a accesskey="2" href="{% url 'auth_login' %}">Connexion</a>
    </li>
    <span class="sep">/</span>
    <li>
      <a class="registration" href="{{idp_registration_url}}">Inscription</a>
    </li>
</ul>

Il faudra donc peut-être s'occuper du point 5 avant.
Si trop compliqué, une autre solution pour améliorer l'accessibility serait de se retourner vers les attributs aria role= list || listitem. Mais il faudra quand même une évolution du markup et je préférerais tenter la première.

j'ai l'impression que ça change juste déplacer {% block user-info }{ endblock } en déplacer un { include "user_info.html" %} ?

C'est juste, on pourrait insérer le code ailleurs en déplaçant {% block user-info } dans theme.html (qui demande aussi des aménagements pour le faire). Mais on continuerait à surcharger le bloc depuis page_template.html et je trouve plus claire pour la maintenance des themes que toutes les surcharges de ce bloc se fassent à travers un fichier dédié.
Dans les 2 cas il y un peu de retouche du markup à faire. Aujourd'hui déplacer { block user-info %} ne déplace pas son wrapper #toplinks qui lui donne son style et revoir aussi la position de la condition `if include_top_links` par exemple.

(qui j'imagine aura des tickets individuels par étape)

Oui c'est l'idée. Mais en débattre ici et maintenant pour évaluer la pertinence de chaque étape c'est bien aussi.

Ce qui me préoccupe donc surtout est l'ordre des choses, éviter d'avoir un moment "et là il faut tout faire partout", à remonter les choses je vois même deux approches différentes possibles :

• des étapes globales qui sont à appliquer l'une après l'autre, c'était dans ce sens que j'avais ma question "il n'y aurait pas à déplacer la reprise de l'existant avant ça ?"

• et/ou une approche qui permet d'avoir l'objectif en place, sur de nouvelles intégrations, et permettre petit à petit la mise à jour/vérification des anciennes. (l'important étant ici "petit à petit").

Et ça se combine, la progression petit à petit peut se faire pour atteindre un niveau général, qui permet alors une action globale qui aurait autrement cassé quelque chose, et puis une suite à nouveau petit à petit.