Location for client-space singletons

[lxbarth]

trafficstars

Right now we hang client-space singletons like admin or user off of the Bones object - only client-side. Typically, a code like the snippet below is executed client-side to set up a global object, modules like bones-document would then rely on it.

$(function() {
    Bones.start();
    Bones.initialize(function(models, views, controllers, templates) {
        Bones.user = new models['User']();
        Bones.user.status(); 
        // ...

Two problems:

1. This pattern cannot be replicated on the server as such global objects would be in the global application scope, not in the client (= window) scope.
2. Having a global object X set up to make a module work as expected is not ideal, we should review better patterns (passing a user/admin/whatever object into constructors?)

Right now we're making hesitant use of the existing pattern described initially. If we solve this issue, we could make much safer assumptions around client space singletons and push more code into modules like bones-auth and bones-document = reuse more code.

Potential solutions

Bones could provide a 'request' object that would hang off an Express request server side and the window object client side. This 'request' object (better name?) would provide a safe space for client space objects.

More thoughts needed.

[AdrianRossouw]

I've run into this head first today.

I'm trying to build an application where the router instantiates a 'State' model, which represents which page is active and so forth. There is a central interface view, which listens to events on the state model, and handles re-rendering component views. The router would only be responsible for changing the context object. (ie: set the current page).

There's a leak in the abstraction due to this. The environment that renders the initial page, versus renders subsequent page loads, is different. This means that on the server side, there is no way to set up a state/context object for the request.

I actually think the correct solution for this is to standardize on TJ's new pages.js client side router (heavily inspired) by express, that solves this kind of thing already. http://visionmedia.github.com/page.js/

will keep you updated if i figure something out.