Interface graphique

Personnalisation de la GUI

    Getting Started

    Nota : Les fichiers de configuration, mentionnés ci-dessous, doivent être placés dans le répertoire de configuration défini par la propriété de la JVM flower.docs.config.dir. S’il n’existe pas, il est nécessaire de le créer.

    • Les propriétés (clé/valeur) sont à modifier (ou rajouter) dans le fichier de configuration flowerdocs.properties à créer

    Exemple de configuration :

    gui.client.app.name=Flow<i>er</i>Docs
    gui.client.app.desc=Dossiers Entreprise
    gui.client.app.env= DEMO
    
    • Les ajouts de beans Spring XML doivent être réalisés dans le fichier gui-${scope}.xml${scope} est à remplacer par l’identifiant (en minuscule) du scope.

    Par exemple : créer un fichier de configuration vide pour le scope Syldavia:

    	<?xml version="1.0" encoding="UTF-8"?>
    	<beans xmlns="http://www.springframework.org/schema/beans" 
    		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    		xmlns:context="http://www.springframework.org/schema/context"
    		xsi:schemaLocation="http://www.springframework.org/schema/beans
    	       http://www.springframework.org/schema/beans/spring-beans.xsd  
    	       http://www.springframework.org/schema/context
    	       http://www.springframework.org/schema/context/spring-context.xsd">
    	
    		<!-- Placer votre configuration personnalisée ici -->
    	
    	</beans>  
    

    Description de l’instance

    Les propriétés suivantes permettent de définir l’instance déployée, elles sont à ajouter dans le fichier flowerdocs.properties :

    • gui.client.app.name : définit le nom de l’instance
    • gui.client.app.desc : définit la description de l’instance
    • gui.client.app.logo : définit le logo de l’instance
    • gui.client.app.env : définit l’environnement sur lequel est déployée l’instance
    • gui.client.app.style : définit une feuille de style (CSS) personnalisée à appliquer
    • gui.password.change.enabled : activer/désactiver l’action permettant de changer le mot de passe d’un utilisateur

    Actions liées aux composants

    Actions personnalisées

    Il est possible d’ajouter de(s) action(s) personnalisée(s) sur les composants.

    Actions basées sur une URL

    Une action se compose de :

    • un nom, un icone et un titre servant à la présentation.
    • une liste de classes de composant, de phases et d’identités qui vont conditionnée l’affichage de l’action
    • une URL cible pour l’action qui va définir la page qui sera ouverte dans une popup.

    Si la liste d’identités n’est pas renseignée, alors l’action sera visible par tous.

    Plusieurs variables sont mises à disposition pour construire dynamiquement l’URL à ouvrir :

    • l’identifiant de l’utilisateur connecté : user.name
    • les autorités de l’utilisateur connecté : user.authorities
    • un token utilisateur : user.token
    • la valeur d’un tag : tags.tagName (remplacer tagName par le nom du tag souhaité)
    • l’identifiant du composant ouvert : component.id

      <bean id="openARender" class="com.flower.docs.gui.client.action.CustomizedAction">
      	<property name="name" value="VisualizeDocument" />
      	<property name="title" value="Visualisation du document" />
      	<property name="icon" value="fas fa-eye" />
      	<property name="url" value="http://localhost:8080/flower-docs-arender/ARender.jsp?scope=Syldavia&amp;docId=${component.id_value}&amp;token=${user.token}" />
      	<property name="allowedClasses">
      		<list>
      			<bean class="com.flower.docs.domain.common.Id">
      				<property name="value" value="CourrierEntrant" />
      			</bean>
      		</list>
      	</property>
      	<property name="phase">
      		<list>
      			<value type="com.flower.docs.domain.componentclass.Phase">INSERT</value>
      			<value type="com.flower.docs.domain.componentclass.Phase">MODIFY</value>
      		</list>
      	</property>
      	<property name="principal">
      	<list>
      	<value>ADMIN</value>
      	<value>adg</value>
      	</list>
      	</property>
      </bean>
      

    Pour que cette action soit disponible, il faut la définir dans le catalogue d’action dédié :

    <bean id="customizedActions" class="com.flower.docs.gui.client.action.CustomizedActionCatalog">
    	<property name="actions">
    		<list>
    			<ref bean="openARender" />
    		</list>
    	</property>
    </bean>
    

    Actions basées sur une fonction JavaScript

    Ce type d’action permet d’exécuter une fonction JavaScript. Pour utiliser ce type d’action, la configuration nécessaire est la suivante :

    • name : Nom de l’action
    • buttonStyle : Style de l’action correspondant à un icone FontAwesome
    • title : Libellé affiché dans le conteneur d’action
    • javaScriptFunction : Nom de la fonction JavaScript à exécuter lorsque l’utilisateur clique sur l’action

    La fonction JavaScript doit prendre en paramètre la catégorie de composant, la phase d’ouverture et un tableau d’identifiants de composant :

    function exportToCRM(category, phase, componentIds){
    	// Ajax request allowing to export a component to an external CRM
    }
    

    Attention : Si cette fonction est définie dans un fichier JavaScript personnalisé, il est nécessaire d’enregistrer cette fonction au niveau de l’objet window :

    window.exportToCRM = exportToCRM;
    
    function exportToCRM(category, phase, componentIds) {
    	console.log("Exporting category=" + category + ", phase=" + phase + ", component ids=" + componentIds);
    }
    

    Exemple : Définition d’une action permettant d’exécuter une fonction JavaScript

    <bean id="exportToCRM" class="com.flower.docs.gui.client.component.action.JavaScriptComponentAction">
    	<constructor-arg value="ExportToCRM" />
    	<property name="title" value="Export to CRM" />
    	<property name="buttonStyle" value="far fa-file" />
    	<property name="javaScriptFunction" value="exportToCRM" />
    </bean>
    

    Actions basées sur une activité

    Ce type d’action va permettre d’ouvrir différents écrans dans une popup:

    • Ecran de création avec vérification
    • Ecran de modification de composants

    La popup est personnalisable de la façon suivante :

    • icon : icone de la popup
    • style : style de la popup
    • title : titre de la popup
    • description : description de la popup
    • place : la place correspondant à l’écran voulu

    Le titre du bouton va être défini en le passant en paramètre à l’action.

    Ecran de création avec vérification

    La place de création avec vérification va être construite à l’aide d’un identifiant de template de recherche et de la catégorie de composant ci-dessous :

    <bean class="com.flower.docs.gui.client.activity.action.ActivityActionPresenter">
    	<constructor-arg type="java.lang.String" value="Créer une enveloppe" />
    	<constructor-arg>
    		<bean class="com.flower.docs.gui.client.search.CreateWithVerificationPlace">
    			<property name="id">
    				<bean class="com.flower.docs.domain.common.Id">
    					<property name="value" value="EnvelopeSearchWithoutDescription" />
    				</bean>
    			</property>
    			<property name="category">
    				<value type="com.flower.docs.domain.component.Category">TASK</value>
    			</property>
    		</bean>
    	</constructor-arg>
    	
    	<property name="style" value="envelope" />
    	<property name="icon" value="envelope fas fa-envelope" />
    	<property name="title" value="Création d'enveloppe" />
    	<property name="description" value="Avant de créer une enveloppe, merci de vérifier que celle-ci n'existe pas déjà" />
    </bean>
    

    Ecran de modification d’un composant

    Une place de modification de composant va permettre de visualiser les métadonnées de celui-ci. Toutes ces places sont construites de la même façon, avec l’identifiant du composant et la propriété supportVisualisation (sauf pour les dossiers).

    Dossier virtuel

    <bean class="com.flower.docs.gui.client.activity.action.ActivityActionPresenter">
    	<constructor-arg type="java.lang.String" value="Bannette collective" />
    	<constructor-arg>
    		<bean class="com.flower.docs.gui.client.virtualfolder.modify.ModifyVirtualFolderPlace">
    			<constructor-arg>
    				<bean class="com.flower.docs.domain.common.Id">
    					<property name="value" value="My_Virtual_Folder_Id" />
    				</bean>
    			</constructor-arg>
    			<property name="supportVisualisation" value="false" />
    		</bean>
    	</constructor-arg>
    	<property name="style" value="bannette" />
    	<property name="icon" value="bannette fas fa-envelope" />
    	<property name="title" value="Bannette collective" />
    </bean>
    

    Tâche

    <bean class="com.flower.docs.gui.client.activity.action.ActivityActionPresenter">
    	<constructor-arg type="java.lang.String" value="Enveloppe" />
    	<constructor-arg>
    		<bean class="com.flower.docs.gui.client.task.modify.ModifyTaskPlace">
    			<constructor-arg>
    				<bean class="com.flower.docs.domain.common.Id">
    					<property name="value" value="My_Task_Id" />
    				</bean>
    			</constructor-arg>
    			<property name="supportVisualisation" value="false" />
    		</bean>
    	</constructor-arg>
    </bean>
    

    Document

    <bean class="com.flower.docs.gui.client.activity.action.ActivityActionPresenter">
    	<constructor-arg type="java.lang.String" value="Facture" />
    	<constructor-arg>
    		<bean class="com.flower.docs.gui.client.document.modify.ModifyDocumentPlace">
    			<constructor-arg>
    				<bean class="com.flower.docs.domain.common.Id">
    					<property name="value" value="My_Document_Id" />
    				</bean>
    			</constructor-arg>
    			<property name="supportVisualisation" value="false" />
    		</bean>
    	</constructor-arg>
    </bean>
    

    Dossier

    <bean class="com.flower.docs.gui.client.activity.action.ActivityActionPresenter">
    	<constructor-arg type="java.lang.String" value="Mes factures" />
    	<constructor-arg>
    		<bean class="com.flower.docs.gui.client.folder.modify.ModifyFolderPlace">
    			<constructor-arg>
    				<bean class="com.flower.docs.domain.common.Id">
    					<property name="value" value="My_folder_Id" />
    				</bean>
    			</constructor-arg>
    		</bean>
    	</constructor-arg>
    </bean>
    

    Configuration en fonction du contexte

    Définition du contexte

    Le formulaire d’un composant a plusieurs conteneurs d’action personnalisables :

    • celui contenant les actions natives (supprimer, attacher, télécharger…) : headerActions
    • celui dédié au déclenchement de tâche : taskActions

    La configuration par défaut d’un conteneur peut être modifiée en définissant un bean Spring Beans dont l’identifiant est composé de la manière suivante :

    • Nom de l’objet graphique : headerActions, taskActions
    • Type de composant : Document, Task, Folder ou VirtualFolder
    • Phase : Insert, ReadOnly, Modify

    Exemple : Dans le cas de la modification des actions lors de la modification d’un composant, le nom du bean à définir est headerActionsDocumentModify`.

    Ajout d’une action personnalisée

    Afin d’ajouter une action personnalisée dans un conteneur d’action, il est nécessaire de :

    • connaitre l’identifiant du conteneur en fonction du contexte (cf. partie ci-dessus)
    • repérer le bean en fonction de cet identifiant dans la configuration XML ou le définir tel que :

      <bean id="identifiant-du-conteneur" class="classe-definissant-le-type-de-conteneur"
      scope="prototype">
      	<property name="actions">
      		<list>
      		</list>
      	</property>
      </bean>
      

    Pour ajouter une action personnalisée, il est ensuite nécessaire de la référencer à l’aide de son identifiant et de la balise <ref bean="identifiant-action"/>.

    Exemple : Ajout d’une action personnalisée exportToCRM lors de la modification d’un document

    <bean id="headerActionsDocumentModify" class="com.flower.docs.gui.client.component.action.ComponentHeaderActions" 
    scope="prototype">
    	<property name="actions">
    		<list>
    			<bean class="com.flower.docs.gui.client.component.action.DeleteComponentAction" />
    			<ref bean="exportToCRM"/>
    		</list>
    	</property>
    </bean>
    

    Déclenchement de tâche

    Un type de widget graphique permet l’ajout d’actions permettant la création de tâche depuis un composant: taskActions.

    Les actions sont affichées seulement :

    • si l’utilisateur a la permission CREATE sur le composant
    • si la classe du composant est autorisée en tant que fille de la classe de tâche à créer

    Deux objets sont mis à disposition :

    • par défaut : l’ensemble des tâches que l’utilisateur a la possibilité de créer à partir du composant ouvert

    • com.flower.docs.gui.client.component.action.CustomComponentActionsPresenter pour définir manuellement les tâches que les utilisateurs pourront créer.

    Dans l’exemple ci-dessous, les classes de tâche Move et Copie ont été définies :

    <!-- taskActions widget configuration int document modification context --> 
    <bean id="taskActionsDocumentModify" class="com.flower.docs.gui.client.component.action.CustomComponentActionsPresenter" 
      scope="prototype">
    	<property name="actions">
    		<list>
    			<bean class="com.flower.docs.gui.client.task.list.CreateTaskAction">
    				<constructor-arg value="Move" />
    			</bean>
    			<bean class="com.flower.docs.gui.client.task.list.CreateTaskAction">
    				<constructor-arg value="Copie" />
    			</bean>
    		</list>
    	</property>
    </bean>
    

    Activation

    Les actions peuvent posséder une stratégie d’activation permettant de définir sur quels critères une action doit être activée ou désactivée. Certaines actions en possèdent une par défaut comme celles permettant la création de tâches, d’autres non.

    Différentes stratégies sont fournies nativement.


    Liée à une permission

    • En fonction d’une permission : ComponentPermissionEnablingStrategy afin de n’activer une action que si l’utilisateur connecté possède la permission UPDATE_CONTENT sur le composant du formulaire

    Exemple : définition d’une stratégie n’activant une action que si l’utilisateur à la permission UPDATE_CONTENT sur le composant ouvert

    <bean class="com.flower.docs.gui.client.component.action.ComponentPermissionEnablingStrategy">
    	<constructor-arg>
    		<value type="com.flower.docs.domain.acl.Permission">UPDATE_CONTENT</value>
    	</constructor-arg>
    </bean>	
    

    En fonction des tags

    La stratégie TagBasedEnablingStrategy peut être utilisée afin de restreindre l’activation d’une action en fonction des tags d’un composant.

    Exemple 1 : définition d’une stratégie n’activant une action que si la valeur du tag Assignee est égale à l’identifiant de l’utilisateur connecté

    <bean class="com.flower.docs.gui.client.component.action.TagBasedEnablingStrategy">
    	<property name="requiredTags">
    		<list>
    			<bean class="com.flower.docs.domain.component.Tag">
    				<property name="name" value="Assignee" />
    				<property name="value">
    					<list>
    						<value>${user.id}</value>
    					</list>
    				</property>
    			</bean>
    		</list>
    	</property>
    </bean>
    

    Exemple 2 : définition d’une stratégie n’activant une action que si le composant ouvert possède une autre valeur que celles définies pour le tag Assignee

    <bean class="com.flower.docs.gui.client.component.action.TagBasedEnablingStrategy">
    	<property name="valueOperator">
    		<value type="com.flower.docs.domain.search.Operators">DIFFERENT</value>
    	</property>		
    	<property name="requiredTags">
    		<list>
    			<bean class="com.flower.docs.domain.component.Tag">
    				<property name="name" value="Assignee" />
    				<property name="value">
    					<list>
    						<value>Comptables</value>
    						<value>RH</value>
    					</list>
    				</property>
    			</bean>
    		</list>
    	</property>
    </bean>
    


    La stratégie EmptyTagEnablingStrategy peut être utilisée afin de n’activer une action que si le composant possède un tag donné vide.

    Exemple : définition d’une stratégie n’activant une action que si le composant ouvert possède le tag Assignee sans aucune valeur

    <bean class="com.flower.docs.gui.client.component.action.EmptyTagEnablingStrategy">	
    	<property name="tag" value="Assignee"/>
    </bean>
    

    En fonction de plusieurs EnablingStrategy

    La stratégie EnablingStrategyWrapper afin de composer une stratégie complexe basée sur plusieurs critères.

    Exemple : définition d’une stratégie n’activant une action que si le composant ouvert possède le tag Assignee sans aucune valeur ainsi que la permission UPDATE_CONTENT

    <bean class="com.flower.docs.gui.calyx.action.EnablingStrategyWrapper">	
    	<property name="strategies">
    		<list>
    			<bean class="com.flower.docs.gui.client.component.action.EmptyTagEnablingStrategy">	
    				<property name="tag" value="Assignee"/>
    			</bean>
    			<bean class="com.flower.docs.gui.client.component.action.ComponentPermissionEnablingStrategy">
    				<constructor-arg>
    					<value type="com.flower.docs.domain.acl.Permission">UPDATE_CONTENT</value>
    				</constructor-arg>
    			</bean>
    		</list>
    	</property>
    </bean>
    


    Une stratégie d’activation se positionne sur une action grâce à la propriété enablingStrategy. Dans le cas où une action n’a pas de stratégie d’activation, celle de son conteneur est utilisée. Cette dernière peut également être surchargée grâce à la même propriété.

    Exemple :

    <bean id="exportToCRM" class="com.flower.docs.gui.client.component.action.JavaScriptComponentAction">
    	<constructor-arg value="ExportToCRM" />
    	<property name="title" value="Export to CRM" />
    	<property name="buttonStyle" value="far fa-file" />
    	<property name="javaScriptFunction" value="exportToCRM" />
    	
    	<property name="enablingStrategy" ref="updateContenPermissionEnabling" />
    </bean>
    	
    <bean id="updateContenPermissionEnabling" 
    class="com.flower.docs.gui.client.component.action.ComponentPermissionEnablingStrategy">
    	<constructor-arg>
    		<value type="com.flower.docs.domain.acl.Permission">UPDATE_CONTENT</value>
    	</constructor-arg>
    </bean>
    

    En fonction des tags dates

    La stratégie DateTagEnablingStrategy est utilisée afin d’activer une action seulement si le composant possède un tag de type Date dont la valeur correspond à la règle définie. Pour activer cette action, il faut utiliser la configuration suivante :

    • condition : Tag de type Date sur lequel la stratégie d’activation est basée. Il est possible de renseignée la valeur ${dayDate} correspondant à la date du jour
    • shouldBeLess : Préciser si la date doit être supérieur ou inférieur à la date renseignée (false par défaut)
    • daysInterval : Le nombre de jours de tolérance. Si non renseignée, la valeur du tag du composant sera évaluée par rapport à la valeur de la condition et la valeur de la propriété shouldBeLess

    Exemple : définition d’une stratégie n’activant une action que si le composant ouvert possède le tag ReceivedDate qui est supérieur de la date du jour.

    <bean id="dateEnablingStrategy" class="com.flower.docs.gui.client.component.action.DateTagEnablingStrategy">
    	<property name="condition">
    		<bean class="com.flower.docs.domain.component.Tag">
    			<property name="name" value="ReceivedDate" />
    			<property name="value" >
    				<list>
    					<value>${dayDate}</value>
    				</list>
    			</property>				
    		</bean>
    	</property>
    	<property name="shouldBeLess" value="false"/>
    </bean>
    

    Redirection

    En fonction d’une action ou d’un conteneur d’action, une redirection peut être configurée. Il s’agit de définir vers quel écran, l’utilisateur sera redirigé après l’exécution d’une action.

    Pour appliquer une configuration particulière, il est nécessaire de définir la propriété redirectionStrategy commme suit :

    • Pour aucune redirection : NoRedirectionStrategy
    • Rechargement de l’écran courant : ReloadRedirectionStrategy
    • Aller à l’écran précédent : GoBackRedirectionStrategy
    • Aller sur un écran particulier : PlaceRedirectionStrategy

    Exemple : rediriger l’utilisateur sur l’écran précédant lorsqu’il crée une tâche depuis l’écran d’indexation d’un document

    <bean id="taskActionsDocumentModify" class="com.flower.docs.gui.client.task.list.ComponentTaskActionsPresenter" 
    scope="prototype">
    	<property name="redirectionStrategy" ref="goBackRedirection" />
    </bean>
    <bean id="goBackRedirection" class="com.flower.docs.gui.client.action.redirect.GoBackRedirectionStrategy" />
    

    Contenu d’un dossier

    Afin de modifier l’affichage des données des documents, dossiers et dossier virtuels contenus dans un dossier, le bean folderSearchCatalog est utilisé. Il est composé de 3 propriétés :

    • documents, qui permet de configurer l’affichage des documents fils
    • folders, qui permet de configurer l’affichage des dossiers fils
    • virtualFolders, qui permet de configurer l’affichage des dossiers virtuels fils

    Ces 3 propriétés fonctionnent de la même façon :

    • une requête request.
    • une liste de colonnes cachées hiddenColumns. Par défaut les identifiants de documents sont récupérés puis cachés afin de récupérer uniquement les données demandées lors de la recherche

    Par défaut dans le fichier flower-docs-gui-client.xml, le catalogue folderSearchRequest est utilisé et permet l’affichage des noms, des classes de documents, date de création ainsi que la date de dernière modification.

    Exemple :

    <bean id="folderSearchCatalog" class="com.flower.docs.gui.client.search.folder.FolderChildrenTableCatalog" scope="prototype">
    	<property name="documents">
    		<bean class="com.flower.docs.gui.client.search.document.DocumentTablePresenter">
    			<property name="request" ref="folderSearchRequest" />
    			<property name="hiddenColumns">
    				<list>
    					<value>id_value</value>
    					<value>status</value>
    				</list>
    			</property>
    		</bean>
    	</property>
    	<property name="folders">
    		<bean class="com.flower.docs.gui.client.search.folder.FolderTablePresenter">
    			<property name="request" ref="folderSearchRequest" />
    			<property name="hiddenColumns">
    				<list>
    					<value>id_value</value>
    					<value>status</value>
    				</list>
    			</property>
    		</bean>
    	</property>
    	<property name="virtualFolders">
    		<bean class="com.flower.docs.gui.client.search.virtualfolder.VirtualFolderTablePresenter">
    			<property name="request" ref="folderSearchRequest" />
    			<property name="hiddenColumns">
    				<list>
    					<value>id_value</value>
    					<value>status</value>
    				</list>
    			</property>
    		</bean>
    	</property>
    </bean>
    
    <bean name="folderSearchRequest" class="com.flower.docs.domain.search.SearchRequest">
    	<property name="selectClause">
    		<bean class="com.flower.docs.domain.search.SelectClause">
    			<property name="fields">
    				<list>
    					<value>name</value>
    					<value>classid</value>
    					<value>creationDate</value>
    					<value>lastUpdateDate</value>
    				</list>
    			</property>
    		</bean>
    	</property>
    </bean>
    

    La visionneuse

    Configuration minimale

    La HMI ARender doit être vue comme faisant partie du même domaine HTTP par le navigateur client. Si ARender n’est pas dans la même JVM que FlowerDocs alors il est nécessaire de renseigner, au niveau de la JVM FlowerDocs, la propriété flower.docs.config.dir pointant vers un répertoire contenant un fichier de configuration flowerdocs.properties.

    Par défaut, la HMI essaie d’accéder au serveur de rendition http://localhost:8761. Un ou plusieurs autres serveurs de rendition peuvent être définis grâce à la propriété arender.rendition.nodes.

    Exemple de configuration :

    arender.rendition.nodes=http://host1:8761,http://host2:8761
    

    Connecteur par défaut

    La configuration par défaut est suffisante pour utiliser le connecteur par défaut pour ARender.

    Si besoin, il est possible de modifier l’URL à utiliser avec la propriété gui.client.arender.url (défaut : ../flower-docs-arender)


    Il est également possible de surcharger le profile ARender (et ses paramètres) en définissant la propriété : gui.client.arender.profile. La valeur de cette propriété sera rajoutée à l’URL d’appel à ARender.

    Connecteur IBM FileNet

    Configuration cliente :

    Editer le fichier flowerdocs.properties et ajouter les propriétés suivantes :

    • gui.client.arender.params.scope avec la valeur objectStoreName
    • gui.client.arender.params.doc avec la valeur id

    Configuration serveur :

    Pour la communication avec FileNet, il est nécessaire de pousser le subject JAAS avec un login et mot de passe. Il faut donc que le jeton utilisateur permette la récupération du mot de passe, pour cela :

    • Editer le fichier flowerdocs.properties
    • Ajouter/modifier la propriété : token.include.password avec la valeur true

    Dans le cadre d’une intégration avec le moteur IBM FileNet, il peut être nécessaire de définir le paramètre filenet.uri (Valeur par défaut: http://localhost:9080/wsi/FNCEWS40MTOM/).

    Autre connecteur

    Si un connecteur custom est utilisé, il est également possible d’ouvrir ARender avec l’identifiant des fichiers associées aux documentes. Ceci entraîne la résolution des identifiant côté client avant d’ouvrir la visionneuse ARender.

    Editer le fichier flowerdocs.properties et ajouter la propriété suivante :

    gui.client.arender.visualize.files avec la valeur true

    Configuration globale

    Au sein de l’IHM FlowerDocs plusieurs formats de date peuvent être définis :

    • Dans les formulaires grâce à la propriété gui.date.form
    • Dans les colonnes d’un tableau grâce à la propriété gui.date.table
    • Pour les popups d’informations techniques gui.date.technical
    • Pour les autres emplacements grâce à la propriété gui.date.display

    Pour plus d’information concernant les différents formats supportés, il est possible de consulter ceci.

    Exemple :

    Dans un formulaire, pour obtenir des dates du type 01/12/2016, il faut définir la propriété gui.date.form=dd/MM/yyyy. Ce type de date permet notamment de faciliter la saise manuelle des dates sans utiliser l’objet DatePicker.

    Configuration du format de date par classe de tag ou référence de tag

    Dans une classe de tag de type Date ou une référence de tag de type Date, il est possible d’utiliser un format personnalisée de date parmis les formats de date prédéfinis dans l’exemple ci-dessous. L’internalisation du format est gérée par l’application.

    Exemple :

    Les format disponibles sont:

    • ISO_8601

      2018-07-25T17:16:11.381+02:00
      
    • RFC_2822

      Wed, 25 Jul 2018 17:16:11 +0200
      
    • DATE_FULL

      FR: mercredi 25 juillet 2018
      EN: 2018 July 25, Wednesday
      
    • DATE_LONG

      FR: 25 juillet 2018
      EN: 2018 July 25
      
    • DATE_MEDIUM

      FR: 25 juil. 2018
      EN: 2018 Jul 25
      
    • DATE_SHORT

      FR: 25/07/2018
      EN: 2018-07-25
      
    • TIME_FULL

      17:16:11 UTC+2
      
    • TIME_LONG

      17:16:11 UTC+2
      
    • TIME_MEDIUM

      17:16:11
      
    • TIME_SHORT

      17:16
      
    • DATE_TIME_FULL

      FR: mercredi 25 juillet 2018 17:16:11 UTC+2
      EN: 2018 July 25, Wednesday 17:16:11 UTC+2
      
    • DATE_TIME_LONG

      FR: 25 juillet 2018 17:16:11 UTC+2
      EN: 2018 July 25 17:16:11 UTC+2
      
    • DATE_TIME_MEDIUM

      FR: 25 juil. 2018 17:16:11
      EN: 2018 Jul 25 17:16:11
      
    • DATE_TIME_SHORT

      FR: 25/07/2018 17:16
      EN: 2018-07-25 17:16
      
    • DAY

      25
      
    • HOUR_MINUTE

      5:16 PM
      
    • HOUR_MINUTE_SECOND

      5:16:11 PM
      
    • HOUR24_MINUTE

      17:16
      
    • HOUR24_MINUTE_SECOND

      17:16:11
      
    • MINUTE_SECOND

      16:11
      
    • MONTH

      FR: juillet
      EN: July
      
    • MONTH_ABBR

      FR: juil.
      EN: Jul
      
    • MONTH_ABBR_DAY

      FR: 25 juil.
      EN: Jul 25
      
    • MONTH_DAY

      FR: 25 juillet
      EN: July 25
      
    • MONTH_NUM_DAY

      FR: 25/7
      EN: 07-25
      
    • MONTH_WEEKDAY_DAY

      FR: mercredi 25 juillet
      EN: July 25, Wednesday
      
    • YEAR

      2018
      
    • YEAR_MONTH

      FR: juillet 2018
      EN: 2018 July
      
    • YEAR_MONTH_ABBR

      FR: juil. 2018
      EN: 2018 Jul
      
    • YEAR_MONTH_ABBR_DAY

      FR: 25 juil. 2018
      EN: 2018 Jul 25
      
    • YEAR_MONTH_DAY

      FR: 25 juillet 2018
      EN: 2018 July 25
      
    • YEAR_MONTH_NUM

      FR: 7/2018
      EN: 2018-07
      
    • YEAR_MONTH_NUM_DAY

      FR: 25/7/2018
      EN: 2018-07-25
      
    • YEAR_MONTH_WEEKDAY_DAY

      FR: mer. 25 juil. 2018
      EN: 2018 Jul 25, Wed
      
    • YEAR_QUARTER

      FR: 3e trimestre 2018
      EN: 2018 3rd quarter
      
    • YEAR_QUARTER_ABBR

      FR: T3 2018
      EN: 2018 Q3
      


    Cette documentation s’appuie sur la propriété ${F_HOME} définissant le répertoire dans lequel est stocké la configuration de FlowerDocs.

    Flower gère l’internationalisation des libellés. Nativement, l’application supporte le français et l’anglais. Cette section a pour but de décrire comment les surcharger.

    Cette fonctionnalité est également disponible dans l’API JS. La documentation concernant cette partie est disponible ici.

    Surcharge de libellés

    Afin de surcharger les libellés de Flower pour chacune des langues supportées, il faut :

    • Créer un dossier labels dans le dossier ${F_HOME}.
    • Créer un fichier avec la nomenclature suivante : FlowerLabels_locale. Il existe un cas particulier pour la langue par défaut (l’anglais) où le suffixe _locale n’est pas présent.


    Exemple : Surcharger le libellé de recherche sauvegardée en français et anglais.

    FlowerLabels_fr.properties

    	searchSaved = Recherches favorites
    

    FlowerLabels.properties

    	searchSaved = Favorites searches
    



    Nota : Il est possible de définir la langue utilisée grâce à un paramètre de l’URL locale qui surcharge celle du navigateur. Par exemple, pour utiliser la langue anglaise :

    http://flowerdocs.com/gui?locale=EN
    


    Afin de faciliter l’ajout dans Flower de fonctionnalité, la GUI Flower inclut un module reverse proxy basé sur le produit open source Zuul de Netflix. Ce module permet d’inclure des plugins en redirigeant des requêtes HTTP émises auprès de la GUI vers des URLs selon les routes définies.

    Définir un plugin

    Un plugin permet de rediriger un flux HTTP reçu par la GUI vers une autre URL. Pour accéder à un plugin, à travers la GUI, il est nécessaire que le client émettant la requête soit authentifié (à travers le cookie SESSION). Cette authentification est transmise au plugin sous la forme d’une en-tête HTTP token dont la valeur est le jeton de l’utilisateur effectuant la requête.


    Afin d’ajouter un plugin, il est nécessaire de définir la route correspondante. Une route est définie tel que :

    • un chemin en entrée : les requêtes émises sur ce chemin sont interceptées. Pour que la GUI puisse rajouter le token, ce chemin doit toujours commencer par /plugins/.
    • une URL : l’URL vers laquelle rediriger les requêtes interceptées

    soit :

    zuul.routes.<plugin-id>.path=<plugin path>
    zuul.routes.<plugin-id>.url=<external plugin URL>
    


    Exemple : Définition d’un plugin nommé myplugin

    zuul.routes.myplugin.path=/plugins/sample/**
    zuul.routes.myplugin.url=http://localhost:3006/sample
    

    Avec cet exemple, les requêtes émises sur <gui>/plugins/sample sont redirigées vers http://localhost:3006/sample.



    * Avec le framework Spring MVC, il est possible de récupérer ce token en ajoutant le paramètre suivant à la méthode d’entrée : @RequestHeader("token") String token. * L’application supporte non seulement HTTP mais aussi HTTPS pour redirigfer les requêtes.

    Le timeout sur les plugins peut être configuré à l’aide des propriétés zuul.host.connect-timeout-millis et zuul.host.socket-timeout-millis.

    Plugins par défaut

    Par défaut, plusieurs plugins sont ajoutés permettant de consommer des ressources Flower. Ils sont listés dans le tableau ci-dessous.

    Chemin URL cible Description
    /plugins/arender ${gui.client.arender.url} Redirige vers la visionneuse de document ARender
    /plugins/plume ${gui.client.plume.url} Redirige vers plume
    /plugins/soap ${core}/services Redirige vers les services SOAP exposés par le Core
    /plugins/rest ${core}/rest Redirige vers les services REST exposés par le Core
    /plugins/reporting ${core}/external/reporting Redirige vers le module Kibana du Core
    /plugins/external ${core}/external
Recherche

Ecran d'indexation

Menu

Page d'accueil