views:

20

answers:

2

Is there a way to make Episerver leave the HTML id attribute alone and more importantly how much work is that?

I know you could also remove the viewstate, how much work is that?

I'm not here to start a discussion about semantics and optimization, whether or not a CMS should touch the front-end code is a long debate. I just need to know how difficult these adaptions are.

A: 

I guess you are only talking about the templates?

The hard part is rewriting the forms support for XForms made in the form designer. You also need to drop the edit-on-page functionality.

You might also want to override some things in the most used controls such as EPiServer:Property but other than that it's just to NOT put any server forms in the template code and you won't have any problems with ASP.NET garbage markup.

Johan Kronberg
+1  A: 

EPiServer Web Controls are developed to work with the ASP.NET WebForms framework and you have limited control over generation of ID-tags in some cases. It is better if you use dotnet 4.0 which is supported in EPiServer CMS 6.

It is a lot of work to eliminate all bad html generated by WebForms Controls completly. You will end up rewriting everything and loose a lot of ASP.NET built-in functionality. If you use WebForms it is probably better to be pragmatic and more cost effective and accept ID-tags and a small view state.

A common approach to get rid of view state is to remove the global form-tag used by ASP.NET. A known side effect is that the right-click menu in view mode used by editors stops working and also some common third party modules will also stop working as expected since they use the form-tag to inject javascript. You will also get issues with XForms.

If you want better control of the generated html render your page the MVC way using your own extension method that extracts values from EPiServer properties.

MVC is not yet supported by EPiServer CMS 6 but will nicely integrated in a future release.

Fredrik Haglund
Thanks! it is as I thought then. Or have experienced.
Jens
If a Control or module generates bad markup, I would say it should be rewritten any way, or not used at all. It think it's not right or fair to dump bad markup in the face of the user just because you want to use pre-existing modules. If you continue to support bad markup that way, we support irresponsible web development.
Jens