Hello, Like many people here, I made complex GUIs (using heavily customized grids, flexgrids, treeviews, etc.) on many platforms and also with a custom XUI motor (with limited functionalities) I wrote about 3 years ago. Also, I'm currently working on that subject for my master degree (doing it part-time). Well, all I can say is that there's nothing like getting your hands dirty to feel the difference. At the time, I was working on a project in Bogota, Columbia and they were asking for many small and sometimes not so small changes in the GUI (about 50 data entry forms amongst other things). If for everyone of them, we would have needed to make the changes in code (which would have certainly become a mess no matter how hard we would try not to), test/debug, repackage and reinstall on every workstation, THAT would have been a PITA ! Now with a single XML file stored in the DB which our application retrieved at startup and then used to create its GUI, the only steps needed were modifying the XML file (much easier and less error prone than code), testing the changes (much faster become less likely to have bugs) and update the DB. No recompile, no packaging, no deployment, nada. On top of that, having a central point for generating the GUI, you are assured that all your widgets will have the same look&feel and if you make a change, it will be reflected in ALL your widgets, no matter where they are.
Also, the first GUI was a tad long to make because the programmers needed to learn the syntax of the XML (long here meaning about 1/3 of the forecasted time). After that, it was just incredible : 1/5 to 1/10 of the forecasted time. In total, we saved about 2000 man/hour ! That's the kind of argument well understood by management usually :) IMHO, stating that the customer will request more is an indication that your tool allows you to be more flexible, something the customer will want to exploit. I can see how an overly complex/buggy/incomplete XUI toolkit can actually get in the way and actually can become worse than not having one at all, but then, all you need to do is choose a good one :) Sébastien Lorion -----Original Message----- Date: Tue, 22 Jun 2004 21:05:30 -0700 (PDT) From: Gerald Bauer <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [xul-talk] Michael Gloegls (of Team Hibernate) on XUL Reply-To: [EMAIL PROTECTED] Hello, allow me to highlight Michael Gloegl's blog story titled "XML is not ‘more managable’". Here we go: Some time ago I encountered a really strange statement from somebody advocating XUL/HTML. He said that he thinks XUL/HTML is a great idea, because ‘it makes it easier to manage situations where multiple customers all want different customization of the GUI’. His reasoning was that ‘if you do it in Java, you’d have to manage multiple versions of the same class file, which is a pain in the ass’. Well I agree that this is a pain in the ass. But using XUL/HTML, does it really make the situation any better? Instead of multiple different versions of a java file, you now have multiple different versions of a XUL/HTML document. Wow great, and those multiple versions don’t have to be managed anymore? If you can just modify the XUL/HTML files once, and then leave them at the customer and just update the java files, well you can do just the same thing with classes. But the fact is that the customer will want to have more GUI customizations, and even more important, your core API will change over time when releasing new versions, and the old XUL/HTML files will no longer match the core API. Just a quick insertion: This is not XUL/HTML bashing. XUL/HTML might be the best thing since sliced bread, or it might be total crap (I rather tend towards the later opinion), this is not really the case here. What I really can’t stand anymore are those people who thing just moving things to an XML file makes it magically more ‘customizable’ or ‘manageable’. So in fact by introducing an additional layer of indirection, you have gained nothing and instead added another possible point of failure and another framework to learn for the developers. In fact if you have parts of an application which are required in many different versions, and can’t be guaranteed to be stable forever, you are in for a huge happy life anyway, no matter if it is a Java class or an XML document. There are a huge number of cases where recreating features of a programming language in XML just doesn’t make sense. I really wish those people would focus more on designing better APIs and less on XMLisation of everything. Source: http://www.gloegl.de/blog/archives/xml-is-not-more-managable Well, if Michael thinks it doesn't matter if your UI is using Java or XML I challenge you to recreate your blog story page using Java Swing and see if you can match the (X)HTML+CSS combo. If you're still not convinced why not try to recreate lets say the Amazon.com frontpage using Java Swing online @ http://www.amazon.com for some more insight? Or why do you think is Sun's frontpage @ http://www.sun.com not a full-page Java applet? Do you see why Java is irrelevant and why a REST-style XML format beats an API anytime? - Gerald ------------------- Gerald Bauer XUL Alliance | http://xul.sourceforge.net United XAML | http://xaml.sourceforge.net The Thinlet World | http://thinlet.blog-city.com --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.708 / Virus Database: 464 - Release Date: 6/18/2004 ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ xul-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xul-talk
