The ups and downs of templated data-bound controls

I've spent way too much time in the last year writing code for back-end stuff. Now spending quality time with UI is causing me headaches.

Mind you, my problems are relative to my standards, I suppose. Today I was working on the thread display for POP Forums v8. In the past, I would pre-process the data into a DataTable, then bind that to a repeater. I had no problem keeping page rendering times under .10 seconds. Doing that was less pretty, but it very quickly allowed me to build HTML or do empty strings for stuff I didn't want to display.

Using a templated control is much cooler for the tweak monkey that likes to change layout or whatever, but the databinding can be slow when you have to perform some logic or render some nested control. For example, I put a derived Image control in the template that took the member information as a parameter, and if they had no avatar, it set the image's Visible property to false. That nearly doubled the render time of the page!

If I just do a straight bind of a List<Post> object to my control, and just display data from those Post objects, no problem. It's very very fast. I need to rethink the approach a little, because I'm just not happy with the performance.

2 Comments

  • One option that some controls use is to support both a templated and non-templated render mode. If someone specifies a template, you use the templated/composited render path. If someone uses default rendering, you avoid creating child controls or compositing.



    Hope this helps,



    Scott

  • Hey... that's a smart idea. But the question that brings up is how in the control's event lifecycle you deal with that. Normally you instantiate the templates in CreateChildControls(), whereas you create markup in Render(). It would then have to be an all-or-nothing, one way or the other approach, right?

Comments have been disabled for this content.