OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Forms for a Rich GUI

[ Lists Home | Date Index | Thread Index ]

I'm not sure what is meant by Winforms being obsoleted by XAML. The most succint pseudo-official statement of the Winforms vs. Avalon (not XAML) positioning I've seen is at http://blogs.msdn.com/johnmont/archive/2004/11/27/271026.aspx 
 
I think using XML for using XML sake doesn't sound like a good idea. It isn't clear what in your requirements actually needs XML for the UI aspect especially if you'd been planning to use a traditional GUI library. 
 
-- 
PITHY WORDS OF WISDOM
The only person who gets all his work done by Friday is Robinson Crusoe.   

________________________________

From: Jeff Rafter [mailto:lists@jeffrafter.com]
Sent: Wed 12/29/2004 4:03 PM
To: xml-dev@lists.xml.org
Subject: [xml-dev] Forms for a Rich GUI



I am working on a project which is currently in the planning stages of a
rewrite. Already the project has some killer XML technology built-in and
leveraging this has only provided benefits along the way. The plan for
the product interface currently is a rich client built on WinForms in
C#. It is my understanding that this technology will be obsoleted with
the newer tools out of Redmond (i.e. XAML). Additionally this is not
very extensible. So we decided to consider alternatives (i.e.,
leveraging more XML technologies). Unfortunately the tangled morass of
competing projects and products has left us wondering which is best (for
our situation). This is our list, in no particular order:

    (A) Stick with WinForms, rewrite that part later if necessary
    (B) Use an SVG interface with SVG components
    (C) Use XForms
    (D) Use SVG and combine it with XForms
    (E) Use XUL (Mozilla/chrome)
    (F) Use XAML

It is also possible that we either need to print or transport documents
and this would likely mean that we would target one of the following for
that piece (1) XHTML (2) SVG (3) XSL:FO. For this piece I would venture
to guess that XSL:FO would be the "right" technology but we already have
a lot of SVG work embedded, and painting to a printer canvas is easy
enough. I wouldn't want to use XHTML because of the poor support for
pagination... but I could be convinced otherwise.

Some of our requirements include:

    (A) High speed
    (B) Data from/to an XML document in memory
    (C) User customization/ extensibility
    (D) Rich gui controls
    (E) Strong event model

So are there any suggestions out there? I have used most of these
technologies already but never for side by side comparison. Answers like
"leave us alone, go hire a consultant" are helpful... but then I would
ask what skill set that consultant should have :)

Thanks in advance,
Jeff Rafter

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>







 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS