Poor maligned, and misunderstood by many: WPF/E

by Donald Burnett

Microsoft is very often accused of creating bloatware. I guess when they designed a lightweight very effective runtime (one that does what it needs to only and integrates well with many other web technologies), people would look at it, misunderstand. Why doesn’t it need these extra features?  Because things that don’t need to be there that might just grow the “runtime” size out of control and people won’t want it on their systems.

Some myths: Let’s look at these and why they just don’t fly with me..

Myth #1 WPF/E doesn’t support Databinding

yes, it doesn’t support databinding like WPF does, but it doesn’t need to. This all goes to to the fact that it really is a “LIGHTWEIGHT” runtime which is a beautiful thing considering it comes from Microsoft. Why doesn’t it need to ? because in this case there is already a technology that’s integrated with it that already does. It’s called Javascript.

Most people will be using WPF/E with another web page system that already has databinding that’s integrated with javascript like ASP.NET. In the case you can in visual studio or even Adobe’s Dreamweaver create a database connection that supports client or server-side databinding (where appropriate) and you just pass the dataset or XML data (if you are using XML) to the WPF/E.

Of course XAML databinding would be nice and we might see it in the future but it’s truly not necessary because you are probably going to use it with ASP.NET or some other server side web page technology that’s already able to pass this data at the scripting level.

So in other words it would just be a “duplicate” feature and bloatware if they added it. ASP.NET databinding is really advanced and can pass that data from the server side to the client wpfe very transparantly and it’s neither hard to do. So in the context of doing it in WPF/E the smart money was on using the databinding that was already there with other systems because the WPFE is going to sit on top of the pyramid on the client and let another system at a lower level do it more efficiently.

Myth # 2

WPF/E at the moment doesn’t have any Input Controls.

This is true but saying this is rather out of context of how you will USE XAML and the WPF/E controls at the moment. It it designed to be a plug in used with another web technology like HTML or ASP.NET which already have standard web controls built-in. Why re-invent the wheel here, it’s already there and can be elsewhere on the page. My issue for instance with flash controls is the size of text and size of boxes never really are consistant with anything else rendered in HTML with the page. The flash application looks like a box unto itself unless you have a really good designer who is watching that. Honestly there are too many people who don’t.

In this case it would be bloatware to add these controls to the runtime, they may but again the browser handles rendering of this already. There have been examples I could point at with ASP.NET AJAX (using the virtual earth control), and WPF/E that nicely integrates all of these together without any hassle and overlays these things all nicely. It’s all about the Z order folks and use of transparency.

Both of these points are very nicely made that there are some nice things they could add that would bring in extra however duplicated functions that are already there through integration. Yes that does make making a WPF/E application different than from making a WPF application. I suspect Microsoft actually put some great thought into this and probably did this on purpose.

In my opinion WPF/E isn’t really missing too much and in the context of a WPF/E app because it’s a web application (that runs in the browser) it’s very consistent about how it integrates with the other  web technologies and XAML’s role is definitely different than it is with a WPF applicatin. That’s okay because it’s meant to work differently, because of the different technologies involved and how it integrates.

A WPF application has to provide more services and do more things simply because in reality you are creating a windows application that uses the .NET CLR. It uses XAML very differently for different purposes. In this case a “non-browser” that supports all that stuff (it doesn’t run on the web or javascript typically).

 

Browser Only WPF/E vs No Browser WPF application figure. 1

 

 

 

Whoever’s saying WPF/E’s XAML implementation is a subset really isn’t how it should have been describe, it’s just a very different implementation. The one thing that does carry over is the page description rather nicely. Someone building a WPF/E application just isn’t gonna approach this in the same way though as a full blown WPF application or even the partial trust browser based .XBAP version of that (which isn’t necessarily cross-platform as a WPF/E).

