I just wanted to refute the argument that just because something is in XML it is not necessarily easier to handle - especially not regarding the "multiple paralell versions" problem.
I fail to see how you've succeeded in that regard.
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?
Well, has anybody done that with XUL yet?
No, because HTML+CSS+Javascript is more than capable of handling it, and because XUL isn't supported in IE. That doesn't mean it would be any easier to support in Java, or that it would be any easier with the Java-like Microsoft VM. (Hint! Hint!)
> I really don't know. I have
not much XUL experience, which I freely admit. But I suspect (like it always is) that easier usage comes with reduced flexibility, not just because one is Java and the other XML.
Of course. You can always invent some strange widget that would be hard to implement in XUL. However, if 99.9% of your GUI it made up of common UI widgets, flexibility isn't an issue. Furthermore, once you develop the XUL needed for a specific widget, you can use XBL to bind it to an element, thus making the XUL code reusable. Since the XBL file you use is part of the style sheet, you can use a different XBL file for every alternative style sheet. This makes choosing the GUI customization of your choice as easy as clicking "View->Use Style->[Style Name]" in your browser menu (assuming your browser supports multiple style sheets).
> So I'd be really interested to
see an Application using things like heavily customized JLists or JTrees, or one of the other Components that make Swing so complex. I doubt it would be much easier or understandable than the equivalent Swing code.
I'm not familiar with JLists or JTrees, but it would appear that this is an issue of the level of customizability, which is not the same as managing customizations.
Do you see why Java is irrelevant and why a REST-style XML format beats an API anytime?
If you wouldn't hand out such extreme and IMHO untrue comments, probably XUL would gain more acceptance.
I agree. What I think he means, though, is that technologies like XUL and Web Forms 2.0 may result in a decline in the use of Java for web applications. Whether Java is better suited for the development of a specific kind of web app depends on the application in question. In reality, I suspect we'll see a lot of Java serverlets with some kind of XUIL on the client side. This is especially true for businesses that want to keep their data algorithms a secret.
Besides, most people and businesses don't need a heavy level of customization. Giving people more options than they need can be a distraction from the task at hand. For proof, just look at the last two Star Wars movies. ;)
This is one of the reasons I don't think XAML will do well as a language for web apps. There's so much you can do with XAML, and yet there's so little separation between the semantics and the presentation. Everything I've seen of MS XAML so far has convinced me that it's designed to create a single detailed GUI rather than a high level layout that is fleshed out using style sheets.
Microsoft just doesn't get the whole concept of themes and skins. The want a GUI to be totally under the control of the programmer. By contrast, things like themes and alternative style sheets put more and more power in hands of users to control appearance and layout. Meanwhile, how do technologies like XAML improve the lives of users aside from providing some nice eyecandy? Better to use a simpler, easily skinnable XUIL like XUL, which would be easy to implement on top of Avalon.
-------------------------------------------------------
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
