Extension
Packaging
Une extension peut-être packagée en différents modules :
- Un module contenant les mécanismes java (exemple : actualite-core);
- Un module contenant les écrans de contribution back-office (exemple : actualite-webapp-contrib);
- Un module contenant les écrans utilisés en front-office (exemple : actualite-webapp-front);
- Un module pour l'API si l'extension expose des données via l'API K-Sup (exemple : actualite-api).
Chargement et déclaration
L'extension est chargée dans l'application via les mécanismes liés à Spring en créant un contexte dédié. Afin d'isoler les différents projets et extensions, le chargement des contextes doit toujours respecter une relation parent / enfant avec l'extension "Core" qui est l'extension de plus bas niveau. Toutes les extensions ont accès aux fonctionnalités et objets de ce contexte Core. En revanche, le Core ne doit pas référencer de fonctionnalités des extensions et les extensions ne doivent pas se référencer entres elles.
Chaque déclaration d'extension est matérialisée comme étant un bean de type {@link com.kportal.extension.IExtension}, qui est porté par ce contexte fils qui est initialisé dans la classe {@link com.kportal.extension.ExtensionConfigurer}. Ce traitement est responsable de la découverte des différents contextes Spring d'extensions (par convention : /extensions/idextension/ExtensionContext.xml). Pour le module Core, la déclaration est présente dans le fichier CoreContext.xml.
Ajoute de contrôleurs Spring MVC
Les extensions peuvent déclarer leurs propres contrôleurs afin d'exposer des fonctionnalités. Ces contrôleurs sont alors chargés dans le contexte propre de l'extension afin de pouvoir utiliser les fonctionnalités de l'extension (service java par exemple). Afin d'identifier les différents modules dans les URLs, les contrôleurs de chaque extension seront préfixées par un identifiant propre à l'extension (par exemple : www.univ-kosmos.fr/mon-extension/url-controller).
Activation et configuration
L'activation et la configuration des contrôleurs se fait via l'édition d'objet héritant de IExtensionServlet. Il est alors possible d'éditer les propriétés suivantes :
| Propriété | Description | Valeurs possibles | Valeur par défaut |
|---|---|---|---|
| servletDispatcherEnabled | Activation du Dispatcher Servlet | Booléen (true, false) | false |
| dispatcherServletBaseUrl | Préfixe des URLs de contrôleurs de l'extension | Chaîne de caractères | idenfiant de l'extension |
| servletPriority | Permet de définir un ordre dans le chargement de la servlet de cette extension par rapport aux autres extensions | integer | com.kportal.extension.IExtensionServlet#EXTENSION_SERVLET_PRIORITY |
| servletName | Nom de la servlet utilisée dans la déclaration Spring (pas utile à modifier) | Chaîne de caractères | idExtensionDispatcherServlet |
Pour chaque extension, il faut également qu'il y ait la configuration d'un objet implémentant org.springframework.web.servlet.HandlerMapping associé. Cela peut être configuré de plusieurs manières :
- Ajouter l'annotation @EnableWebMvc sur une classe ayant l'annotation @Configuration scannée dans le contexte de l'extension;
- Une @Configuration scannée dans l'extension peut étendre la classe org.springframework.web.servlet.config.annotation.WebMvcConfigurationSupport.
Chaque extension peut également étendre son comportement MVC en important dans le contexte des Configurations étendant l'interface org.springframework.web.servlet.config.annotation.WebMvcConfigurer. Il est ainsi possible de configurer Tiles avec l'import de com.kosmos.context.CommonTilesConfig.
@Configuration
@Import(CommonTilesConfig.class)
@EnableWebMvc
public class MonExtensionConfig {
//
}