Simply put they make use of other technlogies that are already there and working efficiently (like brower rendered textbox and html controls and asp.net databinding (under the lid with javascript on the server and client).

I give kudos to Microsoft for creating a cross platform lightweight runtime that does simply what it’s needed to do and no more and lets you integrate and use other web technologies. That has been the major beef about cross-platform plug-ins in the press anyway. How big they are and what a pain they are to install/use and what they have to make up for in the OS that’s not there.

In this case it’s just different not necessarily worse..

If you compare Flash to WPF/E yes you are looking at a 9.0 product versus a pre-1.0 product but I ask you who really has the advantage. The integration with technology that’s already there like ASP.NET controls, databinding etc. The WPF/E plug-in does just what it needs to do, fast and efficiently. A lot of time has spent by Flash developers using “Flash Remoting” and other things to connect flash to other web data technologies. If you look at it, they didn’t add remoting until a few versions ago of flash.  WPFE extends and embraces these other technologies in a pre-1.0 product and I don’t think we could have done half of what WPF/E is doing in the original FutureSplash ActiveX control.

So who’s really blinking here Adobe or Microsoft? Adding declarative markup to flash 9 only proves they see the value in what WPF/E is doing and it took them 9 versions to get there with it. Microsoft has been meticulously making modular building blocks with things like ado.net, asp.net, AJAX, etc. All work together in harmony so to speak.

Seems to me this healthy competition is good for us consumers because we all benefit from better technologies and new idea. If Microsoft hadn’t done WPF/E Adobe might have saw fit not to improve Flash as quickly.

Me I am in the WPF/E camp and hope it stays lightweight and stealthy because it works great. I don’t want to see yet another Microsoft bloatware plug-in. I want to see one that integrates and works well with these other technologies.

I am worried that flash 9.0 will start including the kitchen sink, just because they can and they are worried about real competition for the first time in a long time.. Let’s not add “BLOATWARE RUNTIME” to the vocabulary of RIA.

Finding help with WPF/E databinding

If you are looking for a great site that will help you with WPF/E databinding and integration of WEB services, ASP.NET and XML in general there is a site out there already ready for you..

www.xmlforasp.net

One of the best tutorials for doing databinding with ASP.NET is there and there is already an XML web services to WPF/E example with a HOW-TO video already up there..

This  below is a WPF/E Application that they give you as a code example, no this is not WPF wow! cool huh? databinding to a web service AJAX integration, and more.. Notice the nice porportionally rendered search box control using HTML browser controlled rendering.. (no need for XAML input controls here, but yeah I digress it is a simple example). The webservices based graphics, and the Psuedo-3d carousel.  I am sure that could be moving video not just still frames without a lot of extra work..

 

Anyway I am off the soapbox. Dig into WPF/E just remember it’s not integrated the same as WPF and doesn’t need to be. It’s a different approach but it is cross-platform and maybe even more extensible. Don’t let anyone tell you  can’t do databinding or you can’t do a UI properly because there are no input controls (it’s all about placement and design folks, the kind HTML folks with plug-in controls have been doing for years already.

Technorati Tags:

Advertisements
Explore posts in the same categories: Uncategorized

10 Comments on “Poor maligned, and misunderstood by many: WPF/E”

  1. Joe Says:

    I think your point about databinding misunderstands the central role it has in WPF. Databinding is central to WPF development. It isn’t just used for populating and updating control contents with sources of data. It’s used for linking elements together, triggers and animation. To say that ASP.NET can perform these tasks before the rendering takes place implies that you are just talking about data source rendering. WPF uses databinding (or just binding) as the basis of the whole MVC architecture.

    Also, generally – to say that WPF/E is good enough right now I think misunderstands the market place. WPF/E is a defensive product. There are other (good) competing technologies out there that are comparable to WPF and are also cross-platform. WPF/E is a good start – but it’s not enough – yet.

  2. Don Burnett Says:

    No not really, my point is WPF and WPF/E are really two separate technologies, not even really related. The USE of XAML a declarative description language isn’t used the same (you could even call it a different dialect), because of where it sits and what it interacts with.

    WPF= Windows applications that happen to be net enabled. XBAP’s cloud the issue a bit but they are really windows apps that run on a windows client inside a partial trust web browser.

    WPF/E= a cross platform technology that sits as as a plug in technology that runs inside a web browser. It doesn’t interact with the CLR or C# or VB.net compiled code. It just talks to javascript and interacts with it like everything else inside the browser does, including ASP.NET. My point is people can do the same type of 2 way databinding without having to have actually have it done inside the XAML itself. Databinding is a hallmark function of ASP.net, and honestly having ASP.NET do it for you isn’t any worse.

    I also personally don’t agree with your point of view that WPF/E is a defensive technology. It’s very different from per say the Macromedia products like Flash. People are quick to judge but the way the plug-in works is very very different from flash.

    A good example of another declaritive language (like XAML) that works differently in different situations differently is POSTSCRIPT..

    Postscript used in a PDF is much different than the postscript that’s fed to your laser printer for rendering. You wouldn’t have the same generic postscipt file in both locations. My point is the use of XAML is different, and that’s okay. You have XAML to describe more things in a WPF application where in a WPF/E application it just talks to and fires events to a scripting engine built into the browser.

    I think the fundamental difference I am talking about here between WPF applications and the use of XAML, and the difference in WPF/E means there probably will never be easy portability between the two no matter how much we might like it.

    All in all I won’t say ” WPF/E is a good start – but it’s not enough – yet.”

    Because I am seeing amazing things being done with it, and considering it isn’t even 1.0 yet, by the time we get there well.. It is not a difficult technology to use or get something very cool done with it. I like it for what it is.


  3. […] Burnett has an interesting piece call Poor, maligned, and misunderstood by many: WPF/E which I found to be an interesting read. He brings up two myths about WPF/E that (1) it […]


  4. […] Diskussion über Databinding in WPF/E siehe auch Poor maligned, and misunderstood by many: WPF/E.) 30. April 2007, 12:11 […]


  5. […] Diskussion über Databinding in WPF/E siehe auch Poor maligned, and misunderstood by many: WPF/E.) 30. April 2007, 12:12 […]

  6. Idetrorce Says:

    very interesting, but I don’t agree with you
    Idetrorce


  7. […] Burnett has an interesting piece call Poor, maligned, and misunderstood by many: WPF/E which I found to be an interesting read. He brings up two myths about WPF/E that (1) it […]

  8. mygu Says:

    非常漂亮哦


  9. nice job guys,i like your simple themes
    But I had difficulty navigating through your website because I kept getting 502 bad gateway error.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: