Closed mfferreira closed 12 years ago
I think both ideas can join like so:
if (exports) {
exports.create = function() {
return joli;
};
}
Unfortunately, that doesn't allow you to have two separate joli
instances, since they're created off the same var.
Maybe:
var joliCreator = function() {
var joli = { ... };
return joli;
};
var joli = joliCreator();
if (exports) {
exports.joli = joliCreator;
}
Then, you can get a new Joli instance by calling require('joli').joli()
, and yet joli
is still a global var if you're not using CommonJS.
Oh right. Well u take some parts out from that:
var joli = function() {
this.each = function() {
...
};
this.extend = function() {
...
};
return this;
};
if (exports) {
exports.joli = joli;
}
Its about the same thing, just a different approach.
But that doesn't give you parity for existing apps, since joli
is now a function that needs to be executed first, correct?
For example, if someone isn't using CommonJS, they would now have to use:
var myjoli = joli();
That's why I suggested a separate function joliCreator()
, then still setting joli
as an object, and exporting that, you get parity for non-CommonJS cases, as well as the exports for CommonJS (which would be slightly differently called like var joli = exports('joli').joli()
, but that seems reasonable)
Correct. Maybe just one minor change then:
var joliCreator = function() {
var joli = { ... };
return joli;
};
var joli = joliCreator();
if (exports) {
exports.joli = joliCreator();
}
Cool, that works great.
Hi guys,
I have just pushed a variation of your common work :
var joli = {
// all the previous stuff
};
if (typeof exports === 'object' && exports) {
exports = function() {
var api = {
connect: function(database) {
if (database) {
joli.connection = new joli.Connection(database);
}
return joli;
}
};
return api;
}();
}
This allows to either load the library the way we did before:
Titanium.include('joli.js');
joli.connection = new joli.Connection('your_database_name');
or the new way:
var joli = require('path/to/joli').connect('your_database_name');
Thanks both for the contribution!
Thanks Xavier. The one change that isn't captured in your update is the ability to use Joli on two separate databases, because var joli = {}
is initialized at the root of the module, instead of in a function closure: function() { var joli = ...; return joli}
.
The parsing of CommonJS modules may be cached, so the root-level var joli
is only ever initialzied once. With your change, the second call to .connect()
will overwrite the settings of previous calls.
For example:
var joli1 = require('path/to/joli').connect('db1');
var joli2 = require('path/to/joli').connect('db2'); // joli1 now points to db2
I have a similar patch I'm working with. Instead of looking for exports at the end, I wrap the
var joli
statement in an acreate
function that returnsjoli
.The benefit of doing it this way, is you can use joli for two separate connections/databases.
The downside is, this forces Joli to be a CommonJS module.
Any thoughts on how to have it flexable (checking for exports, so it isn't required to be used as a CommonJS module) yet keeping the
var joli
in a closure to allow for separate joli instances?e.g., my code is: