Comments are closed for this post.
28 May 2009
I agree with most of your points, Josh! I rarely (if ever) have Blend installed and I always disable Cider in favor of the Source Code Editor in VS. I just prefer hand coding XAML. It forces me to be smart about UI composition, whereas tools often lead to bloat.
I've come to accept and even appreciate the verbosity of XAML because it very accurately reflects the code that is represented by the markup. In fact, when I am introducing developers to WPF, I really drive home the idea that XAML is just a serialization format for CLR objects. (This resonates well with developers... whereas designers tend to prefer thinking of XAML the way they do traditional markup.)
Having said that, I would love to have a few of the old mini languages back... especially around transforms and gradient brushes. And I like your idea for column and row definitions.
It also seems like there are a few classes where the framework could simply designate a Content attribute (Setter comes to mind... the default Content for a Setter should be its Value).
Way to beat the drums! I'll gladly jump on your bandwagon. :-D
28 May 2009
You are absolutely right Josh! Unfortunately the situation is so much worse in Silverlight because of the visual state manager which turns code that would be 20 lines in WPF into 200 or 300 lines!
The whole defining columns thing is extremely frustrating wastes a lot of time.
28 May 2009
I completely agree. In VS, I have the WPF design surface visible at abour 20% zoom as a thumbnail view of the Window/Control, but I code everything directly in XAML. Your row/column suggestion would be a huge improvement.
In fact, I wonder if it would be reasonably straightforward to introduce some kind of macro expansion loosely based on XSLT, with which developers could define their own extension markup attributes.
29 May 2009
XAML authors have definitely been neglected to date - it would be great to see some focus on improving this experience.
29 May 2009
There was once a transform mini-language in XAML, but it was removed before the WPF release. However, you can still set RenderTransform and LayoutTransform to a string of six numbers corresponding to the six settable cells of the Matrix structure. For your example:
RenderTransform="2 0 0 2 0 0"
I use this technique all the time for scaling and translation, and even sometimes for simple rotations.
Recently I've been teaching some three-day courses on WPF and Silverlight, and I really emphasize the importance of learning to write XAML by hand.
31 May 2009
I learned to become a hand-crafter the hard way: the tools didn't work as expected or the code they produced was too bloated, making it hard to port, restructure, expand, etc. Even worse, you can never know what subtle (and potentially unstable) changes will be inserted once you more an unrelated pixel on the other side of the screen. Most markup editing GUIs I tried to this date have suffered from the same problems, the XAML tools being no different.
But regardless, I think that readable and easy-to-write plain-text code is key to successful penetration of a new format:hand coding promotes better understanding of structure and functionality and ultimately leads to better code, less bugs and less frustration. (The fact that many things eventually need to be fine-tuned without the hassle of installing and/or loading up a heavy graphic environment is another issue that cannot be ignored). The overly verbose markup of XAML makes it hard and time consuming to work this way and makes HTML much more appealing despite its well-known RIA limitiations.
16 Jun 2009
I am a very experienced programmer and have worked on a great number of languages (C, Basic, Smalltalk, Pascal, Fortran, Cobol, C++,, C#). Recently I started working on WPF. And I am one of those developers that is experiencing more difficulty grasping WPF than I did with other languages.
I don't think that it's because of XAML per se though. I don't mind typing in long XML element names and attributes. I don't mind writing all the end tags. I don't mind typing at all. Visual Studio / DevExpress' CodeRush offers me all the aide that I need for that. Code completion, templates, short cuts, et cetera make that real easy.
What I do have problems with is the actual concepts in WPF. One thing that I find really difficult to learn and to accept really is the fact that one must/can implement a lot of functionality in the XAML, which in my mental model represents the display part of the application, not the code. I seem to be that old fashion developer that wants to type a=b if I want to assign the value of b to a.
WPF/XAML drives me away from that mental model and I'm very much aware of that. It is beginning to win its place in my brains, but it's taking longer than I thought. Even being aware that another mental model is needed for WPF doesn't make it easier for me.
Maybe XAML *is* for designers. That is why I'm trying to work more closely with our visual designer (i.e. having him learn Blend) and leave more of the work to him.
But, it's really new and sometimes hard to go this way. I'm so much used to being able to do everything in our software. That is no longer the case. I will get used to it, but it may take me a bit more time.
My 2cts worth.
05 Jan 2010
I haven't done much WPF work, but from what I have done, XAML text editing seemed the best, if not the only solution. Problems arise when I am trying to build some graphical vector image or gradients and such, and there I use KaXaml to do the work. Blend... I've installed it several times, never got it to work right with my projects and I saw no reason to actually buy it then. To this day ReSharper seems to be the tool that helps me most every single day, and they have great XAML support.
11 May 2010
I completely agree. The result of this is that I've put coding on hold and am going to go 'back to school' as it were to try and learn to think from a designers point of view.
Somewhere along the line someone lost sight of their target audience and instead got carried away by building for tools (which is daft... tools can consume human readable text much more easily than humans can consume machine readable text).
XAML has made a few decisions that have made it really hard to use in text mode and that is a great shame because I think we can all agree that something more than C# is really needed for construction of hierarchical structures.
And the really sad thing? The WPF model is pretty damn impressive once you get past the xaml.
17 Nov 2010
I just found this post. The funny thing is that I had the same idea a few days ago and built this: http://wpf-ex.googlecode.com