Construction d'URL conviviales grâce à des fichiers de modèles

Les fichiers de modèle sont utilisés dans la construction et la déconstruction des URL adaptées au référencement. Puisque chaque type de page nécessite la construction de données différentes, un fichier de modèle contient un modèle d'URL. Par exemple, il existe des fichiers de modèle pour la page Catégorie, la page Contact et la page Produit.

Définitions de modèles

Le fragment de code suivant est un exemple de définition de modèle pour une URL de page de stratégie de confidentialité :


<!-- Privacy URL like this: http://localhost/shop/en/aurora/privacy-policy-registration (canonical)
This Pattern is replacement for PrivacyPolicy mapping present in SEOURLMapper.xml in previous SEO implementations 
(Before FEP3)
 -->
	a<seourl:seoUrlPatternDef name="PrivacyRegistrationURL">
		b<seourl:seoUrlPattern viewName="PrivacyView">
               /LanguageToken/StoreToken:CatalogToken/PrivacyRegistrationToken</seourl:seoUrlPattern>  
		c<seourl:urlToParamMapping>
			<seourl:mapping name="langId" value="?LanguageToken?"/>
			<seourl:mapping name="storeId" value="?StoreToken?"/>
			<seourl:mapping name="catalogId" value="?CatalogToken?"/>
			<seourl:mapping name="fromPage" value="registration"/>
		</seourl:urlToParamMapping>
		d<seourl:paramToUrlMapping>
			<seourl:mapping name="LanguageToken" value="?langId?" defaultValue="-1"/>
			<seourl:mapping name="StoreToken" value="?storeId?"/>
			<seourl:mapping name="CatalogToken" value="?catalogId?"/>
			<seourl:mapping name="PrivacyRegistrationToken" value="Privacy-Policy-Registration"/>
		</seourl:paramToUrlMapping>
		e<seourl:usageDef>
			<seourl:usage device="browser">
				<seourl:target>Privacy</seourl:target>
			</seourl:usage>
		</seourl:usageDef>
	</seourl:seoUrlPatternDef>

a. Nom de définition du modèle d'URL de référencement: Nom du modèle. Définissez la valeur comme étant le nom utilisé lors de la construction des URL de référencement dans les pages JSP à l'aide de la bibliothèque de balises wcf:url.
B. Mappage des struts au modèle: Définit le modèle de l'URL. L'attribut viewName définit le mappage d'action struts utilisé lors de la déconstruction de l'URL de référencement. Une fois que l'URL de référencement est déconstruite et comparée au modèle, la requête est transmise à l'attribut correspondant viewName.

c. Mappage de l'URL de référencement aux paramètres: Utilisé lors de la déconstruction de l'URL de référencement. Une fois que l'URL est comparée au modèle, les valeurs associées aux mots clés de l'URL sont attachées aux noms des paramètres correspondants. Les noms des paramètres sont définis dans ce mappage, qui est basé sur le mappage entre tokenName et le mot clé.
Par exemple, si en/aurora/Privacy-Policy-Registration est comparé au modèle /LanguageToken/StoreToken:CatalogToken/PrivacyRegistrationToken précédent, la valeur du mot clé "en" est associée au paramètre langId. Le mot clé Aurora est associé à StoreToken:CatalogToken et à sa valeur (par exemple : 10001:10002) est affecté à storeID et catalogId (storeId = 10001 et catalgoId = 10002) après le fractionnement.

d. Mappage du paramètre de l'URL de référencement à l'URL: Utilisé lors de la construction de l'URL de référencement dans les pages JSP à l'aide de la bibliothèque de balises wcf:url. En fonction du nom du jeton et de tokenValue, les mots clés sont recherchés dans la base de données et remplacés par les noms de jetons dans le modèle d'URL.

e. Utilisation du modèle: Dans cet exemple, l'utilisation concerne une page statique de confidentialité, qui s'affiche sous l'outil Gestion de magasin dans le Centre de gestion.

Structures des fichiers de modèle

Les fichiers de modèle se trouvent dans ce répertoire :

crs_eardir/crs-web/WEB-INF/xml/seo/stores/storedirectory
workspace_dir\crs-web\WebContent\WEB-INF\xml\seo\stores

Vous pouvez disposer de plusieurs fichiers de modèle par magasin, et chaque fichier est lu dans l'ordre alphanumérique. Si les modèles par défaut doivent être personnalisés, créez un fichier distinct et assurez-vous qu'il est répertorié en dernier par ordre alphanumérique pour remplacer les définitions par défaut.

Si aucun fichier de modèle n'est trouvé, les répertoires du magasin d'un fichier de modèle sont recherchés. La recherche de fichiers de modèle se poursuit jusqu'à ce que l'une des conditions suivantes soit remplie ù:

