Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

kungfuftr (5129)

kungfuftr
  (email not shown publicly)

Um... I'm Scott apparently... FreeBSD, Perl, Mozilla and hopefully some xlib.

Journal of kungfuftr (5129)

Wednesday June 30, 2004
12:31 PM

Mozilla

[ #19602 ]

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:

  1. 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.

  2. 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.

  3. 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...

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Check out XUL-Node on CPAN.
    • 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);
        </s

      --
      -Scott McWhirter- | -kungfuftr-
      "JAWK - Just Another Whiny Kid"
      • 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?
        • 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 fi

          --
          -Scott McWhirter- | -kungfuftr-
          "JAWK - Just Another Whiny Kid"
          • > 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 attribut
            • 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

              --
              -Scott McWhirter- | -kungfuftr-
              "JAWK - Just Another Whiny Kid"
              • > 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