Is converting asp xml code from aspx to code behind bad practice?

Question

I find myself being constantly annoyed when looking at the XML "code" in the .aspx files, and i tend to remove it and write my own C# to replace the controls that are in the .aspx files ( Im currently writing my own replacement for the CreateUserWizardStep that was in the .aspx file ).

I personally find that XML code tends to not provide the control i need, and hunting the internet for clues on how to forcing it to do what i want is just annoying.

So the question becomes: am I teaching myself a bad practice here? Should I take the time to learn the "magic" in the XML? ( The project I'm on here is with only one other coder, so I'm thinking more ahead for perhaps other projects??)

Answer 1

Whether it's going to be a problematic practice depends to a great extent on whether you're going to have a non-coder maintain the aspx page. It's not that hard to define your own tags for ASP.Net, but it does break the mental model of "page = script" somewhat, so your mileage may vary.

Answer 2

In general you should try to as much as possible to create your code (any code) in a "declarative" manner. .ASPX syntax with WebControls are a great way to create widgets in a declarative manner. By removing the WebControls from your markup and "hand roll" them through the C# codebehind is going the wrong way per definition.

But if you cannot do what you wish to achieve in a declarative manner, you obviously must create your stuff as nested controls or through some other similar mechanism, though what I'd try to do then if I were you would be to create my own WebControls which you then could use declarative in your .ASPX file. A great pace to start would be by using the composition pattern in an Ajax Framework like for instance Ra-Ajax. (disclaimer, I work with Ra-Ajax)

If you take a look at e.g. the Tree control in Ra-Ajax, this control is entirely composed out of other controls, purely in C# without having to resort to hand-rolled JavaScript at all...