Combien de travail pour qu'Episerver laisse les attributs ID seuls?

Existe-t-il un moyen de faire en sorte qu'Episerver laisse l'attribut d'identifiant HTML seul et, plus important encore, combien de travail cela fait-il?Combien de travail pour qu'Episerver laisse les attributs ID seuls?

Je sais que vous pourriez également supprimer le viewstate, combien de travail est-ce?

Je ne suis pas ici pour commencer une discussion sur la sémantique et l'optimisation, si un CMS devrait toucher ou non le code frontal est un long débat. J'ai juste besoin de savoir à quel point ces adaptations sont difficiles.

Source

2010-10-13 Jens

Veuillez publier des exemples plus concrets de problèmes avec des tags d'identification ou View State si vous voulez des suggestions plus spécifiques sur la façon dont vous pourriez les contourner! –

Le problème avec les ID générés est qu'ils gâchent la sémantique du document HTML et utilisent des identifiants dans les feuilles de style plus d'un tracas à utiliser, car vous ne pouvez pas dépendre d'un ID pour la spécificité car il est (souvent) en constante changer en cours de développement (et avec les prochaines versions/mises à jour). L'encapsulation du document entier dans un élément de formulaire ne peut pas poser de problème (autre que sémantique) si vous activez le formulaire pour prendre en charge à la fois le post-retour et ajax via l'amélioration progressive (hijax). – Jens

Je suppose que vous parlez seulement des modèles?

La partie la plus difficile est la réécriture de la prise en charge des formulaires XForms dans le concepteur de formulaires. Vous devez également supprimer la fonctionnalité d'édition sur la page. Vous pouvez également remplacer certaines choses dans les contrôles les plus utilisés tels que EPiServer: Property mais à part cela, il suffit de NE PAS placer de formulaires serveur dans le code modèle et vous n'aurez aucun problème avec ASP.NET balisage des déchets.

Source

2010-10-13 11:07:03

Les contrôles Web EPiServer sont développés pour fonctionner avec le framework ASP.NET WebForms et vous avez un contrôle limité sur la génération de tags ID dans certains cas. Il est préférable d'utiliser dotnet 4.0 qui est pris en charge dans EPiServer CMS 6.

Il est beaucoup de travail pour éliminer tous les mauvais html générés par les contrôles WebForms complètement. Vous finirez par réécrire tout et perdre beaucoup de fonctionnalité intégrée ASP.NET. Si vous utilisez WebForms, il est probablement préférable d'être pragmatique et plus rentable et d'accepter les tags d'identification et un petit état d'affichage.

Une approche commune pour se débarrasser de l'état d'affichage consiste à supprimer la balise de forme globale utilisée par ASP.NET. Un effet secondaire connu est que le menu contextuel en mode affichage utilisé par les éditeurs ne fonctionne plus et que certains modules tiers communs cessent aussi de fonctionner comme prévu, car ils utilisent la balise form pour injecter javascript. Vous aurez également des problèmes avec XForms.

Si vous voulez un meilleur contrôle du code HTML généré, rendez votre page MVC en utilisant votre propre méthode d'extension qui extrait les valeurs des propriétés EPiServer.

MVC n'est pas encore pris en charge par EPiServer CMS 6, mais sera bien intégré dans une future version.

Source

2010-10-14 08:30:17

Merci! c'est comme je pensais alors. Ou ont expérimenté. – Jens

Si un contrôle ou un module génère un mauvais balisage, je dirais qu'il devrait être réécrit de toute façon, ou pas du tout utilisé. Il pense que ce n'est pas juste ou juste d'abandonner un mauvais balisage dans l'esprit de l'utilisateur juste parce que vous voulez utiliser des modules préexistants. Si vous continuez à prendre en charge le mauvais balisage de cette façon, nous soutenons le développement web irresponsable. – Jens

Combien de travail pour qu'Episerver laisse les attributs ID seuls?

Répondre

Questions connexes