[jifty-devel] Fwd: A plan for XUL::App

Agent Zhang agentzh at gmail.com
Sat Sep 8 10:02:19 EDT 2007

Hi, folks!

I'd forward the following mail to jifty-devel and seek opinions from
the Jifty people ;)



---------- Forwarded message ----------
From: Agent Zhang <agentzh at gmail.com>
Date: Sep 8, 2007 9:10 PM
Subject: A plan for XUL::App
To: jianing.yang at alibaba-inc.com

I've been mostly working on a Firefox extension last week and I've
already got a first (naive) implementation. My $boss got very happy
when I offered him a link to my .xpi file.

The buzzword of this extension is that there's NO xul in the source
tree. Template::Declare generates all the ugly XML/XUL/RDF stuff for
me, including  install.rdf. Hmm, maybe this will be the first Firefox
extension in the world produced by Jifty's Template::Declare module.

Also, jquery.js is a godsend for the Javascript part, it works
seamlessly between XUL and HTML DOMs.

This extension will soon be open sourced and the resulting .xpi file
will also been uploaded to addons.mozilla.org, according to my $boss

In the next week, I'll work on the architecture refactoring for this
project. In particular, I'd love to invent a new application framework
for XUL development. It'll be called XUL::App. I'm going to steal a
lot of good ideas from Jifty. Here's some random thoughts:

   $ xulapp app --name MyExtension  # create a directory tree
structure rooted at ./MyExtension/
   Creating new application MyExtension
   Creating directory lib
   Creating directory lib/MyExtension
    Writing file lib/MyExtension/App.pm
   Creating directory lib/
   Creating directory bin
   Creating directory doc
   Creating directory t
   Creating directory jslib

    $ cd MyExtension
    $ xulapp view --name TreeView --out  treeview.xul
    Writing file lib/MyExtension/View/TreeView.pm
    Updating file lib/MyExtension/App.pm

    $ xulapp debug treeview.xul  # will launch a Firefox window
loading treeview.xul
    $ xulapp bundle  # will generate  install.rdf, chrome.manifest,
and then package related stuff into a .xpi file

And lib/MyExtension/Application.pm will probably look like this
(Thanks to Audrey's Object::Declare!):

    package MyExtension::Application;
    use XUL::App::Schema {
        xulfule 'foo.xul' =>
            generated from {
                 'MyExtension::View::Foo' => { template => 'foo',
arguments => [...] },
            includes [qw( foo.js foo.cs )];

        xulfile 'browser-overlay.xul' =>
             generated from 'MyExtension::View::Overlay',
             overlays 'chrome://browser/content/browser.xul';

        jsfile 'foo.js' =>
            requires [qw( bar.js dom.js jquery.js )];

        xpifile 'foo.xpi' =>
            id is 'myextension at foo.bar.org ',
            name is 'MyExtension',
            version is '0.0.1',
            targets {
                Firefox => ['1.5' => '3.0a5'],
                Mozilla => [' 1.0' => '1.8'],
            creator is 'Agent Zhang',
            developers are [qw( John Mary ... )],
            updateURL is ' http://foo.bar.org/update';

Currently XUL::App is focused on FF extension development, so there
will be no server-side logic in the near future.

Modern Jifty apps use Template::Declare for their "view", and so will
XUL::App :) Jifty also has cool concepts like "model" and "actions".
Not sure how "actions" fit in the XUL world, but I can see XUL's RDF
and its wrappers are good parallels to "models". Maybe XUL::App's
model classes will simply emit JS and RDFS code for certain RDF
schemes defined there.

Unlike Jifty, XUL::App will look more like a compiler. We'll use 100%
Perl (as well as a lot of JS for sure) during the development phase,
but 0% Perl in the final .xpi package for deployment. So there won't
be any portability issues nor any big runtime that slows things down.

For the test suite part, I'd really love to see a DOM lib for
SpiderMonkey or even Test::WWW::Mechanize::AJAX on CPAN soon. Testing
XUL/AJAX in bare command line w/o launching any real web browser will
simply rock ;)

Yeah, I'm writing down crazy plans...putter++ once said on #perl6 that
such things are very bad for expectation management...but anyway...

Suggestions and comments will be greatly appreciated. Thank you :)

More information about the jifty-devel mailing list