Autre #9518
MandayeJS : Structure des "Sites"
0%
Description
Le mandayeJS a actuellement la structure suivante
mandayejs
├── locale
│ └── fr
│ └── LC_MESSAGES
├── mandaye
│ ├── management
│ │ └── commands
│ ├── migrations
│ ├── static
│ └── templates
│ ├── mandaye
│ └── registration
└── sites
├── montpellier3m
│ └── static
│ └── montpellier3m
│ └── mediatheques
│ ├── css
│ ├── fonts
│ ├── images
│ └── js
└── vincennes
└── static
└── vincennes
├── biblio
│ ├── css
│ ├── font
│ ├── images
│ └── js
└── conservatoire
├── css
├── font
├── images
└── js
Soit un dossier client contenant les statics de chaque applications Dans le cas où il faudrait développer un webservice par application, le mieux serait de :
- Avoir un seul urls.py et un seul views.py par client, avec dans urls.py ,comme dans passerelle, un mecanisme active l'url si un parametre du type SITE_API_<VINCENNES_CONSERVATOIRE>_ENABLED = True
- Avoir dans sites , des app django par applications ( dueonext, archimed, ...) contenant un urls.py et views.py en plus des statics pour chaque client utilisant cet application. En résumé j'aurai pas exemple une application django duonext, archimed ...
?
Historique
Mis à jour par Benjamin Dauvergne il y a plus de 8 ans
J'ai du rater un truc, pourquoi est-ce qu'on se sert de static différents pour chaque client ? Pour moi il n'y a qu'un JS plus ou moins spécifique par client, il y a plus ? S'il y a du style il faudrait essayer de le garder coté publik-base-them.
De quel web service par client parle-t-on: des proxys de web-service pour récupérer la liste des prêts comme à montpellier ou d'autre chose ?
Mis à jour par Josué Kouka il y a plus de 8 ans
Oui il y'a plus. Il y'a :J'ai du rater un truc, pourquoi est-ce qu'on se sert de static différents pour chaque client ? Pour moi il n'y a qu'un JS plus ou moins spécifique par client, il y a plus ?
- Un (ou une liste de) js lié à la barre mandaye par client. Ce js inject le css de la barre mandaye
- Un js lié à la page d'association de compte (si besoiin)
De quel web service par client parle-t-on: des proxys de web-service pour récupérer la liste des prêts comme à montpellier ou d'autre chose ?
Je parle du web-service pour récupérer la liste des prêts comme à montpellier
Ma question de savoir quel serait la meilleure structure pour pouvoir gerer un cas où pour un client on a un web-service par application : 1 web-service pour la mediathqeques, 1 web-service pour le conservatoire, ...
Mis à jour par Frédéric Péters il y a plus de 8 ans
Ma question de savoir quel serait la meilleure structure pour pouvoir gerer un cas où pour un client on a un web-service par application : 1 web-service pour la mediathqeques, 1 web-service pour le conservatoire, ...
À cette question, ma réponse c'est qu'on peut zapper le niveau "client" pour avoir juste le niveau "application", i.e. sites/duonet/, sites/whatever/, etc. (et si jamais un duonet se retrouvait ne pas ressembler à l'autre, on ferait duonet-vincennes, etc.). Un seul niveau, donc.
D'un autre côté, traiter le style de la barre Mandaye comme un thème, quelque chose de parallèle, et là il peut y avoir vincennes, montpellier, etc. Et cette partie disparaitra à un moment, intégrée dans la mécanique générale des thèmes (publik-base-theme et cie).
Mis à jour par Benjamin Dauvergne il y a plus de 8 ans
Josué Kouka a écrit :
Oui il y'a plus. Il y'a :J'ai du rater un truc, pourquoi est-ce qu'on se sert de static différents pour chaque client ? Pour moi il n'y a qu'un JS plus ou moins spécifique par client, il y a plus ?
- Un (ou une liste de) js lié à la barre mandaye par client. Ce js inject le css de la barre mandaye
Ça devrait être le même js partout, seule la CSS devrait différer.
- Un js lié à la page d'association de compte (si besoiin)
Idem.
De quel web service par client parle-t-on: des proxys de web-service pour récupérer la liste des prêts comme à montpellier ou d'autre chose ?
Je parle du web-service pour récupérer la liste des prêts comme à montpellier
Ma question de savoir quel serait la meilleure structure pour pouvoir gerer un cas où pour un client on a un web-service par application : 1 web-service pour la mediathqeques, 1 web-service pour le conservatoire, ...
Je penche pour un système de plugin à la passerelle, en essayant de garder l'activation coté hobo pour ne pas avoir à faire de page de gestions dans mandaye, on pourrait s'en sortir avec une simple liste de template comme pour combo (user-portal, agent-portal, etc.. ici on aurai imuse-duonext, archimed, etc..).
Pour chaque type de "mandaye" on active un certain plugin via le choix du template, et donc par exemple on aurait une URL "^_manday/ws/.*$", qui passerait la requête à l'application activée par le template choisi:
from django.apps import apps
def ws(request):
if settings.MANDAYE_TEMPLATE:
try:
app = apps.get_app_config('mandaye.apps.%s' % settings.MANDAYE_TEMPLATE)
except LookupError:
pass
else:
return app.ws_view(request)
raise Http404
Ça nous force à maintenir coté hobo la liste des applications disponibles dans mandaye, ça ne me parait pas déconnant.
Mais il faut bien voir qu'il a a deux axes de configurations:- le client, qui ne devrait déterminer que le style (CSS donc),
- et l'application, qui va déterminer le mode d'intégration (nom des champs de la page de login, etc..) et les web-services disponibles.
Il faut éviter de mélanger les deux pour ne pas refaire deux fois la même intégration pour la même application dans deux villes différentes. Si j'indique dans hobo que l'application derrière mandaye est un portail duonet ça devrait faire les bons choix de JS et de web-services automatiquement, ensuite ça devrait récupérer le thème depuis publik-base-theme ou le combo portail usager, sur ce point je ne sais pas trop, l'intégration complète du thème n'étant pas généralement possible.
Mis à jour par Josué Kouka il y a plus de 8 ans
Il y'a surement un point que je n'ai pas saisi. Mais il me semble que le style de la barre mandaye est relatif au client.
Ça devrait être le même js partout, seule la CSS devrait différer.
Il y'a bien un js commun (http://git.entrouvert.org/mandayejs.git/tree/mandayejs/mandaye/static/mandaye.js) avec une CSS (http://git.entrouvert.org/mandayejs.git/tree/mandayejs/mandaye/static/mandaye.css) par defaut. Le(s) js dont j'ai parlé permet(tent) de styliser cette barre mandaye pour le client en question. Dans le cas de Vincennes, il y'a js (duonet.js) qui ajoute un logo et des icones.
Ensuite, il y'a le fait que ce sera la meme barre utilisée pour toutes les applications "mandayisés" du client
Idem pour le style de la page d'association
et l'application, qui va déterminer le mode d'intégration (nom des champs de la page de login, etc..) et les web-services disponibles.
Le mode d'intregation est définit dans le settings.json. Ce dont je ne suis pas sure que ce soit relatif à l'application (duonet, imuse) que l'on mandayise. Encore dans le cas de vincennes, je pense qu'ils ont demandé d'ajouter un champs ou que vincennes est sur une version plus vieille (comparaison http://new.extranet.duonet.fr/Connect.aspx?key=CV4j27Em0dM= et https://duonet.fr/ sqchant que http://new.extranet.duonet.fr/ redirige vers https://duonet.fr/).
Pour l'instant je ne vois pas trop comment avoir un thème générique où je ne sais juste pas trop comment faire.
Mis à jour par Benjamin Dauvergne il y a plus de 8 ans
S'il y a des textes à personnaliser, il faut utiliser des variables (settings nommé TEMPLATE_VARS, alimenté par les variables expotés par hobo, et diffusé par un context_processor dans les templates, voir hobo/context_processors.py et hobo/multitenant/settings_loader.py).
Si ce sont des images, il faut utiliser un fichier CSS, mais en aucun cas les templates ne devraient changer. Si tu entrevois un problème que ces deux solutions ne supportent pas, expose le ici. Le JS ne doit pas servir à personnaliser la barre, juste à définir son comportement et ce soit donc être le même partout.
Normalement les paramètres d'intégration sont uniquement fonction de l'application (et éventuellement de sa version, mais je n'ai rien contre des /apps/duonet2014, /apps/duonet2015, etc..), tu pourrais avoir des AppConfig de cette forme:
class Duonet2014AppConfig(AppConfig):
AUTH_CHECKER = ...
CSS = ...
JS = ...
etc...
ça enlèvera une bonne partie de la configuration manuelle sur ces histoires dans les settings, le choix d'utiliser un module en particulier pourra être fait en fonctionn soit d'une variable de settings explicite MANDAYE_TEMPLATE soit d'une variable template_name dans settings.TEMPLATE_VARS; comme cela on gère un fonctionnement manuel et via hobo.
Mis à jour par Josué Kouka il y a plus de 8 ans
Dans TEMPLATE_VARS ( client )
* SITE_CA_URL * SITE_SCRIPTS * SITE_ASSOCIATE_STATIC * SITE_STATIC_ROOT_PATH
Dans AppSettings ( application )
* SITE_LOGIN_PATH * SITE_HOME_PATH * SITE_LOCATORS * SITE_AUTH_CHECKER * SITE_AUTH_COOKIES * SITE_FORM_SUBMIT_ELEMENT