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.

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).

Pingback from blogs.windowsclient.net

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

I really enjoy reading your browser..NC..Tnx...

I know it has been a while, but...

If I am designing the user interface as a designer, I am concerned with how the interface will look and how the user will interact with that interface. I will be concerned with what events trigger a certain process, but I won't be especially concerned with the details as to how that process is implemented. So as a designer working in XAML I will want to be able to define the events (double-click, right-click, etc.) that initiate a given action rather than leave that to the coder.

It is nice to be able to do it either way, but preferable to do declare the event handler in the XAML -- simply in terms of the division of labor between the user interface work and the code that actually carries out what it is that the user wants done. This way you could write an entirely different user interface with an entirely different appearance and set of rules for the user to interact with the program, and as long as the XAML-based user interface knew what methods to call (e.g., find_prime_numbers), none of the code behind would have to change.

In this way, the next round of DotNet could come out sporting some pretty little user controls that you have never seen before as well as some more abstract objects ("hyper-generics" or some such thing), and the developer's company could focus on implementing the changes to the appearance of the program first, providing their customer with something that looks quite new even though all of the code that does the heavy lifting has remained the same -- and will remain the same until the next revision or two.

Thank you for the work you have put into your nice blog. We will bookmark to your blog because it is very informational. We love the site and will come back to see your new posts.

I am not new to blogging and really appreciate your blog. There is much original content that peaks my interest. I am going to bookmark your site and keep checking you out.

Awesome site. Very informative and nice design. I really like your posts and your style.

Very creative, one of the nicer sites I have seen today. Keep up the great work.

I really like the work that has gone into making the site. I will be sure to tell all all of my blog buddies about your site

thank u
great post
love u all