Les fichiers de modèles se trouvent à un certain niveau. Le nombre maximal de niveaux qui peuvent être définis dans une URL de référencement est de 5.
Un fichier .disable est trouvé.
Tous les répertoires de magasins connexes sont recherchés.

HCL Commerce Enterprise Dans un magasin de sites étendus, la recherche de fichiers de modèle effectue d'abord une première recherche dans les répertoires du magasin pour le magasin de sites étendus. Si aucun fichier de modèle n'est trouvé, la recherche effectue une recherche dans les répertoires du magasin de ressources.

Jetons fixes

Un fichier de modèle de référencement peut contenir deux sections : Un jeton est un symbole élémentaire dans un modèle d'URL. Chaque jeton a une utilisation spécifique et est associé à un mot clé et à une valeur. Lors de la construction d'URL adaptées au référencement, les jetons d'un modèle d'URL sont remplacés par leurs mots clés respectifs. Pendant la déconstruction d'URL, les noms de jetons respectifs des mots clés sont recherchés afin de correspondre à un modèle d'URL particulier. Les mots clés sont également recherchés pour trouver les valeurs qui doivent être associées aux paramètres de l'URL dynamique déconstruite. Il existe deux types de jetons : dynamique et fixe. Les jetons dynamiques sont définis dans la table SEOTOKENUSGTYPE et les jetons fixes sont définis dans le fichier de modèle.

<seourl:tokenDef>
		1<seourl:token name="PageViewToken">
			<seourl:tokenValue value="image"/>
			<seourl:tokenValue value="detailed"/>
		</seourl:token>

		2<seourl:token name="PrivacyRegistrationToken">
			<seourl:tokenValue value="Privacy-Policy-Registration"/>
		</seourl:token>
		
		3<seourl:token name="TopCategoryBooleanToken">
			<seourl:tokenValue value="Y"/>
			<seourl:tokenValue value="N"/>
		</seourl:token>

		4<seourl:token name="BeginIndexToken">
			<seourl:tokenValue value="[[0-9]*]"/>
		</seourl:token>
		
		5<seourl:token name="CatEntryIDToken">
			<seourl:tokenValue value="[[0-9]*]"/>
		</seourl:token>
		
		6<seourl:token name="ContentOnlyToken">
			<seourl:tokenValue value="1"/>
			<seourl:tokenValue value="0"/>
		</seourl:token>
	</seourl:tokenDef>

1. PageViewToken: Peut avoir seulement deux valeurs, image ou détail.
2. PrivacyRegistrationToken: Peut avoir seulement une valeur Privacy-Policy-Registration.

3. TopCategoryBooleanToken: Peut avoir une valeur Y ou N.

4. BeginIndexToken: Peut avoir des valeurs numériques. Enfermez l'expression dans un ensemble de crochets []. L'expression [[0-9]*] indique que la valeur valide pour BeginIndexToken peut être n'importe quelle valeur numérique. Pour utiliser un entier, n'utilisez pas le *.

5. CatEntryIDToken: Peut avoir des valeurs numériques. Enfermez l'expression dans un ensemble de crochets []. L'expression [[0-9]*] indique que la valeur valide pour CatEntryIDToken peut être n'importe quelle valeur numérique. Pour utiliser un entier, n'utilisez pas le *.

6. ContentOnlyToken: Peut avoir comme valeur 1 ou 0.; Une valeur de 1 indique d'inclure l'en-tête, le pied de page, la barre de navigation gauche et droite, ainsi que le contenu.; Une valeur de 0 indique de ne pas inclure l'en-tête, le pied de page et la barre de navigation gauche. Afficher le contenu présent au milieu de la page

Jetons dynamiques

La table SEOTOKENUSGTYPE fait le lien entre l'interface utilisateur du Centre de gestion, qui enregistre les mots clés de l'URL, et les fichiers de définition des modèles qui sont définis dans la vitrine. Le principal écart entre le Centre de gestion et la vitrine est les noms des jetons utilisés dans les fichiers de définition des modèles. L'interface utilisateur du Centre de gestion utilise les noms des jetons pour enregistrer les mots clés URL pour les entrées de catalogue, la catégorie et les pages de magasin statiques. Pour distinguer les différents jetons utilisés dans la définition du modèle, le concept d'utilisation est introduit. La table Type d'utilisation de jeton fournit l'interface utilisateur du Centre de gestion avec les noms des jetons utilisés dans les fichiers de définition de modèle. L'usage mappe un nom de jeton aux entités pour lesquelles les mots clés sont définis par rapport au nom de jeton défini. Certains des usages sont prédéfinis dans cette table et sont mappés aux entités par défaut pour lesquelles les mots clés d'URL sont autorisés à être définis.

