Construire une application angulaire à l'aide des capacités sans tête de Sitefinity

Maintenant que vous savez comment consommer et créer du contenu avec les services OData et comment authentifier les utilisateurs de votre application, continuons avec une autre partie importante de l'expérience client.

Remarque : Il s'agit du troisième article du série sur la création d'une application angulaire avec les capacités sans tête de Sitefinity. Vous pouvez consulter partie 1partie 2 et partie 3 ici.

Dans cet article de blog, nous parlerons de la personnalisation et de la façon d'afficher un contenu personnalisé dans
votre application sans tête à l'aide des services Sitefinity OData. Nous explorerons également comment travailler avec le Layout
API de service pour afficher le contenu et la structure de la page Sitefinity en dehors de Sitefinity. Cet article est la quatrième partie de
la série sur la création d'applications angulaires avec les capacités sans tête de Sitefinity et s'appuiera sur l'échantillon (part 1part 2part 3). Vous pouvez trouver l'exemple ici.

Qu'est-ce que la personnalisation ?

La personnalisation consiste à adapter un service ou un produit à des individus spécifiques et à leurs besoins. Sitefinity vous aide à fournir différentes versions de contenu, d'actifs de page et de pages à différents
types d'audience, appelés segments d'utilisateurs. Vous définissez des segments en fonction d'un large éventail d'utilisateurs
des caractéristiques et des données que vous pouvez combiner dans des règles et des conditions. En savoir plus sur la personnalisation
dans Sitefinity dans la documentation.

Quelle est la personnalisation dans cet exemple ?

Dans Sitefinity Quantum (Sitefinity Sandboxes), il existe une page personnalisée appelée Lading page. Il se compose de plusieurs blocs de contenu. Cinq d'entre eux sont personnalisés, basés sur un segment appelé Clients potentiels. Cela signifie que lorsqu'un client potentiel accède à la page, les blocs de contenu personnalisés s'affichent
un contenu différent et spécialement préparé pour ces types de clients.

Un exemple de scénario pour cette personnalisation est que vous souhaiterez peut-être afficher un contenu pour les utilisateurs enregistrés (clients existants) et un contenu différent pour ceux qui n'ont pas de compte et sont considérés comme des clients potentiels. Un autre exemple d'utilisation serait le ciblage de clients, provenant de différents canaux : sites Web, réseaux sociaux, applications, etc. 19659008]

Comment cette personnalisation est-elle réalisée ?

Dans le sandbox Quantum sous Marketing -> Personnalisation , vous verrez le segment Clients potentiels. Si vous l'ouvrez, vous remarquerez qu'il s'applique aux utilisateurs qui visitent la page via une URL spécifique (qui inclut un paramètre de requête url_campaign with value social_media). La personnalisation est activée uniquement lorsque cette URL spécifique est atteinte. Vous pouvez même tester cela vous-même en ouvrant la Landing page dans le navigateur et en ajoutant ?url_campaign=social-media à la fin de son URL. Cela modifiera le contenu des cinq blocs de contenu de la page.

Alors, comment utilisons-nous cette personnalisation dans une application Angular ?

Nous le faisons en tirant parti de l'API du service de mise en pagequi renvoie le contenu et la mise en page des pages Sitefinity et vous permet de faire votre propre rendu frontal de chaque page. Un peu plus
des informations à ce sujet peuvent être trouvées ici.

Configurons-le dans notre exemple

Pour garder le code plus organisé, nous avons créé un nouveau module appelé LayoutRendererModule. L'idée est d'utiliser l'Layout service API pour visualiser la Landing page dans notre application. Par conséquent, nous avons également créé un nouveau chemin de routage dans l'application, appelé landing-page. Lorsque cette route est atteinte, le RootComponent est initialisé, ce qui nous rend la page de destination.

Vous avez probablement déjà remarqué que la conception de la page de mise en page est différente de la conception du Quantum application sans tête. Ainsi, pour ajouter des styles spécifiques pour cette page uniquement, nous les ajoutons dans la propriété stylesUrls du décorateur de composants. Cela garantit qu'aucun de ces styles ne sera chargé lors de l'accès à d'autres itinéraires.

Que se passe-t-il lorsque vous ouvrez la landing-page dans l'application ?

Nous souscrivons à la ArticatedRoute URL et obtenez l'URL de la page demandée. Nous le transmettons ensuite au PageContentService.

Le PageContentService gère l'obtention de la page et de son contenu via l'Layout service API. Nous obtenons d'abord la page demandée, puis nous vérifions le contexte pour les composants paresseux. Les composants paresseux sont des composants qui doivent être chargés à la demande, qui dans ce cas sont tous des widgets personnalisés sur la page. S'il existe des widgets personnalisés, nous effectuons un autre appel à l'API pour leurs versions chargées/personnalisées paresseuses.

La méthode get de PageContentService renvoie plusieurs éléments importants pour nous :

• site culture
• siteId
• content de la page

Dans le template du RootComponent nous passons tout cela à la directive ComponentWrapperqui les traite et visualise chaque contenu de la page. Il est chargé d'attribuer un composant angulaire approprié à chaque objet de contenu renvoyé par le service (qui est le contenu de chaque widget sur la Landing page). Ces composants angulaires sont utilisés pour visualiser ce contenu, de la même manière que les widgets MVC, mais dans le contexte de notre application angulaire.

Dans notre cas, la page se compose de blocs de contenu et de widgets de grille/disposition. C'est pourquoi nous avons deux composants, correspondant à chacun de ces types de contenu : ContentBlockComponent et LayoutComponent. Le TYPESMAP mappe chaque objet de contenu renvoyé par le service au composant, qui le visualisera. Une fois que nous avons le bon composant de visualisation, nous définissons ses propriétés, le créons et l'injectons sur la page à l'aide de la méthode resolveComponentFactory.

Qu'est-ce qui est spécifique aux composants angulaires ?

Le composant de bloc de contenu est simplement un div dans lequel nous rendons le contenu, et nous passons également les classes wrapper CSS provenant du widget de bloc de contenu dans Sitefinity. Si le bloc de contenu que nous sommes
la visualisation est partagée, nous faisons un appel supplémentaire aux services OData pour le contenu partagé.

Le composant Layout est comme les widgets de grille dans Sitefinity : il sert de placeholder pour d'autres widgets. Il peut être rendu sous forme de ligne d'amorçage avec des colonnes et de conteneur d'amorçage, en fonction des propriétés du modèle de contenu renvoyées par le service de mise en page.

Maintenant, si vous ouvrez la page de destination dans l'application, vous verrez que le html rendu est presque identique au html de la page de destination Sitefinity et les deux pages semblent identiques. Cela démontre la puissance de
l'Layout service APIqui permet d'afficher très facilement les pages Sitefinity dans les applications SPA, en préservant la structure de la page et son apparence.

D'où vient la personnalisation ?

Les widgets personnalisés sont ont servi de widgets chargés paresseux, comme mentionné précédemment. Pour obtenir le personnalisé
version d'un bloc de contenu, nous souscrivons au sujet receivedContent$ du PageContentService. Il suit chaque contenu paresseux de la page un par un. Pour obtenir le contenu paresseux/la version personnalisée qui correspond au composant que nous visualisons actuellement avec ComponentWrappernous comparons le Id de la version chargée paresseux au Id du composant, et si elles correspondent, nous copions les propriétés de la version chargée paresseux sur le composant sur la page. En bref, nous remplaçons la version standard du composant par la version personnalisée si elle existe.

Comment voyons-nous cela en action ?

Il y a un nouveau lien vers la page de destination dans la navigation de l'application. Une fois que vous avez cliqué dessus, vous serez redirigé vers la version par défaut de la page de destination. Ajoutez simplement ?utmcampaign=social_media à l'URL et vous remarquerez comment des parties de la page sont remplacées par différentes, exactement comme avec la page MVC.

Nous espérons que vous avez trouvé ce tutoriel, ainsi que nos trois tutoriels précédents, utiles. Nous encourageons tout développeur curieux de créer une application Angular à lire les quatre (ICYMI : liens vers partie 1partie 2 et partie 3).

Si vous avez des questions, veuillez nous envoyer une ligne dans les commentaires ci-dessous. Si vous débutez sur Sitefinity, vous pouvez en savoir plus ici ou vous lancer directement et commencer votre essai gratuit de 30 jours aujourd'hui. Nous avons également traité le sujet sans tête dans notre Fondations du développement Sitefinity gratuit. bien sûralors n'hésitez pas à le consulter.