Silverlight Brass Tacks

Bill Reiss' Silverlight Ramblings

About the author

Author Name is someone.
E-mail me Send mail

Recent comments

Authors

Tags

Don't show

    Categories

    None


    Disclaimer

    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

    © Copyright 2008

    Why would you specify an event handler in XAML instead of code?

    Forgive me if I'm being dense and this was obvious to other people, but I have been wondering about this for while.

    In most demos I see by the Silverlight Team and others, they typically declare the event handler in the XAML:

    <Rectangle x:Name="rect" MouseEnter="rect_MouseEnter"/>

    As a developer, it seems to me like this is a strange mix of code and design time stuff, and it would be cleaner to wire up the event handler in code, and then all of the event handling code is in one place.

    I guess the key to this is that I am a developer, and that's how developers think. The problem with doing this in code is that designers then need you to change some code if they want to change the visual element that the MouseEnter event is wired to. If, however, the event handler is wired up in XAML, then the designer can move that event to some other element, and as long as the event handler code doesn't do anything specific to that particular element, it should all still work.

    In this world of tighter integration in the designer-developer workflow, there will be a lot of little things like this that developers will need to get used to.

    Currently rated 2.0 by 2 people

    • Currently 2/5 Stars.
    • 1
    • 2
    • 3
    • 4
    • 5

    Posted by Bill Reiss on Wednesday, April 23, 2008 7:54 AM
    Permalink | Comments (3) | Post RSSRSS comment feed

    Related posts

    Comments

    Raumornie us

    Wednesday, April 23, 2008 4:45 PM

    Raumornie

    I don't think this is obvious either...

    In my opinion, it's just as easy for a designer to change a visual element and keep all of the events wired in code as long as they don't change the names. This could get problematic if, as in your example, there is an element called 'rect' that ends up being a Grid or a StackPanel, but the same thing ends up happening if the designer is setting the events in XAML (above 'rect_MouseEnter' may end up being a mouse enter event for a Grid, StackPanel, etc.).

    As a developer currently dabbling in design myself, I think any kind of code-related stuff should remain in code. If designers are concerning themselves with things like mouse handlers, they need to know a lot about how events bubble and whether it's better to attach the mouse event to a TextBlock, the background Rectangle, or an invisible Rectangle in the foreground. My coding experience might suggest the third option, but the designer might not even consider it (nor should they need to!).

    I love the idea of a designer-developer interactive workflow, but I don't think the two tasks are ever going to be completely decoupled. And I think that's ok. Good to know that both options are there and there's certainly a use for in-house conventions about where they should be.

    snyhol us

    Wednesday, April 23, 2008 6:49 PM

    snyhol

    I think they do this in demos to show off the XAML editor's ability to add an event and an event stub. Often demos do not illustrate best practices.

    The event declaration in XAML is kind of similar to the event declaration in ASP.NET... except with XAML, the designers will directly edit the markup files in Blend. In ASP.NET, the markup file was still typically edited by the developers - and the designers would contribute wireframes, UI designs (in JPG format), or HTML/JavaScript prototypes. Even though it does feel cleaner to wire up the events in code, I find defining the events in markup to be more flexible.

    I could imagine a workflow where the designer might work with a little code and the developer might work with a little XAML. Ultimately, they are on the same product team - and will be talking and collaborating with each other. The "silo" approach might be an edge case (the approach where developers and designers are working completely independent of each other).

    blogs.windowsclient.net

    Thursday, May 29, 2008 11:46 AM

    pingback

    Pingback from blogs.windowsclient.net

    WPF/Silverlight/XAML Web News - 2008/04/30 - Rob Relyea - Xamlified

    Add comment


    (Will show your Gravatar icon)  

      Country flag

    [b][/b] - [i][/i] - [u][/u]- [quote][/quote]



    Live preview

    Tuesday, July 08, 2008 1:17 PM