Custom Controls in WPF

Link. April 26, 2006. Comments [1]. Posted in: .NET | WinFX | WPF

While reading Chris Sell's and Ian Griffith's Programming Windows Presentation Foundation book, I ran across the following tidbit on chapter 9 on custom controls: "One of the main reasons for writing custom controls in older user interface technologies is to modify the appereance of a control, but as we've seen in earlier chapters, the content model and templates mean this is often unnecessary."

From what little I've experienced of WPF, the whole templating mechanism seems extremely powerful, particularly given the content model for UI Elements and the layout mechanism. Certainly, very impressive things can be achieved this way. That said, it does seem the whole templating mechanism can be just as easily abused (just like everything else in every other technology). So, where does the line get drawn between templating and creating new custom controls? Obviously, the second option takes more work (or so it seems to me, at this time), while the first can be more convenient.

Thing is, in my experience working with other smart-client technologies (WinForms, MFC, Win32), I found myself creating custom controls not just because it was the only possibility to affect behavior or custom draw a control (it isn't), but because it really helped make the code more modular and mantainable and make it self-contained (which helps reusability a lot, by the way). So, when I look at the templating mechanism in WPF, I find myself thinking that, while very cool and powerful, it could easily turn into a mantainance nightmare. In other words, I find myself asking "How is this different from, say, handling the Paint event for a child control in a Windows Forms and doing custom drawing there?" (from a code estructure point of view). At least from my little knowledge of WPF, I'd dread hundreds-of-lines XAML files with tens of templates and resources, just as much as I'd dread the corresponding windows forms code with hundreds of lines of embedded presentation, drawing and business logic.

I've been pondering about this for a while, and would love to hear the opinion of those of you that have been doing real-world WPF applications out there on the topic of reusability, templates and custom controls on WPF. Please, please convince me I'm wrong ;-)

Friday, June 02, 2006 11:03:47 AM (SA Pacific Standard Time, UTC-05:00)

You raise an interesting point. I think it will be many years before the core paradigms of application development in WPF really stabilize. But I think the question of who owns presentation rendering in the immediate future is clear: it's not us programmers.

Coming to the table with an extensive HTML background, I *get* the styles and templates. I really do. The key to understanding templates is, I think, that you have to understand that nobody's going to hand-code templates from scratch. And I think you need to understand great divide between the roles of graphic designers and programmers that's expected in WPF.

The template system is intended to be skinning system. We as programmers are supposed to implement relatively presentationless XAML. Sure. We own details of how things lay out in the window; and the behaviours of elements in the UI. But it is graphics designers who will own the actual presentation, and the actual authoring of the skins.

So how do templates get built? Using Microsoft Expression, of course. That's the tool that allows designers to skin the application without writing code. Reallistically, I think designers will use XAML templates much the same that CSS stylesheets are used, although XAML templates are far more powerful. Just like in HTML, designers will flip back and forth between the rendered and raw XAML to produce great looking templates. (Just like in HTML, I think designers will need to be XAML-literate, and able to dig in wiht a text editor where neccessary).

Again, coming from an HTML background, I think the presentationless authoring of functional XAML as a separate activity from the skinning process is a great idea. Programmers produce crappy looking UIs. I don't know if you've seen the BBC demo from Mix '06 (part of Bill's keynote). There ain't no way that mere mortal programmers are going to produce UIs that look that good.

That being said, sure, there are times when you need to get down and dirty and actually render content. But the secret in that case is to provide a rich set of presentation controls to our designers (foreground/background colors, fonts, at a minimum, maybe even wholescale elements that are rendered using complex graphics that have been built by a designer, and plugged in via XAML templates.

Robin Davies

Comments are closed.

Commonality

by daemons be driven

Custom Controls in WPF

Syndicate

About

Ads

Categories

Statistics

Archive

Other