Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles WPF as a Rich Client Technology

WPF as a Rich Client Technology

This item in japanese


WPF, the Windows Presentation Foundation, is a .NET API for building Windows applications. Much has been written about how WPF makes it easier than ever before to create visually impressive applications, but it has other talents which, although less eye catching, make WPF a powerful technology for building front ends. In particular, the .NET framework's strong support for connected systems combined with WPF's approach to data binding to make it a compelling choice for presenting information from back-end services written in any technology, such as Java, Ruby, or .NET.

In this article we will compare WPF to alternatives such as Ajax/DHTML, Swing, and Flash; we will then look at some scenarios where you might usefully build a WPF front end as a rich client, using back-end services based on Java for example.

A Short Guide to WPF

WPF is a platform for building rich client applications. It part of the .NET 3.0 Framework, so it is built into Windows Vista, and can also be installed on Windows XP service pack 2, and Windows 2003. WPF user interfaces are constructed as .NET object models. However, WPF offers XAML - the eXtensible Application Markup Language - which is a markup language that allows the user interface's appearance to be designed separately from the code that defines its behavior. Either approach is equivalent, XAML being just an alternate syntax. However, the XAML syntax is designed to be easy for tools to create and consume, the intention being that tools will be created to enable designers to get directly involved in creating user interfaces, without needing coding skills.

(For more detailed information about WPF, see )

WPF is not the first rich client API to be available in .NET. However its predecessor, Windows Forms, is essentially a .NET layer on top of Win32's windowing system. And while Windows Forms added a lot of functionality on top of Win32, it was still constrained by certain limitations in the underlying UI platform. WPF does not build on Win32's windowing system. Instead, it builds on DirectX, which enables it to exploit the full power of the local machine's graphics card. However, WPF is not just about impressive-looking applications.

The single biggest benefit WPF has to offer is that it integrates many rich client features into a single platform. Most of these individual features have been available in isolation in other UI technologies for some time. For example, WPF offers animated vector graphics and video, which have long been Flash's fortes. WPF offers ordinary Windows controls such as buttons, list boxes, and tree views, which have been available in Win32 and Windows Forms for years. It offers flowed text layout, something HTML has done from the start. (Although WPF's text rendering is significantly more advanced than HTML and CSS are today.) WPF's markup + code-behind style of application construction also draws directly from HTML-oriented technologies such as JSP and ASP.NET. It has some basic 3D support, but OpenGL and DirectX have been able to do more advanced 3D rendering for many years.

