xa.js - simple lightweight javascript framework

The first thing I'd do is remove all the useless comments like

// return the Class object which is now ready to be further extended.
return Class;
...
// execute constructor method if present
if (this.construct) this.construct.apply(this, arguments);
...
// store config
config = scope;

and a million more.

The second thing I'd do is stop using tabs for indentation. Use 4-space indentation instead.

In your for-in loops, ALWAYS use a hasOwnProperty call or Douglas Crockford will revoke your JavaScript privileges. For example

for (var i in config)
    this[i] = config[i];

needs to become

for (var i in config) {
    if (config.hasOwnProperty(i))
        this[i] = config[i];
}

or the world will end in 2012, and you really don't want to be responsible for that.

Stuff like

if (complete === true || ...) ...

is redundant.

Here and there there is an inconsistent use of braces, normally you don't use them for one-line statements but occasionally there is stuff like

if (scope instanceof Function) {
    target = scope.prototype[name];
}

Sometimes you make useless checks like

if (jQuery !== undefined && jQuery instanceof Function) ...

undefined isn't an instance of Function, so you can skip the undefined check.

Oh, and instanceof should generally be avoided anyway, since objects created in a different window will return false and IIRC there is an IE memory leak with some COM+ objects, so I'd just replace it (and others like it) with if (typeof jQuery === 'function').

window.xa = window.$xa = window.XA = new xa();

I'd pick just one of these, three with nearly identical names just pollute the namespace.

So yeah. I haven't really looked into what this does a lot, just browsed the code and picked at obvious things, but it looks kinda promising. Good luck. :-)

If for some reason you need support for Safari 1.3 and IE 5, which don't support hasOwnProperty, this will work reasonably well.

if (typeof Object.prototype.hasOwnProperty !== 'function') {
    Object.prototype.hasOwnProperty = function (prop) {
        var type = {}.toString.call(this).slice(8, -1);
        return this[prop] !== undefined && this[prop] !== window[type].prototype[prop];
    };
}

When you run tests like

Log.assertion('type', !!(
    xa.u.type(function(){}) === 'function'
    && xa.u.type({}) === 'object'
    && xa.u.type([]) === 'array'
    && xa.u.type('string') === 'string'
    && xa.u.type(null) === 'null'
    && xa.u.type(undefined) === 'undefined'
));

how do you tell what's failing?

If your tests are going to help rather than hinder code maintenance, they should tell you exactly what's going wrong.

With the above, if xa.u.type('string') returns 'spam', all the info about the values being compared, and the line number of the particular && clause that is false is lost before it reaches the code maintainer.

In the case of a framework you want to be generic I understand, but a few things I personally found too generic, such that I had multiple ideas what they might be and no idea which is right:

• config
• context
• scope

Is your config object derived from an xml file? Is it handed in by every single class? app? only uncommon apps? maybe give it a more explicit name, xaAppSpecificConfig or some such? (or is it class specific? I'm really not certain). Same type of things for the others, I know what scope is in normal programming, but again is it class or app specific? If it's class specific, does that mean if I changed the scope of a class to another app it would no longer be available in the previous app but would be in the new one? Or is scope merely an inheritance definition such that the inherit mechanisms would be different?

Little thing I saw in your utils.extends where the large for loop is, the entire for loop's activity is in a nested if, so reverse the bool check of the if and put a continue in it so the rest of the code can be one tab less and clearer to the fact that the if means "else do nothing" in your current code:

for ( ; i < length; i++ ) {
  // Only deal with non-null/undefined values
  if ( (options = arguments[ i ]) != null ) {

should be:

for ( ; i < length; i++ ) {
  // Don't deal with null/undefined values
  if ( (options = arguments[ i ]) === null ) {
    continue;
  }

Next thing is generally you want to order your class contents as:

• member value/property instances
• constructors
• event handlers (in sequence if they occur as such)
• methods
• nested type implementations

And the reason for this, while it is a style thing, it really is more about readability, when you read a method and you see a member you want to know about, I think for a large part of the industry they expect to look up to the top of the class to see it's instance definition, and if they see a method they tend to look down the code for it's implementation if they want to go into it (side effect of how we read, the next thing that happens in a book is on the line below the previous, and as such we order our methods in execution order descending similarly).

You got the order mostly right, though the BaseApp is a member level instance and used as such, though defined long after the other member level instances (apps/libs/utils/etc).

Also at the very bottom of the file you have a bunch of member level stuff below nested type implementations.