>>>>>How does that differ from any other team?
>>>>>
>>>>>>Now my (limited) understanding is that WPF is structured so that a designer can do the WPF and the coders write the C#. So that means a desinger could break your code by changing the name of an event.
>>>>
>>>>Designer does not necessisarily mean programmer.
>>>
>>>In many cases, the designer is experienced with the controls and tools used and also knowledgeable of current design standards. He/she will likely design the appearance and behavior of base controls so they all look according to the overall desired design. He/she may not even do any actual development but work with skins or setting appearance behavior and standards for developer to follow. However, the developer will actually use the controls in the app. Other shops work differently.
>>
>>
>>You illustrated my point. This whole concept of putting some portions in XAML and some in C# adds a level of ambiguity that seem rather stupid and makes the code more prone to maintenance problems
>>
>>Now if the WPF was simply design tags realted to UI presentation, then I see a clear separation between UI and code. But from what I can see, WPF blends the two together. If someone could go in and change the XAML and that resulted in the app's look changing, and this didn't require a recompile, then I'd say cool.
>
>Depends on what the designer does in the xaml. Of course it will most likely require a recompile (based on my experience so far), but it doesn't necessarily have any effect on the code behind.

It's possible to keep the XAML as stand-alone files so re-compiling isn't neccessary. But, of course, that comes with it's own problems (e.g. someone can just delete the XAML files). I thought about the idea of storing the XAML in a database but......

>
>FWIW, I agree in some part with you. I do not think it is insanely difficult, but so far, I do not like it. I don't like the separation of xaml and code behind because it is easy to blur it and to create problems with some working in xaml and some in the code behind and some in both.
>
>Everytime (so far) that I look at a real world WPF app's code, I find each developer is doing it differently.
>
>However, I REALLY like alot of the neat stuff you can do with WPF gui wize... I see WPF as a first attempt at a really neat tool.