Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Forms for a Rich GUI
 FYI... the xameleon project I started a while back and have since held back the release while I completely rewrite the foundation of this library using FXSL and XSLT 2.0 allows you to use one base foundation (right now its XHTML elements that each have a possible child element called "style" with subsequent possible children for each CSS 2.1 property with children and/or attributes to further hold the names and values of each property for this particular element -- this may be changing to SVG as its base as it is seemingly more natural to map an SVG-like syntax to XAML and XUL (XUL's proving to be a real pain in the butt but itll get there eventually) than it is a XHTML and CSS-based syntax to SVG, XAML, and XUL) Anyway the point of this post is to point out the fact that there is definitely recognition in the industry to the fact that the ever expanding plethora of XML-based declarative languages that abound, at least conceptually, in our development world these days is probably doing more damage than it is good, further separating platforms that actually are extensions to the same base platform (e.g. XUL in Mozilla and XAML via either Xamlon or Avalon in 90% of the cases run on top of the same GDI subsystem (or variation thereof) and as such provide just a slightly different enough syntax to really [expletive deleted] you off and force you into writing two or three or four versions of basically the same code base just to appease the various "users" who prefer this or that or whatever else (I really believe that a good dose of Lithium "silently" integrated into our water systems would do a world of good in curing the bi-polar disorder that is the declarative XML GUI definition language hell we have created for ourselves to now deal with -- The supposed DLL Hell that was the 90's doesn't even hold a small blue birthday candle to the dXML Hell we are about to experience in this industry in this now almost 5 year old new millenium of ours. Unless... Again, the point of the "xameleon" project is to try and retain some sort of sanity by allowing you to build on one dXML language (d stands for Declarative if your'e wondering what I am refering to with the little "d") -- most likely SVG eventually for the reasons stated above, and then use the xameleon engine (powered by Saxon.NET which, by the way, I'm about 2-3 hours away from either releasing the 8.2 beta 1 build or putting it to bed for the night and picking it up again tomorrow afternoon to then release tomorrow night instead -- problems with jaxp compatibility stuff is the current and only slow down at the moment) to output the GENERAL GUI framework for each desired dXML output. I emphasize general as there are definitely areas in which are to far apart to do an adequate mapping job and as such require a bit of hand massaging after the fact... still, a few hours of massaging code is a lot better than a few weeks of developing a completely new code base so I think most people will be cool with it. Theres bound to be a winer here and there but to be honest I could give a -- wait, better not say that here... ;) I'm sure you get my point none-the-less ;) Some screen shots of the older C# based development UI can be seen here > http://www.x2x2x.org/x2x2x/images/xameleonGUIOne.gif < and here > http://www.x2x2x.org/x2x2x/images/xameleonGUITwo.gif <. I say older as I have since switched to a browser based UI that uses client-side XSLT 1.0-based code and javascript coupled with various ASP.NET controls and server-side based XSLT 2.0 based code coupled with Serverside ASP.NET components and .NET based webservices to make all the magic happen as it ultimately seemed to be the easiest way to ensure that you are always using the latest and greatest code base if I build it in the browser-based client/server webservices architecture that is made embarasingly easy (embarassing by the fact that my four year old can now write production ready code... if things continue going this direction pretty soon code is going to be writing us... still, it is nice being able to build a fairly significant application in 2 weeks when it would have taken 6 months using a classic Win32 client/server architecture a few years back) So, those interested in following this project can add this link to their favorites folder > http://www.xameleon.org < and check perioducally for updates or just visit XSLTBlog.com and pick your favorite XML feed which will be updated when I make more headway on this project in the next few weeks... Don't panic if you go there (xameleon.org) and see just a basic UI as thats all I had time to develop when I first launched this project a few months back... it'll change soon and it will be at the xameleon.org address so its all good.. Cheers! <M:D/> On Wed, 29 Dec 2004 16:03:43 -0800, Jeff Rafter <lists@j...> wrote: > 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> > > -- :: M. David Peterson :: XML & XML Transformations, C#, .NET, and Functional Languages Specialist 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
