Tout en apprenant que SITECORE, j'ai constaté que la majorité du code d'échantillon de sitecore sur la bande est en XSL au lieu de .NET.
Quel serait l'avantage de choisir XSL sur les processus que je suis devenu habitué en tant que développeur .NET?
Y a-t-il des avantages de vitesse de traitement à l'utilisation de XSL?
XSL est effectivement plus facile une fois que vous êtes à l'aise avec la syntaxe?
6 Réponses :
Certaines personnes préfèrent XSL en raison de la compétence d'équipe existante, la disponibilité du talent XSL ou la croyance que XSL est plus facile ou moins chère à apprendre.
Dans Sitecore, les sublayouilles basées sur ASP.NET fonctionnent réellement beaucoup mieux que les rendus XSL. Si c'est ce que vous êtes à l'aise, allez-y. Je n'ai jamais créé de rendu XSL moi-même.
XSLT est une langue puissante; Ses principaux avantages sur les langues telles que ASP.NET ont tendance à venir lorsque vous souhaitez réutiliser et personnaliser la logique sur une grande variété de pages différentes ou de structures de documents source différentes avec des éléments communs communs et d'autres structures variables. Pour y parvenir, il utilise un modèle de traitement basé sur des règles que certaines personnes trouvent assez difficiles à se familiariser avec la première rencontre. L'apprentissage est un investissement qui va payer au fil du temps, mais cela peut être intimidant au début.
En ce qui concerne la performance, je n'ai jamais rencontré un site dans lequel il n'est pas assez rapide pour le travail, ce qui inclut des services assez élevés à fort stress; Lorsque les gens ont eu des problèmes de performance, ils se sont habitués généralement être dans d'autres parties du pipeline de traitement (ou simplement dus au codage incorrect).
Avec une référence spécifique à Sitecore, Toutefois, XSLT présente des inconvénients de performance dans certaines situations en raison de la mise en œuvre de SITTECORE. La structure XML est hautement générique, ce qui signifie tester des valeurs de nœud plutôt que des noms. La profondeur de nœud est également un problème possible, faisant des recherches récursives coûteuses. Il n'y a pas de choix de processeur dans la mise en œuvre de Sitecore, bien que cela ne soit probablement pas si difficile de le personnaliser. Enfin, il repose également sur certaines extensions XSLT dans C #, qui peuvent avoir ses propres inconvénients.
Suite ... de ce que j'ai vu dans Sitecore, .Net est généralement le moyen plus efficace d'ajouter des composants de présentation qui font autre chose que les tâches simples les plus élémentaires. Il existe également des meilleures pratiques de Sitecore XSLT (telles que l'utilisation de chacun) contre-intuitive pour la plupart des développeurs XSLT.
Le choix entre les composants XSLT et .NET dans SITECORE est en grande partie l'une des goûts et des compétences. XSLT in Sitecore a quelques inconvénients: il a tendance à être surperformé par des composants .NET pour tous sauf les rendus les plus simples et les endroits où il peut sembler le plus logique de l'utiliser, tel que la réplication de la structure de l'arborescence de contenu en tant que menu Site. en fait ceux qui ont tendance à prendre le plus grand succès de performances. Dans les situations de droite, XSLT est un outil incroyablement puissant et vaut la peine d'apprendre, mais je n'ai pas encore d'argument convaincant pour en faire beaucoup d'utilisation à Sitecore. Il convient également de noter que certains des schémas standard de la programmation XSLT ne sont pas les plus efficaces dans Sitecore.
Le seul véritable avantage que je puisse penser, serait que les rendus XSLT sont plus faciles à déployer isolément. Dis, par exemple, que vous mettez à jour votre rendu "points de nouvelles" et que vous souhaitez déployer ce changement à tester / la production tout de suite, ce serait un cas simple de téléchargement du fichier .xsl lui-même.
Utilisation de .NET DÉVELOPPEMENT (et supporter le modèle de projet d'application Web), un déploiement de la base de code déployerait implicitement toutes les modifications apportées aux assemblys affectés - y compris quel que soit le travail que vous avez en cours.
Il y a bien sûr des moyens de gérer cela. Code source ramifiant / fusionner et ainsi de suite - mais c'est une couche supplémentaire de complexité à votre solution.
Cela étant dit, j'utilise .net pour bien plus de 95% de tout mon développement de SiteCore moi-même: -)
Je vais simplement ajouter mes 2 cents aussi:
Je trouve qu'il y a trop de limitations dans XSLT qui doivent être surmontées avec les "bibliothèques" externes ou avec vous développant une méthode en C # qui peut être utilisée dans XSLT.
donc je trouve en utilisant ASP.NET SIMPLER. Mais alors je suis aussi beaucoup mieux avec ASP.NET qu'avec XSLT.
mais xslt a de bonnes choses:
Quand j'ai commencé à travailler avec Sitecore, mon entreprise utilisait un peu de XSLT, mais nous sommes partis lentement de cela, à cause de ses limites et que la plupart des gens ici sont plus familiers avec ASP.NET /C #. / p>
"En résumé, un objectif principal de la conception logicielle et du codage est la complexité de la conserve. La motivation de nombreuses pratiques de programmation consiste à réduire la complexité d'un programme. La complexité réduite est une clé pour être un programmeur efficace." -Steve McConnell (1993)
laissez ce guide quand utiliser XSLT sur c #.
Sans cas, ce type de questions ("avantages de x au lieu de y") sont subjectifs et argumentatifs
@Alejandro Je suis d'accord maintenant que je le regarde à nouveau. Toute réflexion sur la modification de la question? Sinon, je prévois d'accepter la réponse de @james Walford