Coffeehouse Thread

13 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Why is WPF so complicated?

Back to Forum: Coffeehouse
  • User profile image

    So watching the WPF video on the homepage and I noticed a block of code for the actual button. (Sorry I would Clipster it however it seems like the red button isn't there...) but it went something like...

    <border background="ffffff" padding="12">
        <image x:name="image" height="200" source="normal.jpg" />

    and how it doesn't do anything till you set trigger events.

    <control template.triggers>

    <trigger property="IsPressed" value="true">
        <setter targetnam="image" property="source" value="pressed.jpg" />

    I'm just wondering why they deviated from "known standards" JS. In Boxely (our WPF like platform)...this seems like it would be done simpler....

    <hbox s:fill="ffffff">
        <image id="image" s:height="200" src="normal.jpg" on:click="pressed();" />

    and then your pressed event in a referenced js file would be like...

    function pressed()
        var box = scene.getBoxById("image");
        id (box)
           box.src = "pressed.jpg";

    To me however it seems like in order to do more (like the hovering) it would need to have another tigger property and ALOT of if then statements to change the image. Where as with JS you could do maybe easier and just declare on:mouseover and more...

    I dunno maybe it's the same, it just seems more complicated...

  • User profile image

    It's perhaps as WPF and XAML try to achieve more then JS. I guess it is also as they want put as much as possible into XAML. You could alsways do it in code behind by using different classes and methods.

  • User profile image

    But you can do it this way. You can hook the Clicked event up to some code-behind code. In that code-behind code you can set the image's source to whatever you want.

    I guess what they're trying to do is to keep the style completely in the XAML code. It makes it much easier to reuse.

  • User profile image

    It looks like bad HTML to me. Perplexed

  • User profile image

        I think why XAML is bit complicated and cumbersome is because Microsoft wants to convince us that XAML is designed for IDEs or Designers, It's really unusual to manually write XAML in production situation. and WPF is not all about XAML, you only see the complexity of XAML, but It's just a tip of iceberg, WPF introduces a lot of new concept and programming paradigms which will take ages to learn about[A]


  • User profile image
    Ernie Booth

    This could be done the way your describing Cybermagellan even in WPF we could have something like this:


    <Border Background=”#ffffff” Padding=”12”>
    <Image x:Name=”image” Height=”200” Source=”normal.jpg” MouseLeftButtonDown=”OnPressed”/>


    And then in C# you would have


    void OnPressed (object sender, RoutedEventArgs e)
       this.image.Source = “pressed.jpg”

    But the reason that we choose to do it in Xaml is because it is much easier for a design tool to read xml then it is to read C# or VB.NET.  If you have done Windows Forms programming and edited the OnInitialized section you know how easy it is to break a code parser for a designer.  So WPF chooses to use a markup language so that designers can easily parse design files, this has already lead to some great third party design tools such as Aurora and Zam3D.  

    There is another more interesting reason to use Xaml which is that it works really great with the Model-View-Controller design pattern where the Xaml file is the view and the code beside file is the controller. As jmacdonagh points out this makes reuse much easier. 

    One thing to keep in mind is that Xaml is not what makes WPF so revolutionary it’s the flexibility that WPF allows via composition, data binding, styling, templating, resources and animation.

    ·         Composition: Element composition is at the core of WPF. Controls such as ListBoxes and Buttons are made up of simpler elements such as Borders, Shapes, Brush and Resources. A great example of composition in WPF is the Content property on most controls. Buttons for example don’t have a Text property, but instead of a Content property of type object. Any type of object can be assigned to this property, for example this Xaml snippet shows a Button being used as Content for another button. This results in the light blue button being placed inside of the green button.  Both buttons continue to work normally.


    <Button Background="Green">

    <Button Background="LightBlue">Hello, Composition</Button>




    Composition allows for very complex controls to be created without having to re-implement how they are render and hit tested.


    ·         Styling: UI development often requires setting the sample properties on different controls multiple times.  Styling is away to create the look of a control once and apply it to all the controls that should have that appearance.


    ·         Templating: Controls in WPF are look-less, meaning that their behavior is completely separate from their appearance. This allows the look of a control to be completely replaced without modifying its behavior or altering the class in which it is defined. There is no reason a button couldn’t be round, or use 3D animations for its state changes.  There is another type of templating called DataTemplating which allows for non user interface objects to be given a look based on their type. An example of this might be a Customer business object that could be added to a ListBox as an Item and have a DataTemplate control how a Customer is rendered.


    ·         Resources: are a reusability mechanism; they can be anything from an image to a Style.


    ·         Data Binding: is central to WPF in that just about any property in a control can be data bound to any CLR property.  Data Binding gets rid of event handlers which are used to simply update another property and contributes to a much cleaner implementation.  It also makes look-less controls in WPF possible as controls in a template are bound to properties in the behavior class.


    For a good technical overview check out this session from Mix06:

    For a full week of WPF check this out:


  • User profile image

    Ignoring what other's said (they were right), I don't see the complexity you're complaining about any way.  You traded 7 lines of "code" in 1 file, for 7 lines (not including braces) of "code" in 2 files.  Had to use XML in both examples, so if that's what's complex I don't buy that you've helped any.  I think the 1 file thing speaks in XAML's favor if you're talking complexity.

    For anyone who's done any declaritive programming (including web developers), XAML is not really complex at all.  There's a few minor things to get used to, such as how templates and styles work in XAML, but they are not any more complex than the counterparts we've used for years now, and the added power is astounding.

  • User profile image

    wkempf wrote:
    Ignoring what other's said (they were right), I don't see the complexity you're complaining about any way.  You traded 7 lines of "code" in 1 file, for 7 lines (not including braces) of "code" in 2 files.  Had to use XML in both examples, so if that's what's complex I don't buy that you've helped any.  I think the 1 file thing speaks in XAML's favor if you're talking complexity.

    What's the way XAML does code reuse? such as closing child forms?

    From my understanding it might be the same as me.close()?
    (I haven't read anything on XAML lately) or can it do code reuse for reaction events?

    with JS Events as long as you've declared them you can use them and reuse them....


    function close()

    and then every window that needs to close just uses that

  • User profile image

    In you're first example, what you have is dynamic styling.  IOW, in response to an event you modify some attributes (usually related to the visual presentation) on the control.  In this case, the all XAML approach is the most appropriate, and "reusing code" is straightforward.  You design a template and apply it to all controls of a given type or to individual controls.  This is superior for numerous reasons to the HTML/JavaScript example.  Of course, as pointed out, you also have the option of doing it in a code behind event handler, the same as you'd do with HTML/JavaScript.

    Your second example isn't a styling thing.  You're doing more than setting some attributes.  In this case, you're going to have to go down the code behind route, and as I just said, this means code reuse is identical to your HTML/JavaScript example.

  • User profile image

    Xaml considers what happens to the visual appearance of a button when you roll over it or click it a part of the definition of the button itself, and not part of the underlying user interation code.
    This means you can reuse style and behaviour consistently between applications.

    To the underlying code a button can be anything from as simple as <Button></Button> to a 3D object that spins on rollover and it will always behave in the same manner. This allows you to mock up a basic UI to design the User Interation model, and then have a developer write the code-behind, while a designer creates the final effects in parellel.
    Provided you have agreed on the which controls will be used, and what names they are given, how they end up looking becomes irrelevant to  the developer.

  • User profile image
    Ernie Booth

    Right I think the important point here is that behavior and appearance are totally separated with WPF.  The Button class defines how a button acts, that is has some content on type object and then it is a Click event, but it doesn’t define that it should look like a rounded rectangle with a particular gradient and text as it content.  Instead that appearance is defined in a ControlTemplate which is not a part of the class definition and so it can be changed by application developers without having to mess with the Button class.

  • User profile image

    Yeah see with our language it's different, the software feeds from a toolkit (aka ControlTemplate), however you can specify your own style, OR you can do it inline as well...

    <button id="close" s:fill="#ff0000" label="Red" on:click="close();"/>

    creates a red close button....

    Styling, Appearence, etc can be changed within the controls declaration.

  • User profile image

    Which is the worst way to define the styling, and why CSS exists in the HTML world.  XAML goes somewhere in the middle.  You can specify all of the look in the declaration, as you show, or you can separate it out in styles and templates, which happen to still be XML with very similar syntax instead of a seperate concept like CSS.

    Comparing CSS to XAML styles/templates there things to like and dislike about both.  I prefer the XAML syntax (and complete control, which you can only get with CSS by using XBL, which adds yet more complexity), but I miss a lot of the CSS selectors.

    But back to your actual point, I still don't see the complexity in XAML.  Having done a lot of HTML/CSS, and even more XUL/CSS/XBL, the things I've done in XAML so far have been MUCH easier to do... at least once you know how.  There is a learning curve, as with everything else.  But the learning curve so far has been much less than what I went through for HTML/CSS and especially XUL/CSS/XBL.  And all of those are superior to Win32/WinForms and other traditional UI toolkits.  Declaritive markup for UIs vastly simplifies a lot of what I do.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.