WPF versus WPF/E

<< Google's Big Move | Home | Blog Tag - Five Things You Don't Know About Me >>

WPF versus WPF/E

I sat down to look at WPF/E this evening. WPF/E is Microsoft's cross-platform XAML engine that runs in a web browser. The technology is currently in a community preview stage.

I thought a good first step would be to port my "Game of Life" WPF application to WPF/E and see the game run in a browser. A quick look at the documentation revealed that WPF/E doesn't support data binding, resources, or layout controls (like the Grid).

A good contrast will be to compare the following snippet of WPF code to my hacked up WPF/E equivalent. This C# code dynamically creates a "life" indicator in each cell of a grid control.

Ellipse ellipse = new Ellipse();

Grid.SetColumn(ellipse, column);

Grid.SetRow(ellipse, row);

ellipse.DataContext = _cells[row, column];

mainGrid.Children.Add(ellipse);

ellipse.Style = Resources["lifeStyle"] as Style;

With no data binding, no resources, and no Grid control, the JavaScript code for WPF/E has to take an alternate route.

var xaml = '<Ellipse Height="7" Width="7" />';

var ellipse = this.agControl.createFromXaml(xaml);

ellipse.Fill = this.CreateBrush();

ellipse.Opacity = this.cells.isCellAlive(i,j) ? 1 : 0;

gameBoard.children.add(ellipse);

ellipse["Canvas.Top"] = (this.agControl.height / this.size) * i;

ellipse["Canvas.Left"] = (this.agControl.width / this.size) * j;

WPF/E has some clever solutions to tough problems. There is no Ellipse constructor function as you might expect. That approach would require a massive JavaScript file with functions defined for all the WPF/E objects. Instead, we create objects graphs using XAML fragments. The code merely needs to pass these fragments to the WPF/E ActiveX control's createFromXaml method and receive an object in return. Also, notice the syntax for attached properties in WPF/E (ellipse["Canvas.Left"]).

If I had $100 to spend on WPF/E features, I'd spend the whole lot on adding data binding and layout controls. Overall, WPF/E is a bit different from what I expected before I started this evening. At this stage, the technology is good for performing animations, and playing media. No small feat, really, but anything the team can add that will facilitate day-to-day business requirements (build a dashboard of key performance indicators, fill out an insurance claim form) would make the technology terrific.

Print | posted @ Thursday, December 28, 2006 5:17 AM

Comments on this entry:

# re: WPF versus WPF/E

by Rick Strahl at 12/28/2006 10:05 AM

Yeah that's what I thought as well. It seems even the full WPF isn't really geared towards business scenarios with providing only the most rudimentary of controls. Everything fancy (complex lists or trees, grids etc. or even formatted input controls etc.) are strangely lacking from WPF in general. Line of business applications is apparently not the target...

# re: WPF versus WPF/E

by Strange Pants at 12/28/2006 11:53 AM

Until WFP and WFP-E are identical (i.e. code once, run anywhere) why would you even bother? If you are going to have to write the application twice, you might as well rewrite for the browser itself (ASP.NET?).

I realise WFP-E holds a lot of promise for changing the UI paradigm, but ... this really does look like yet another half-baked product from Microsoft in a year full of half-baked products.

# re: WPF versus WPF/E

by admin at 12/28/2006 4:11 PM

@Rick: Yes, the controls are rather primitive. I can only imagine WPF growing to include everything needeed to support business apps, but I wonder what WPF/E has in store.

@Strange Pants: My guess will be that code once run everywhere will never work, but its hard to say what things will look like 5 years for now.

# re: WPF versus WPF/E

by scottgu at 12/28/2006 9:46 PM

WPF/E with this first CTP has the same graphics support and parsing as WPF. What it doesn't have yet is control support (beyond the core visual elements) as well as layout manager support (layout management is part of the control model).

This is coming though...

# re: WPF versus WPF/E

by James Hancock at 12/29/2006 5:30 PM

Basically what you're saying is that WPF/E is just flash by any other name at this point and there is absolutely no reason to use it when 99% of the graphic world knows flash and doesn't know WPF/E.

Until there is databinding native that can be created within the ActiveX (I don't know why I would care about javascript but...) this is essentially useless and has the exact same problems that flash does right now without all of the benefits of 99% computers on every platform having flash on it....

# re: WPF versus WPF/E

by Mike Harsh at 12/29/2006 10:20 PM

Did you finish your WPF/E game of life? I didn't see a link. Also, as a better workaround to your ellipse constructor problem, see Jesse's response in this forum post:

forums.microsoft.com/.../ShowPost.aspx

This will let you write code like:

var ellipse = createElement("Ellipse");

# re: WPF versus WPF/E

by scott at 12/30/2006 1:52 AM

Mike: Thanks for the tip. I'll post the code this weekend.