Dans ce chapitre, nous allons décrire la philosophie d'organisation d'une webapp lutece de manière très simplifiée. Les notions seront ensuite approfondies dans la suite du livre. Il s'agit ici de donner des repères au lecteur qui aideront la compréhension des chapitres suivants.
Lorsqu'une webapp est déployée dans un conteneur de servlet, l'intégralité des fonctions du site sont accessibles depuis les URLs de cette webapp, par exemple http://www.example.com/webapp-example/ que l'on abrégera <webapp> dans la suite de ce chapitre.
On distingue d'emblée dans Lutece deux parties qui sont totalement séparées:
* Le front office, destiné au public : URLs sous <webapp>/jsp/site/
* Le back office, destiné aux administrateurs : URLs sous <webapp>/jsp/admin/
La quasi-totalité des contenus html du Front Office sont accessible à l'URL <webapp>/jsp/site/Portal.jsp. Le contenu de la page est déterminé par les paramètres de la requete HTTP. Par exemple:
Les différents paramètres HTTP servent à utiliser différents Content Services que nous découvrirons plus tard dans ce livre. Lorsqu'il n'y a pas de paramètres HTTP, c'est le PageContentService ("page_id=XX") qui est utilisé et qui renvoie le contenu de sa page racine (par défaut page_id=1, mais configurable).
Note: ces URLs techniques peuvent être remplacées par des URLs explicites en utilisant le plugin-seo (exemple: <webapp>/home.html pour <webapp>/jsp/site/Portal.jsp?page_id=1, ou <webapp>/sitemap.html pour <webapp>/jsp/site/Portal.jsp?page=map)
L'accueil du back office est accessible à l'URL <webapp>/jsp/admin/AdminMenu.jsp. Contrairement au contenu du Front Office accessible par le fichier Portal.jsp, les différentes fonctionnalités du back office sont accessible par leurs propres fichiers ".jsp", par exemple:
L'accès au Back Office nécéssite une authentification. Les liens vers les différents contenus sont ajoutés dynamiquement dans la page d'accueil en fonction des droits et des rêles de l'utilisateur back office.
Note: Nous parlons ici du méchanisme d'authentification Back Office. Il existe également un mécanisme d'authentification Front Office optionnel (plugin mylutece). Ces deux mécanismes ne doivent pas être confondus: ils sont indépendants et les deux populations d'utilisateurs totalement séparées.
L'architecture modulaire de Lutece s'appuie sur la distinction entre le coeur et les plugins.
Le coeur fournit un framework avec lequel les plugins apportent des fonctionnalités.
Les avantages sont de permettre une homogénéisation tant au niveau de l'implémentation que de l'interface utilisateur, sans surcharger de complexité tous les cas d'utilisation.
Les principes de développement et d'organisation du code sont partagés entre le coeur et les plugins. Par exemple, le coeur et le plugin-document implémentent tous les deux des Content Services selon la même architecture.
Dans la suite de ce livre, nous décrirons tantôt des fonctionnalités du coeur, tantôt des fonctionnalités de plugins, car les principes restent globalement les mêmes.
Dans la terminologie Lutece, en plus du coeur et des plugins, il existe aussi un autre type de composant: les modules.
Leur rôle est d'implémenter ou de spécialiser des fonctionnalités d'un plugin. Il s'agit d'une convention de nommage, car leur comportement est identique à celui d'un plugin. Un exemple d'implémentation de ce type de composant est le module mylutece-database dont le role est d'implémenter les fonctionnalités d'authentification du plugin-mylutece en se basant sur des utilisateurs stockés dans la base de données locale. Dans le cas où la webapp Lutece doit être protégée par une authentification de type SSO, partagée entre plusieurs sites, ce module peut etre substitué par un module d'authentification SSO, tel que le module mylutece-cas ou mylutece-openam qui interagissent avec des serveurs distants d'authentification.
Il y a une erreur de communication avec le serveur Booktype. Nous ne savons pas actuellement où est le problème.
Vous devriez rafraîchir la page.