Lists Home |
Date Index |
> I've started the XUL Alliance a while back but so
> far everyone feels free to ignore it. See
> http://xul.sourceforge.net for details.
Off course, not because your site is bad but because XUL wasn't that easy to
use nor was it well supported and most of all badly advertised. Not that you
didn't made any effort but do you have the same deep pockets as Macromedia?
On the other hand, some elements of MXML are definitively superior for a
practitioner. Just take a look at the code below:
<?xml version="1.0" encoding="iso-8859-1"?>
<mx:TextInput id="source" width="100"/>
<mx:Button label="Copy" click="destination.text=source.text"/>
<mx:TextInput id="destination" width="100"/>
a) Its declarative. You really create objects with markup. An element is
equivalent to an object; quite easy to grasp for any object oriented
b) No needs to use artificial constructs to bring an object into the ECMA
script word. It's already instantiated. Now compare that to the "W3C
standard way", you have to "explicitly" instantiate the object into the ECMA
script world using constructs like:
var source = getElementById("source");
var destination = getElementById("destination");
Bottom line, you can't create compact construct like the one proposed by
MXML (and simply declare the script in the event handler"
And so on and so forth...
Moreover, they sell a tool that produces the code for you by drag and
dropping! Enough to catch the interest of practitioners pressed by time
constraints to produce an app for yesterday.
XUL is not a bad idea Gerald, it was simply badly implemented, badly
marketed, badly supported. And this doesn't suppress the fact that you have
probably invested a lot of efforts into your site, simply that you do not
have the resource to push that into the market and that Mozilla was a living
dead (or sleeping beauty) for a long time.
Didier PH Martin