At work right now I'm involved in a minor turf war over HTML. I write it in the .aspx and then other people sometimes move it into the C#, which aggravates me. The reason given for this is Don't Repeat Yourself, but I'm trying to make the case that there are other ways to respect DRY in this situation. I can think of at least five methods that would be both more maintainable and less code the server needs to interpret.1. Provide additional properties
I admit it's not the cleanest thing to do, but adding boolean properties on the objects being rendered that say things like whether a user is the same one who's logged in or whether some object has an image attached to it offers a lot of flexibility on the UI. It's a simple way to get around writing backend logic in the page itself while offering the possibility of later reuse. It's messy, though, because there's a temptation to just misuse existing properties instead of asking for a new property, and conversely, you can end up with a lot of duplicate information. A good example is the length of an array. You could end up repeatedly asking the array for its size to render things differently for 0 objects or some minimum number of objects that you want users to be able to page through. You could get this information instead in properties like hasObjects and doPaging or something, but that's just adding to an API things you could infer from what you have already. And neither alleviates the need for backend loops and conditionals mixed in with your HTML.2. Put repeated logic in user controls
Forgive me for not knowing how this concept works in other frameworks, but I'm guessing they all natively have something similar or can be abused into offering it. Instead of adding helper properties to your API, you could create those properties based on a single object passed into a control. This is less flexible than having the extra properties available to everything on the page, but it feels much cleaner and object oriented. In .NET MVC, there seems to be a movement against having code behinds for anything, which I think is unfortunate, since creating helpers for use within the context of a specific user control based on one large, self-contained object makes much more sense from an MVC perspective than having the server try to figure out beforehand everything the page will need.3. Use JSON and render everything client-side
This is my favorite. When the page first renders, you pass an object from the server side into the control, it plugs in the values, and all the HTML is rendered and ready when the client downloads it. Say there's an existing list of Things, and the user adds a new Thing. The markup from the same user control that rendered the other Things has been added to the page inside a script tag (or a convenient external URL) and now, when the server responds with the confirmed data about the newly added Thing, it's applied to the template and that gets rendered without refreshing the page. I think that's fucking elegant. My boss thinks I'm high and that we should put the markup in user controls and use those both the first time the page renders and to respond to XHRs with the markup pre-populated.
If you're reading this, what do you think? Am I betting on the wrong horse here? Did I miss something?