Mozilla... i loves it... I'm not just talking about the browser, but the project as a whole. I mean everyone know about the mozilla suite, firefox, thunderbird, chatzilla and even the spin offs like camino and galeon, but there is so much more to it:
Branding...
For those who've been looking at mozilla lately, they'll notice a nice site and polished graphics, but i've been around mozilla since the suite was in it's 0.5/0.6 stage and it's been a hell of an improvement. Now that mozilla has moved out from under the grasp of AOL, it appears that the project is really concentrating on the end user, which is sorely lacking from many open source projects.
Framework...
I've been looking at the mozilla framework for quite some time now and it's amazing. It's got a lovely rendering engine called 'gecko' and produces nice standards compliant screens for it. What most people don't realise is that when netscape started the gecko rendering engine, they designed it to not just render HTML, but also other SGML style languages. In the instance of the browser... not only is the HTML being rendered, but the browser interface itself is (via XUL). As well as the loveliness of gecko, there's also things like XPCOM and XBL, which allow you to define your own CORBA style interfaces to elements and this allows any interface to be used wether from python, C, C++ or javascript.
Standards compliancy
This is an incredably important thing these days and at my current job, it's something that we run into everyday. We currently have a javscript based framework which needs to work cross-browser and not only do we have CSS woes (IE only _truly_ supports CSS1) but the javascript DOM interface is nightmarish. The hacks to make IE work in a sane way are probably as long as the functional code in mozilla would be. This isn't to say mozilla doesn't have its faults... but they're a hell of a lot less.
I'm having a bawl with mozilla and shortly will be trying to get a nice xlib XPCOM interface setup so that i can have a mozilla framework based window manager and desktop toolkit. The one thing i really miss within the framework, is the ability to use perl with it... there was a perl XPCOM binding several years back, but it became unmaintained and no longer works. If I was quite daring i might have a try, but I believe it'd be out of my sphere of knowledge. Why would perl be nice to use in a mozilla framework based system? mainly... because the rendering engine works on the fly, more rapid development cycle, you'd be able to use things like Class::DBI, Template::Toolkit and the like directly with GUI components! nuff said... mozilla project rocks...
Re:XUL and Perl?
kungfuftr on 2004-07-01T00:41:07
Nice... I see it's a rather recent addition to CPAN. This is rather nice, but without proper xpcom support, wouldn't be as extensible. With XPCOM, everything that you can do DOM wise in the browser with javascript you can automatically do with perl, giving you the ability to have:
<script type="text/perl" language="perl">
my $text = $document->createNode('p');
$text->{'value'} = 'Hello World';
$document->body->appendChild($text);
</script>Lots of people give javascript a hard time, but it's really quite a lovely language and ECMAScript 262 looks to make it even lovelier!
Re:XUL and Perl?
eilara on 2004-07-01T02:48:00
Your example becomes, in XUL-Node:
Window(Label(value => 'Hello World'));
It is just a little Perl sugar over the API you showed.
What can you do in Javascript with XPCOM that you cannot in XUL-Node, which makes it more extensible?Re:XUL and Perl?
kungfuftr on 2004-07-01T10:20:02
the full DOM API (including most of DOM2), things like dynamically append and reappend element nodes to different locations within the document. XUL::Node allows you to print elements very easily, but it doesn't let you mess about with that document once its been rendered. Some good documentation on this sort of stuff is along the lines of is to have a look at seamonkey's XPCONNECT ability and the python/ruby xpcom bindings.
What would it mean... well say for example you've got a javascript event that fires when you've got a dropdown box that would populate a text field. Using XPCOM, you can get javascript to call a perl method that will return text based on the option you've selected, etc. Has a heck of a lot of nice stuff...
Re:XUL and Perl?
eilara on 2004-07-01T10:56:14
> the full DOM API (including most of DOM2), things like dynamically
> append and reappend element nodes to different locations within the
> document
Next version will have support for disposal of nodes, and re-parenting.
Very easy to add.
> XUL::Node allows you to print elements very easily
Yes it allows you add nodes to the document very easily.
> but it doesn't let you mess about with that document once its been
> rendered.
You mean re-parenting and disposal?
Or do you mean calling attributes/properties/methods:
$window->sizeToContent(1);
$button->value('ok');
$box->style('background-color:green');
This is supported.
> Some good documentation on this sort of stuff is along the lines of is
> to have a look at seamonkey's XPCONNECT ability and the python/ruby
> xpcom bindings.
Can it be done in Javascript? Then it can be done in Perl using XUL-Node.
I am still looking for a feature request in your critique, besides node
disposal and re-parenting.
XUL-Node lets you send the DOM commands in Perl. It will translate them
to Javascript. Any command. And of course the Perl can be on a different
machine from the browser.
What is the difference between going: Perl->XPCOM, vs.
Perl->HTTP->Javascript->XPCOM? Serialization and other distributed
application problems have known solutions.
The only difference may be in performance or ease of development, not in
programming power as you suggest.
> well say for example you've got a javascript event that fires when
> you've got a dropdown box that would populate a text field. Using
> XPCOM, you can get javascript to call a perl method that will return
> text based on the option you've selected, etc. Has a heck of a lot of
> nice stuff...
Here is the relevant code from menulist example in the distribution,
which does what you seek:
Window(SIZE_TO_CONTENT,
HBox(ALIGN_CENTER,
MenuList(selectedIndex => 0,
MenuPopup(map { MenuItem(label => "item #$_", ) } 1..10),
Select => sub {
$label->value
("<= selected item #${\( shift->selectedIndex + 1 )}");
},
),
$label = Label(value => '<= select item from list'),
),
);
You are right that not ALL Javascript features are supported (see TODO),
but it seems there is no theoretical limit here. Definately easier to
code missing features than to revive XPCOM-Perl bridge...
Re:XUL and Perl?
kungfuftr on 2004-07-01T12:45:09
I suppose what i mean is, that XUL::Node is very dependant on their being an external engine which does lots of different bits and bobs. There's also this issue that you're using 2 extra layers (HTTP+JavaScript) which means that it's more prone to error.
We've been doing something similar my current employer, but more on a HTML basis as posed to an XUL one and there are quite a few limitations to the RPC mechanism... for example:
How do you make the software interact with external devices such as barcode scanners, smart card systems, local mediums such as files on disk and things like registry melarky.
That sort of stuff is well out of the range of an RPC mechanism and could be easily done within XPCOM stuff. XUL::Node looks lovely and i'll defenitely be playing with it, I just know that no matter how good it is you are still quite limited by it due to javascript security restrictions, which are something you cannot get past easily.Re:XUL and Perl?
eilara on 2004-07-01T22:25:06
> I suppose what i mean is, that XUL::Node is very dependant on their
> being an external engine which does lots of different bits and bobs.
Do you mean the XUL::Node code itself? But if there was a viable Perl-
XPCOM bridge you would be dependant on that. What is the difference?
Anyway, nothing in XUL-Node does lots of anything. It is a very simple
tool.
> There's also this issue that you're using 2 extra layers
> (HTTP+JavaScript) which means that it's more prone to error.
Yes, you can now be hurt by XUL-Node developer Javascript errors. But
this is only if XUL-Node is not done right. In which case I would not do
it at all.
There is also the issue of speed.
Once you try it, you see these are non issues at all.
> We've been doing something similar my current employer, but more on a
> HTML basis as opposed to an XUL one
Cool. The Half Object pattern is very useful.
> and there are quite a few limitations to the RPC mechanism... for
> example: How do you make the software interact with external devices
> such as barcode scanners, smart card systems,...
As you say later in your post, these are Javascript security limitations.
RPC is not the problem.
Ok, I see what you mean. XUL-Node is not for you. It is focused ONLY on
the XUL user interface concern. Not the full mozilla enchilada.
It could be extended for what you want, but as you say, the extension
itself would not be in Perl.
XUL-Node is aiming to provide an alternative for web developers, not
desktop developers.
> XUL::Node looks lovely and i'll definitely be playing with it
And tell me what you think!
