---------------------------------------------------
About Firebug / Firebug Lite future
---------------------------------------------------
I'm very glad to see such changes in the horizon! I think this is
an important step to the rising community of developers that
are working with Firebug code.
I believe this is also a great opportunity to redesign the Firebug
architecture to make things easier in the Firebug / Firebug Lite
relation.
The Firebug Lite 1.3 architecture allows to use the same
panel/module code as Firebug with "minor" modifications.
It would be great to separate the code not only by
module/panel, but also in two layers (cross-browser, and
browser dependent layers). The browser dependent layer
is a "piece" of a module that uses some internal functionality
of the browser like a XPCOM component. The cross-browser
layer would be the same used by the Firebug and Firebug
Lite versions. This way, we will ensure that the changes in
the "cross-browser layer" will be automatically ported to
the Lite version.
For example, there would be a consolePanel.js,
consoleModule.js, and consoleModuleX.js, where
the "X" file would contain the XPCOM dependent code.
Of course, the name convention here is just an
example. What really is important is the separation
of the cross-browser and the XPCOM dependent codes.
---------------------------------------------------
About modules and scope
---------------------------------------------------
2010/1/17 John J Barton <johnjbar...@johnjbarton.com>
> If you read:
> var file = require("file");
> then it really makes you think that this means "I need you to load
> 'file.js' and give me the result". But I think we can use it in a more
> JS like way: "I need the object 'file' in my scope". And this part is
> really all we need for now.
Last year I implemented a small JS "library" (1kb size minified),
inspired by the FBL.ns() way of handling scopes, with some
more inspiration from the Helma NG implementation[1], which
uses 3 different types of loading: import, require, and include.
If you are interested, I can upload this code to the repository,
so you can take a look how it is implemented, and use it as an
inspiration to the Firebug implementation.
Taking for example, the current implementation of FBL.ns:
//----------------------------------------------------------
FBL.ns( closure );
//----------------------------------------------------------
Using the implementations I mentioned as an inspiration,
It could be something like this:
//----------------------------------------------------------
FBL.ns(namespace [ , scopeDefinitions ] , closure);
//----------------------------------------------------------
Here is some basic example of a module that doesn't
require any other module.
//----------------------------------------------------------
FBL.ns("domplate", function(scope) { with(scope) {
exports({
domplate: function()
{
// exported function
}
});
}});
//----------------------------------------------------------
And here, an example of a module that depends on the
"domplate" module, and loads it with the "import"
definition, that is, it will be loaded in the current scope
using the "domplate" namespace.
//----------------------------------------------------------
FBL.ns("Firebug.Console", {imports: "domplate"}, function(scope) {
with(scope) {
exports({
log: function()
{
logTag.append(...);
}
});
// uses the imported domplate in the current scope
var logTag = domplate(...);
}});
//----------------------------------------------------------
A more complex example would be:
//----------------------------------------------------------
FBL.ns("Firebug.CSS",
{
include: "Lib.*",
imports: [
"domplate",
"Firebug.Editor"
]
},
function(scope) { with(scope) {
exports({
startEditing: function()
{
// uses the imported Firebug.Editor
var editor = new Firebug.Editor();
}
});
// uses Lib.extend as "extend"
var obj = extend(otherObj, {});
}});
//----------------------------------------------------------
This implementation has the same basic principle
of FBL.ns(): it defines a scope with a closure and
a "with" statement. On top of it, it uses a namespace
to identify each module, and a scope handling
mechanism that allows you to choose how exactly
to embed to imported module in the current scope.
regards,
Pedro Simonetti.
[1] http://helma.org/wiki/Helma+NG/Modules%20and%20Scopes/