WPF's predecessors are all good at what they do, but it's very difficult to use features from multiple technologies in a single application. It's very hard to use Flash's animation facilities in conjunction with Windows buttons and combo boxes. (Flash applications tend to define their own controls, but these typically fail to integrate visually with the user's chosen OS visual theme, they often fall short on accessibility, and their behavior is usually inconsistent with real controls.) Using data binding in a rich client application in conjunction with the text layout services offered by HTML is not well supported. In general, when you try to mix technologies, your application ends up split into multiple different worlds. Getting anything to span the divide is at best inconvenient, and often impossible.

By contrast, WPF makes this easy. Unfortunately, many of the publicly available WPF examples demonstrate this integration somewhat gratuitously. Wrapping full-motion video onto a rotating cube that forms part of the caption of an otherwise normal-looking Windows button embedded in the middle of a flow layout document might be a convincing demonstration that the various different UI features can all be brought together, but it also raises the question: who in their right mind would design a real application that way?

In reality you would be unlikely to integrate every possible UI feature into an application. To do so would be reminiscent of the early days of the web, where many sites would try to use every possible HTML feature without applying much thought. The results were horrendous. It took time to learn how best to use the technology to build good web applications. Likewise, the freedom to use WPF's visual features in any combination is powerful and liberating, but a little taste and restraint will be necessary to build useful applications. Moreover, WPF has a lot to offer even to fairly visually unadventurous applications.

Why Build a WPF Front End?

To discuss meaningfully why you might want to build a WPF front end, we need to compare it with some alternatives. Some obvious candidate technologies would be the web, Swing, Flash, Windows Forms, or even Win32.

Compared with a web front end, WPF enables higher quality interactivity. The standard of interactive web apps has improved lately, but while AJAX offers massively better interactive behaviour than classic plain HTML, that's really not saying much. We have become so accustomed to the web that we barely notice its many egregious interaction problems, and we are blown away by web sites that manage merely not to suck. Even best-of-breed AJAX applications deliver a user experience that would qualify as pretty ordinary by rich client standards. Moreover, although AJAX tools are coming on in leaps and bounds, it still requires a great deal more effort to deliver a satisfactory interactive experience with AJAX than it does to produce something at least as good with a rich client technology. Also, WPF applications can work even when the client machine is disconnected from a network. Moves are afoot to solve this problem for web applications, but today, rich client applications offer the only convincing solution for users with intermittent connectivity.

Compared with Swing, WPF offers two notable benefits. The first is WPF's data binding system, especially the XML binding and the data template features, which are discussed later in this article. The second advantage is a double edged sword that is also a reason you might not want to use WPF: WPF is designed to run only on Windows. This means it is able to take full advantage of the local PC's capabilities, and especially the power of the graphics hardware. This enables features such as high performance rendering of advanced data visualization, or more cosmetic touches like animation and video.

While Flash can offer some of the same cosmetic flourishes as WPF, such as animations and video playback, it's weaker if you want to build applications that look and behave like ordinary Windows programs. One of WPF's great strengths is that it offers both advanced visual features and a standard set of Windows controls that behave in the way users expect, allowing you to use both, mixed freely within a single application.

Compared with other Windows-specific rich client technologies such as Windows Forms, or classic Win32 development, WPF offers better data binding features, and makes it much easier to produce rich data visualizations. While WPF offers many benefits, there are also some reasons you might choose not to use it.

Why Not Build a WPF Front End?

The most likely blocker for WPF will be non-availability of .NET 3.0 on the client. A WPF application absolutely requires the .NET 3.0 Framework to be installed on the end user's machine. If you need to support users running operating systems other than Windows, or they are using a version of Windows older than Windows XP service pack 2, this rules out WPF. And even if the client machines are running a suitable version of Windows, you may not be able to get .NET 3.0 installed.

(Even if this rules out WPF, it might not rule out WPF/E. This is UI platform offering a trimmed down subset of WPF's features. The ‘E' stands for Everywhere, since it will run on non-Microsoft platforms including the Firefox web browser, and Mac OS X. However, this hasn't shipped yet, which limits its utility today. In fact the very first public preview had only just shipped at time of writing. So it's early days for WPF/E, and it's not something you can build on right now.)

Another point to bear in mind is the memory footprint of a typical WPF application. Looking at the WPF applications currently running on my machine, their working set sizes are all competing with the Microsoft Office suite applications in vying for the title of ‘biggest memory hog'. (And these particular WPF applications all have significantly less functionality than any of the Office applications.) If you need to support client machines with small memory configurations, WPF may not be the best choice.

You may also want to consider whether you want to adopt Yet Another Technology. If you are already using .NET, WPF is attractive because it's just another part of the .NET world, making it relatively easy to learn and adopt. But if you are not already using .NET in your systems, you would need to consider whether the potential benefits outweigh the costs of adding to the set of technologies your developers need to know.

But assuming that none of these blocking factors apply, and the benefits look worthwhile, the next step is to consider what sort of WPF application you might build.

Application Types and Deployment Options

WPF applications come in several forms. They may offer a UI with web-like navigation, or they might opt for a more traditional forms-oriented style. They might run as standalone applications, or they could be hosted entirely within a browser frame. And there are various options for how the application might be deployed.

The traditional style of rich client application runs in its own windows instead of a web browser, and can be launched from the Start menu's Programs list. You can use this style without losing the central update model of a typical web application: WPF is able to use the .NET framework's ‘ClickOnce' deployment technology, enabling updates to be deployed to a web server, and downloaded by client machines automatically.

If you have an established web-based Java application, a standalone WPF application probably looks like a bit of a misfit. In this case, you could instead start to exploit WPF without disrupting the overall application structure by building one or more browser-hosted navigation style WPF applications. This kind of application is called an ‘XBAP' - a XAML Browser Application. (As mentioned earlier, XAML is the markup language often used to construct a WPF user interface.) This is a very similar model to Java Applets: an XBAP can be embedded into a web page, or it can stand in for a whole web page, and in either case it is hosted in a secure sandbox. You could augment or replace parts of your web application with XBAPs while leaving the overall information architecture in place. This avoids the need for an all or nothing approach to WPF, adopting it only in the places where it offers the most benefit. You may also be able to provide a fallback UI for clients without .NET 3.0, by serving ordinary web pages instead of XBAPs to such clients.

Yet another option is a pure markup approach. Instead of building XBAPs (which are always compiled applications) you could simply generate XAML. If a web server serves up XAML pages, then as long as the client supports WPF, it will parse and render the content. This may provide a particularly easy way to incorporate WPF content: if your web server content management system supports the ability to generate web pages using XSLT, you may be able to adapt this to generate XAML as well as HTML from the underlying source material.

If you are building a new application from scratch, this ability to adopt WPF piecemeal is less useful. In that case, you would probably go for a standalone client application. This then raises the question of how the client application will communicate with the Java service.

Connecting Client to Server

WPF is part of the .NET 3.0 Framework, which also includes WCF. (The Windows Communication Foundation is a technology for using and creating distributed services, and it supports a wide set of web service standards.) This suggests an obvious strategy for connecting a WPF client to a Java server: XML web services using WCF on the client side. However, this is not the only option. (This is just as well, because in some cases, you may be unable to use WCF. WCF does not currently support partial trust scenarios, meaning you cannot use it within an XBAP, for example.)

You can also use the .NET 2.0 style web service client features. WPF's data binding system is just as happy working with this system as with WCF. Indeed, it doesn't really care where the data came from. It's happy to use any old set of objects as a data source.

As well as being able to bind to objects, WPF also has excellent support for data binding directly to XML data. This makes a POX (Plain Old XML) approach eminently workable. The next section shows a simple example.

XML Data Binding

WPF is able to bind directly to XML as a data source. It does not require it to be wrapped in any way. To illustrate this, we'll bind to a very simple but very popular form of XML data: RSS. There are of course numerous different sources of RSS in the world, generated by any number of different technologies. In the following example, we're going to use an RSS feed from Sun's developer site. (It seems safe to assume that Java is likely to be involved somewhere in this particular server.) Here's a XAML fragment for a WPF user interface that presents some information from an RSS feed:

<Border BorderBrush="Black" BorderThickness="1" Padding="2">
<XmlDataProvider x:Key="source" XPath="/rss/channel"
Source="" />
<StackPanel DataContext="{StaticResource source}">
<TextBlock Text="{Binding XPath=title}" FontSize="18"
FontWeight="Bold" Margin="0,5" />
<TextBlock Text="{Binding XPath=description}"
TextWrapping="Wrap" />

The URL for the XML source is hard-coded here with an XmlDataProvider element to keep the example simple - in a real application there are many different ways you could get the XML into the application.

The most interesting part of this example is the pair of TextBlock elements nested inside the StackPanel. (A StackPanel is a layout component that arranges its child items in a vertical stack.) Each of the TextBlock elements is bound to part of the source XML document - the connection is described in each case with the ‘{Binding ...}' syntax. The XPath expressions in these elements are relative to the XPath expression in the XmlDataProvider element near the top of the example. So the first text block is essentially evaluating the expression /rss/channel/title, and presenting the result as text. Here's how the whole example looks.

We didn't have to do anything to the XML data in this example - we just fetched it in its raw form from the web. WPF's data binding services let us point XPath expressions directly at the data we wish to display. This approach will work for any service (Java or otherwise) that exposes data in XML form.

This example only shows singular pieces of information from the feed. We can produce something more interesting with only a little more effort by taking advantage of another WPF data binding feature: data templates.

Data Templates

A data template is a reusable description of how to present a piece of data. You can apply a data template to multiple items, e.g. every item in a list, in order to present information consistently. The following example can be added inside the StackPanel of the previous example. This creates a ListBox control, whose items in this case are the set of ‘item' elements in the RSS feed:

<ListBox ItemsSource="{Binding XPath=item}"
<Grid Margin="2,8">
<RowDefinition />
<RowDefinition />
<RowDefinition />
<ColumnDefinition Width="80" />
<ColumnDefinition />

<TextBlock Grid.Row="0" Grid.Column="0" Text="Title:" Margin="0,0,0,6" />
<TextBlock Grid.Row="1" Grid.Column="0" Text="Description:" />
<TextBlock Grid.Row="2" Grid.Column="0" Text="Link:" />
<TextBlock Grid.Row="0" Grid.Column="1" FontWeight="Bold" FontSize="14"
Text="{Binding XPath=title}" TextWrapping="Wrap" />
<TextBlock Grid.Row="1" Grid.Column="1"
Text="{Binding XPath=description}" TextWrapping="Wrap" />
<TextBlock Grid.Row="2" Grid.Column="1" Foreground="Blue"
Text="{Binding XPath=link}" TextDecorations="Underline" />

Each item in the list is presented by a DataTemplate, which in this example has been specified inline inside the ListBox. This template shows how to arrange and format each item, and which pieces of data to extract from the item. The results look like this:

This barely scratches the surface of what a data template can do visually. You are free to use absolutely any WPF feature in a data template, so you are by no means limited to text. Data templates can incorporate images, graphical elements, animations, or 3D content, for example. You can also add interactive controls, such as text boxes to allow data to be edited, or custom controls that provide whatever interactive behavior you would like.

As you can see, data templates provide a remarkably easy way to format lists of data returned by a service. You can apply them directly to plain XML data as this example does. You can also use them with objects, such as those returned by WCF web service wrappers.

Web Services and Object Data Binding

The ability to bind directly to XML can be useful, but often it can sometimes be more convenient to work with wrapper objects of some kind. If you are working with a web service that offers a WSDL definition, it is often possible to use tools to generate such wrappers. You can then use WPF's object-based data binding to bind to these objects instead of binding directly to the raw XML.

For example, eBay offer a WSDL definition of their web service API, which you can download from here: (You need to sign up to their service in order to use the API, but the WSDL is freely downloadable.) eBay uses Java for it's back end, as also indicated by the server headers and error messages returned by their servers. Since it is a web service, the fact that it's implemented in Java places no constraints on the client-side technology. So you can import the WSDL into a .NET client.

You can use the web service support that has been available since the earliest versions of .NET. Alternatively you can use the new WCF (Windows Communication Foundation) tools introduced with .NET 3.0. Both technologies offer tools that will generate similar wrapper classes for the messages and associated types defined in the WSDL. One such type in the eBay web service API is UserType, which provides information about a user. The tool-generated wrapper for this extracts element values from the XML and presents them as .NET properties. We can then bind to these from WPF. The following markup binds a UI to some of the properties in a UserType. (This example assumes that some code somewhere in the application has obtained a UserType instance from the web service, and placed it into the UI's ‘data context', making it available for binding purposes.)

<Grid TextElement.FontSize="20">
<ColumnDefinition Width="Auto" />
<ColumnDefinition Width="10" />
<ColumnDefinition />
<RowDefinition />
<RowDefinition />
<RowDefinition />
<RowDefinition />

<TextBlock Grid.Column="0" Grid.Row="0" Text="User ID:" />
<TextBlock Grid.Column="2" Grid.Row="0" Text="{Binding Path=UserID}" />

<TextBlock Grid.Column="0" Grid.Row="1" Text="Email:" />
<TextBlock Grid.Column="2" Grid.Row="1" Text="{Binding Path=Email}" />

<TextBlock Grid.Column="0" Grid.Row="2" Text="Feedback score:" />
<TextBlock Grid.Column="2" Grid.Row="2" Text="{Binding Path=FeedbackScore}" />

<TextBlock Grid.Column="0" Grid.Row="3" Text="Registration date:" />
<TextBlock Grid.Column="2" Grid.Row="3" Text="{Binding Path=RegistrationDate}" />

Note that instead of specifying "XPath=..." in the Binding expressions, we are now specifying "Path=...". This indicates to WPF that we expect the source data to be in an object's property rather than in XML form. The markup above presents user information as shown here:

The advantage of taking this object wrapper approach is that it makes it easier for the client to do more than just present the data. WPF applications usually consist of a mixture of markup and code. With the data from the web service extracted from the XML and wrapped in objects, the code can easily process this data and provide whatever client-side behavior the application needs.


We've examined two very simple examples that present a WPF front end on top of Java services. The main WPF-specific feature we've exploited is data binding, which provides a very convenient means of connecting data retrieved from a service to the UI. Like any rich client application, a WPF application can of course provides whatever client-side intelligence and behavior we would like. While these examples deliberately used extremely simple visuals to emphasize that WPF is more than just a pretty face, WPF has the potential to take the prosaic but useful world of data binding and ordinary Windows controls, and enhance it with visually rich presentation.

For other content related to .NET and Java integration scenarios, see also the special J+N content page on InfoQ.

About the author

Ian Griffiths is an independent consultant, developer, speaker, and author. He has written books on Windows Presentation Foundation, Windows Forms, and Visual Studio. He lives in London but can often be found on various developer mailing lists and newsgroups, where a popular sport is to see who can get him to write the longest email in reply to the shortest possible question. More information about what Ian is up to can be found on his blog at

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • What about the REAL alternative, Eclipse RCP?

    by Neil Bartlett,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Interesting article. But your comments on Swing are a little strange - and also you've ignored the single most obvious alternative to WPF, which is Eclipse RCP.

    First off, Swing can do data binding, and so can SWT/JFace, which is the GUI technology used inside Eclipse RCP. In fact, since SWT uses native components, it avoids the problem you describe with Swing (i.e. the fact that Swing components are rendered in Java, so can't make use of the "full capabilities" of the PC - this is debatable about Swing, but definitely not true for SWT).

    Also SWT (like Swing) is cross-platform, so you can run on more than just Windows, which as you point out yourself is a big limitation of WPF.

    I know that this is an advocacy article, but if you're going to make a comparison with competitive technologies, then you shouldn't list every competitor _except_ the strongest.

  • Re: What about the REAL alternative, Eclipse RCP?

    by Przemyslaw Rudzki,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    An obvious questions one should ask is "how will the world split between those two i.e. Eclipse RCP and WPF?".

    I believe, that we are approaching the moment in which enterprise desktop will be totally ruled by the Eclipse based solutions. This is not only because soon to be released Lotus Hannover - actually not at all. This is because open source products that can be used in the office work have almost reached the level of stability and number of features that are typical to their closed source counterparts. Most of the business apps today run in the browser anyway and I cant really think of any reasons why would companies want to buy the operating system licensed per seat if they can have diskless workstations (centrally managed) with quite good, standard compliant browser totally for free. Well there is one - familiarity, but hey I guess what, SWT comes to the rescue ;-).

  • Re: What about the REAL alternative, Eclipse RCP?

    by David Li,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Eclipse RCP is a very good tool for the Java community but it's not an alternative to WPF. WPF is the next generation platform for creating Windows Applications. Eclipse RCP is about writing Eclipse plugins and applications to improve the Eclipse development platform. Apples and oranges.

    Swing/SWT are the right competition to WPF but they are more of a competitor to Winform rather than to WPF. You can't achieve the same type/level of presentation possible on WPF on Swing/SWT platform. Can you wrap a form around a 3-D surface for example, the list goes on.

  • Re: What about the REAL alternative, Eclipse RCP?

    by Neil Bartlett,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    David, I'm afraid you're quite mistaken about what Eclipse RCP is. It is a platform for building any kind of GUI application, not just IDEs. Two examples: the next version of Lotus Notes is an Eclipse RCP application. And in my job, I use Eclipse RCP to build a trading application for a bank.

    The mistake is understandable, thanks to the overloaded use of the term "Eclipse". But Microsoft developers should know all about that, with the whole ".Net 3 == WinFX" debacle

    I guess SWT will let you wrap components around a sphere if the Windows API exposes that. Swing is possibly more flexible in that you can apply arbitrary geometric translations, including 3D ones. But my question is: why on Earth would anybody want to do such things? Do users want applications that work, or applications that can wrap themselves into funny shapes? I'm sure it looks really whizzy in demos, but come on, we're just trying to give user applications to help them do their jobs.

  • Re: What about the REAL alternative, Eclipse RCP?

    by David Li,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for clearing up Eclipse RCP for me, I just went to Eclipse RCP webpage and it appeared to me all they talked about was Eclipse plugin, hehe.

    In order to do any 3-D graphics stuff, all SWT/Swing needs to do is to provide a wrapper around low level OpenGL/DirectX libraries, that's what WPF is, which is a wrapper around DirectX10. I am not implying that wrapping a 2-D form around a 3D object would be of any value but .NET developers no longer have to know low level opengl/directx libraries to do fancy stuff such as data visualization. Also, a vector-based user-interface is a big improvement for user interface design. Possibilities are endless, for example, SAP developers have been able to create a Windows Media Center like interface that navigates around complex business intelligence data and display them as 3-D charts etc, all that in 4 days of developer marathon competition using WPF. That's what's truly amazing.

    Of course, if developers want to stick with old look and feel Winform 1.0/2.0 are still available for developers to do things the old way to do things quick and easy.

  • Re: Eclipse RCP vs WPF vs Flex vs Swing

    by Scott Delap,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The >= Win XP SP2 requirement is a consideration. However, the larger issue is deploymen in general. With a corporate application this may be less of an issue since corporation administration services may be available to push out releases to 100's of machines at once. On the consumer side it is the biggest decision. With this in mind I think it may take a while for WPF to take hold in the browser market space. Should I write my app in WPF with has a 20% browser footprint or Flash which has 90%. This is the biggest thing holding back Swing apps and applets right now. The deployment issue trumps any technological ones. No one is willing to write a consumer "I don't know I need this yet app" in Java and take the chance that the average consumer can navigate JRE install hell. How many applets have you viewed that didn't load? Did you ever go back to the page to see if it was fixed?

    Changing gears slighting if you are writing a "desktop application" instead of a "browser / internet deployed application" the decision making process becomes more interesting. Eclipse RCP and Swing become viable consumer options because you can bundle Java with the installer. Adobe's Apollo will soon be ready for prime time as well. At this point evaluations can be made much more in terms of the language driving the technology, ease of development etc.

    In summary however deployment is question one...

  • Re: What about the REAL alternative, Eclipse RCP?

    by Gabe Cruz,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    settle down...

  • WPF/e

    by colin bowern,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    WPF/e is attempting to address the cross-platform support by providing a subset of WPF functionality through a browser-based plug-in. There is a Windows and Mac plug-in and one can probably speculate seeing something appear via the Mono project for Linux if demand sparks up.

    Flash was never designed for what it is doing now. Adobe is trying to redesign to compensate. The advantage I see with WPF and WPF/e is that it is fresh with not a lot of legacy to deal with. In addition the separation of code behind and front end layout helps bring design and development together. How many Flash developers really consider malicious input when developing their little flash apps among various other development security issues? Probably not as many as there should be.

  • Re: WPF/e

    by Todd Pre,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Since I've been researching cross-platform application development (creating products for the home user, I can't conciously have them not work on Mac OSX), so far my research has taken me to QT, wxWindows, GTK, and XUL -- the Mozilla API that seems to do much of what WPF does. They at least use smiilar XML declaration for the layout. Firefox web browser uses this, so does a pretty slick code editor for dynamic languages called Komodo. Anyway, I'm really interested in this WPF/e technology in what it's going to offer, since I see this as competitor to XUL. While in the past I have enjoyed Winforms and the like, my real interest for the future is writing software for multiple platforms. Has anyone heard a time from for WPF/e or anything about the functionality it will have?

  • Re: What about the REAL alternative, Eclipse RCP?

    by Ted Neward,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It really is an apples-to-oranges comparison, given that (a) Eclipse RCP provides a full "component manager" perspective that WPF lacks, and that (b) WPF is far more deeply integrated into the underlying platform (through the .NET stack) than Eclipse RCP is. I don't think anybody's suggesting that Eclipse RCP isn't useful; the goal of the article was to suggest that a .NET/Java marriage isn't quite the scandalous suggestion that it used to be.

  • Macromedia Flex

    by Mohsen Mollanoori,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think you have forgotten the excellent tool Macromedia Flex, Flex has a really good design, It's data binding is really better than other framework, action script is well suited for embedding in such applications(of course better than a strongly typed language like C#), It supports CSS, and it is backed by Java EE at server side. after all clients just need to install Flash Player(<1M) which is available almost everywhere.
    I don't want to say that Flex is better than WPF, I just wanted to say that there are other excellent options.

  • Re: Macromedia Flex

    by Todd Pre,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Yes, I've recently discovered Adobe's Flex stuff. It's quite similar to WPF, using XML as a visual markup and then codebehind binding. I just read over at Bruce Ekel's blog and interesting article about FLEX as the ultimate client runtime, and there's a link there to a screencast creating a Flex application with a TuboGears(Python) backend, though they cite that Ruby or any server technology could be used: I guess Flash people with naturally navigate towards Flex (and the upcoming Adobe Apollo, which promises as cross-platform runtime for full-blown client apps that install), and .NET will go towards WPF and XAML. What I'm looking for is the quality of runtime. I have strong desires for creating client applications that run everywhere from a common codebase. I still have nightmares about egregious Swing apps and their clunky interfaces from the turn of the century. I know that applications don't have to use solely native windows widgets to perform great on each platfom (Google's Picassa -- which has its own look --is an excellent application that performs great on Windows, but without the Window's "conventions").

  • Unified technology alternatives...

    by Peter Taps,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    My company is in the design phase of a new software product for data modeling. The data can come from a variety of databases, applications (such as Microsoft CRM), Web Services, Excel files, etc.

    It does not matter if the application is stand-alone or embedded in the browser. The things that are a must are:
    1. Rich user interface - drag-n-drop, high quality graphics rendering, context-sensitive menus, dynamically built menus, etc.
    2. Vector-based graphics - resolution independent
    3. The application should be able to access local resources such as Excel files, Microsoft Access database, etc.
    4. The ability to save/load user-defined models as local files.

    The closest application in terms of look-n-feel is probably Microsoft Visio.

    Our existing applications were all developed on .NET platform. WPF seems to be a natural evolution. However, I am also considering cross-platform support and I came across this discussion.

    Alternate technologies that are being discussed are SWT, Flex and Adobe Apollo.

    I did a little research on SWT. I did not see any mention of vector-based graphics paradigm. Did I miss something? Also, does it support our requirements #1 and #3? I guess we would use ActionScript as our programming language.

    I did a little research on Flex. However, I am not clear on how I can achieve #1, #3 and #4. Please comment.

    I did some research on Adobe Apollo. It talks about the ability for the developer to mix and match various technologies such as HTML, Flash, etc. I did not see a unified programming model. Did I miss something?

    I appreciate any comments that you may have.


Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p