Les usages prédéfinis suivants se trouvent dans le mappage de table :

Royaume-Uni
Langue
Produit
Elément
Catégorie
Confidentialité
Plan du site

L'usage est défini pour des entités telles que les entrées et les catégories de catalogue et pour le contenu statique dans le magasin, comme les pages de confidentialité ou les pages de plan de site.

Les usages des jetons sont définis au niveau du magasin. Comme pour la vue de la relation du magasin, vous pouvez définir les usages des jetons au niveau du site, applicables à tous les magasins. Vous pouvez ajouter plus d'usages à la liste d'utilisation par défaut. Vous pouvez également remplacer les noms des jetons pour ces usages pour un magasin spécifique ou pour le site.

Les jetons de magasin sont mis en cache dans SEOConfigurationRegistry plutôt que dans le cache dynamique, car les jetons sont rarement mis à jour. Définissez toujours les jetons de magasin au niveau du site (niveau de magasin zéro), car les jetons de magasin sont toujours utilisés pour trouver la valeur storeId.

L'usage du magasin prédéfini utilise StoreToken comme nom de jeton. Si des jetons complexes sont définis pour l'utilisation du magasin pour un magasin spécifique, ils doivent contenir StoreToken. Par exemple, un magasin peut envisager de fusionner les valeurs d'ID de magasin, de langue et de catalogue dans le jeton pour l'usage du magasin et se présente sous la forme suivante : StoreToken:LanguageToken:CatalogToken. Lorsque le registre de configuration met en cache le jeton, il recherche la chaîne StoreToken dans le nom du jeton. La valeur à la position correspondante dans la valeur du jeton est traitée comme storeId. Ce comportement est la principale raison pour laquelle un nom de jeton codé en dur est le jeton de magasin prédéfini.

Langues

Le jeton par défaut pour l'utilisation de la langue est LanguageToken. Etant donné que les mots clés du jeton de langue sont issus du registre des langues, vous n'avez pas à les définir.

Par défaut, les LanguageTokens sont récupérés à partir du registre de langue. Le code lang est le mot clé. Par exemple, en anglais, urlKeyword est en et languageId est -1.

Toutefois, ce comportement par défaut peut être remplacé en définissant séparément urlKeywords (autre que le code de langue par défaut) pour n'importe quelle langue, dans les fichiers de modèle d'URL de référencement.

Pour plus d'informations, voir Utilisation de nouvelles langues avec des URL adaptées au référencement..

Conseils pratiques pour l'utilisation de fichiers de modèle

Les fichiers de modèle fournissent différentes options. Ces options peuvent être une zone d'incertitude pour les utilisateurs qui doivent décider comment construire les URL.

Les fichiers de modèle sont lus lors de la première requête. Si les fichiers de modèle sont modifiés après cette requête, les modifications ne sont pas reflétées dans un magasin tant que le serveur n'a pas démarré ou redémarré.
Si vous travaillez dans un environnement de développement, vous pouvez inclure un fichier texte nommé .reload pour que votre environnement charge périodiquement les modifications dans les fichiers de modèle.
Le fichier .reload doit se trouver dans le même répertoire que votre fichier de modèle.
Dans le fichier .reload, spécifiez la propriété d'intervalle de rechargement au format suivant :
```
reloadinterval = reload interval in seconds
```
Où reload interval in seconds est le temps (en secondes) qui s'écoule avant que le fichier de modèle soit rechargé. Par exemple,
```
reloadinterval = 900
```
Le fichier .reload est destiné à charger les modifications dans les fichiers de modèle de référencement. Ce fichier ne charge pas les modifications dans le fichier SEOURLMapper.xml.
Remarque : Utilisez le fichier .reload uniquement pendant le développement, n'utilisez pas le fichier dans un environnement de production. Le rechargement constant des fichiers de modèle peut affecter gravement les performances et provoquer des résultats inattendus.
L'ajout d'un fichier .disable vide dans le même chemin d'accès désactive la nouvelle fonction de référencement pour ce magasin particulier. Cette action nécessite un redémarrage de serveur ou un fichier .reload.
Vérifiez que la valeur de patternName n'est pas la même que celle d'un nom de mappage d'action dans les fichiers de configuration Struts.
Les caractères barre oblique "/" et trait de soulignement "_" sont des mots clés spéciaux utilisés pour séparer les jetons dans les fichiers de modèle de référencement. Par exemple,
```
<seourl:seoUrlPattern viewName="ProductDisplay" >/LanguageToken/StoreToken:CatalogToken/CatEntryIDToken</seourl:seoUrlPatter>
```
Remarque : N'utilisez pas ces caractères, ou le point "." lorsque vous construisez la valeur de urlKeyword