Best way for programmers to edit XAML

Question

I was wondering how programmers chose to edit XAML. Most of the programmers I speak to seem to edit the raw XML, but that seems nuts to me since it is such a natural thing for a more visual editor (of course you often have to get down to the raw code ultimately, but isn't there a better way to lay out a grid, or edit a template, or add non c# triggers or manage commands? The one that really set me off was editing a menu -- Visual Studio 1.0 had a better menu editor for C++ than the raw XAML editing experience.)

When I edit .aspx files I use a visual editor much of the time, and then for the raw stuff I get into the html code.

I am aware of Expression Blend, but that seems far more focused on artistic types and GUI experts rather than programmers.

Does anyone have recommendations for a better editor for XAML than VS? Especially so since VS seems to have real nasty problems with XAML editing too, like bugginess and poor performance?

Appreciate your helping this XAML newbie.

Answer 1

The Visual Studio 2008 visual editor for XAML is still fairly primitive as you've encountered. When it comes down to wanting a true visual editor for XAML files, Blend is your best bet.

Like you, I originally thought Blend was targeted more for designers, but after using it for awhile now, I've found that Blend is clearly the best tool to visually edit XAML files. And since Blend integrates with Visual Studio Team System, you are able to switch between Visual Studio and Blend fairly seamlessly.

Answer 2

I must agree that Blend has the best XAML editor I've tried. While VS2010 has made some significant improvements over 2008, it's not at the same level as Blend, and still feels a little clunky and is prone to freaking-out.

A good option for doing quick and dirty XAML editing is Kaxaml, a small editor which can be thought of as NotePad for XAML. It's fast(er than VS), has syntax-highlighting, auto-completion and an in-editor preview. I find it quite useful to use alongside VS, although it is limited for serious work.

Answer 3

Visual Studio 2008 isn't the tool to edit WPF window. It falls in error usually if you uses a complex xaml type or some advanced styles.

Visual Studio 2010 has added a lot of new features in editing and specially designer for binding and IntelliSense for xaml too.

Blend is true that is oriented for designers like Microsoft want to sell it but I find it more like the missing feature of the designer of VS. Blend has an advanced editor for styles and animation and helps a lot to generate. But Blend lacks terribly in editing raw XAML, it has no IntelliSense at all.

My choice is to use both VS 2010 and Blend specially for styles and animations.

Answer 4

I use Blend when I'm doing visual tweaking or setting up Storyboards. I'll sometimes use it when first laying out a window, as well, but I've found that it's often easier to just hand-code the XAML rather than relying on Blend to guess the layout I want. I use Visual Studio when I'm doing XAML editing by hand, as it has better Intellisense and automatic formatting than Blend. I never use the visual editor for WPF in VS.

Part of the challenge here is that XAML layout is much more sophisticated than WinForms, so simple drag and drop doesn't quite cut it anymore. Blend does a pretty good job of guessing what I want, but if I really want to clarify how the visuals should be laid out, it's easier to express by typing the XAML, now that I'm familiar with it.

My typical workflow:

1. Create the initial layout by entering XAML in Visual Studio for the Grids, StackPanels, DockPanels and what have you that will lay out the window or control. I may also drop in some of the other controls as well, if the layout is simple.

2. Open up Blend and use it to place smaller controls, edit control properties and create/associate any styles I need. If I need custom control or data templates, I'll create them from Blend and then repeat the VS/Blend process on those templates.

3. Go back to VS and edit the XAML to set up my designer data context and manually code the data bindings.

4. Use Blend to verify the look of the finished window or control with the designer data context, tweaking and styling as needed to polish the UI.

I go back and forth a lot, but I'm typically also approaching it from a different mindset with each tool. If I was working with a larger company, I suspect most of what I do in Blend would be handled by a graphical designer, which is I think the intention. I don't mind wearing both hats, though and I've become accustomed to using both tools, as needed.