none
WPF/E vs. XBap

    Question

  • Hello Community!

    I was recently trying to evaluate why there is seemingly two ways to write web-based applications with WPF.  Am I way off? 

    Can anyone explain to me when I would use an XBap over a straight up WPF/E application? 

    Thanks,

    Alan

    Wednesday, December 13, 2006 5:49 PM

Answers

  •  Alan Z wrote:
    I was recently trying to evaluate why there is seemingly two ways to write web-based applications with WPF.  Am I way off?
    At the moment, yes you are way off.

    WPF/E has no UI controls, no layouts, and no ability to write code (other than Javascript).  These things may be added to WPF/E at some point in the future, possibly before it's released to the world.

    So you can't "write web-based applications" using WPF/E... Unless you can talk your boss into paying you for several years while you re-invent the GUI, using nothing except drawing primitives wired together with Javascript (no joke, Barak Cohen and KIRANKU actually suggested this approach on this thread).

    WPF/E wil work on the Mac and under Mozilla, however.

    Wednesday, December 13, 2006 6:07 PM

All replies

  •  Alan Z wrote:
    I was recently trying to evaluate why there is seemingly two ways to write web-based applications with WPF.  Am I way off?
    At the moment, yes you are way off.

    WPF/E has no UI controls, no layouts, and no ability to write code (other than Javascript).  These things may be added to WPF/E at some point in the future, possibly before it's released to the world.

    So you can't "write web-based applications" using WPF/E... Unless you can talk your boss into paying you for several years while you re-invent the GUI, using nothing except drawing primitives wired together with Javascript (no joke, Barak Cohen and KIRANKU actually suggested this approach on this thread).

    WPF/E wil work on the Mac and under Mozilla, however.

    Wednesday, December 13, 2006 6:07 PM
  • Actally I'm not sure what the issue is here... if I can get to javascript I can use any number of tools to get to the c# code behind page for server-side coding  (e.g. AjaxPro et al)... combining WFP/E and C# is a piece of cake
    Sunday, December 24, 2006 11:32 PM
  • The big answer is portability IMHO.  WPF/E is meant to be for portable pieces of *WEB* content. It does not support the full WPF stack.  On the otherhand, WPF/E is 1/50th the size (the x86 size of the .NET 3.0 Runtime is 50 Megs, 90 Megs for x64).  And if you need Apple compatibility, WPF/E is the obvious choice.

    XBap is a compelling answer closer to click-once deployment.  I have a list of common confusions about WPF vs. WPF/E on my website if that helps too:

    http://adoguy.com/viewrant.aspx?id=2143

    HTH

    Monday, January 01, 2007 11:17 AM
  • The issue is that if you have a XAML element, you cannot simply bind a C# event to it - you can only bind a javascript event handler to it, and therefore you miss out on all the cool API within WPF, you have to work in interpreted code/ not compiled, and you have to work with rudimentary Javascript, not the powerful C#.  Any attempt to bind back to server-side C# through some AJAX thing will not be suitable for enterprise-class application development (way to slow waiting for additional round trips, problems with security, and too prone to errors).
    Monday, January 08, 2007 3:24 PM
  • XBAP has absolutely no integration with the browser.  It cannot even read session cookies, so integration with forms authentication is not possible, much less any larger application.  XBAP has no way to communicate back to the hosting IE window (it is missing features found in Javascript 1.0 - window.opener, window.frame.top, DOM integration, ...)  As it stands, neither XBAP or WPF/E are suitable for integrated web development.
    Monday, January 08, 2007 3:28 PM
  •  Shan McArthur wrote:
    As it stands, neither XBAP or WPF/E are suitable for integrated web development.

    Indeed.  It really seems as if Microsoft has gone out of its way to make sure they don't have a competitive rich-client development environment.

    XBap's hijack your whole browser and can't even read your session cookies.  Meanwhile, WPF/E is just an anemic version of Flash with no Flex components.  WPF/E's ability to communicate with browser objects is nice -- but since WPF/E has no functionality, what good is it?

    Microsoft seems to be going backwards in the rich client domain.  Even a plain old NET 1.1 object embedded in a web page using an <OBJECT> tag could be rendered as part of a larger HTML page.

    WPF/E seems like it won't ever expose a significant portion of the CLR.  I think the best hope is that the XBap team realizes they need to expose the browser's Document Object Model to running XBap's.  Until then, XBap's will have to be built entirely in XAML.

    Monday, January 08, 2007 7:49 PM
  •  

    I agree with you on WPF/E but I think they are working to improve it in that regards.

    I don't mind XPab not being able to access the browsers cookies or object model. That is what I'm hoping we would get away from with XBap.

    HTML, javascript must die! They weren't meant for web applications.

     

     

     

     

    Monday, January 08, 2007 8:49 PM
  • I dont believe you researched XBAP very much. XBAP are a method of deploying .net 3 applications in the browser sandbox. 

    XBAP enables nearly full .net 3.0 functionaly for writing fat or thin clients applications

    While wpfe is a slim down portable (mac, mobile etc...) subset of WPF to enable cross platform media and rich data visualisation with XAML. 

    XBAP can read seesion cookies but you must enable it in your back end. See blog and example on 

    http://www.galasoft-lb.ch/mydotnet/WpfTests.TestSessionId/index.html

    http://www.galasoft-lb.ch/mydotnet/WpfTests.TestSessionId/PublishedXbap/WpfTests.TestSessionId.xbap

    The XBAP / browser communication is weak i agree, but not impossible agian see example http://www.galasoft-lb.ch/mydotnet/WpfTests.TestOpenWindow/index.html

     

    Tuesday, January 09, 2007 3:03 PM
  • XBAP cannot read or use the session cookies of the browser window that launched the XBAP application.  The article demonstrates that it can hold onto the browser cookies of any child web services of the XBAP application, but this does not work for the parent window cookies.  Consider a web application that uses forms authentication, then attempts to launch a secure XBAP application.  The XBAP application cannot get the forms authentication cookies, and therefore cannot integrate with the web application using the same user credentials (without asking the user to re-authenicate).

    XBAP cannot open windows, which some people see as a good thing, but it makes it impossible to use for some web applications.  There are many valid reasons to open new windows.  XBAP cannot communicate with its parent window (like Javascript window.opener) or with its parent frame (window.frame.top).

    I too wish that the XBAP team would reconsider their design requirements and allow XBAP to integrate with the container IE window/frame, share the cookies, access the DOM from within the XBAP, and open windows.  All of these capabilities are possible with EVERY other web development platform, and missing these features is a significant impediment on WPF.

    The WPF/E team is focusing on cross-platform capabilities and as such is likely to never have a full .net framework implementation.  In its current state (after a year of 'agile' development) it doesn't have a single user input element (text box, radio, button, menu, treeview, tab control, ....), does not have any .Net code-behind capabilities, no data binding, and no .Net framework.  All events must be wired up to Javascript handlers.  At this rate, it is going to take them a very long time to get WPF/E up to a point that it can be used for developing web applications.

    Friday, January 12, 2007 12:00 AM
  • hi everyone out there is there a way to call javascript functions from xaml code in wpf based application. I have searched for it but could not find a solution, does wpf application supports integration of javascript functions please reply

    Friday, January 19, 2007 2:03 PM
  • hi andrew you said in your statement that combining c# and wpf/e is a piece of cake can you please guide me along as to how we can combine wpf/e based application with c#  file.

    Saturday, January 20, 2007 10:40 AM
  • With WPF/E in its present form, all of your events are implemented in the browser javascript - there is no .net code-behind or any c#, it is all Javascript.  With XBAP, there is no browser integration.  As such, I don't think that Andrew's comments about integrating will be meeting your requirements.
    Saturday, January 20, 2007 10:29 PM
  • is there a way to call javascript functions from xaml code in wpf based application
    No, not from a WPF ("Avalon") application.

    -mark
    Program Manager
    Microsoft
    This post is provided "as-is"

    Monday, January 22, 2007 9:56 PM