idea.js

/*
 * ** SUMMARY **
 * App._router._route should not be empty, but contain a Route object, with the currently mapped URL parameters
 * App._router._route could be accessed as App.getRoute()
 *
 * App._router._route could be accessed as App.getRoutes()
 *
 * Is there an event which fires internally on a successful route change? 
 * I realise this would set a precedence, so window events can be used instead. It is just a nice feature, but not 100% needed.
 * 
 * The proposed changes would make creation of RBAC type systems simpler, as well as common web elements such as breadcrumbs, and contextual common views like meta/social tags
 *
 * Finally as a thought, when you specify a route, there could be a way of defining the regex associated with a parameter, to only allow numbers or a specific format
 * If a regex was notmet, it could return false. Optional params would not return if not present in URL.
 * Proposed format:
 *  options: {
        url: AppPath + 'views/tag.html',
        route: AppPath +'tag/{{tagID}}',
        routeFormat: { tagID: '[0-9]{3}'}
    }
* blocks.route('Product/{{type}}').format({type: '[a-zA-Z]'})
*/

// an application property with the current route would enable common non-routed views to have contextual output
// in the case below (a breadcrumb),it would be a chore to create a breadcrumb view for each routing option
// So the next best thing is an observable in the breadcrumb view, which all views update after routing, or by seeting an event callback for history change on the body
App.View('Breadcrumb', {
    // this would be the current route string
    // this could be extended with a formatter which turns the string coming in into an array of URL parts so the breadcrumb view can display them nicely with an each()
    currentPath: blocks.observable()
})


App.View('Tags', {
     options: {
        url: AppPath + 'views/tag.html',
        route: AppPath +'tag/{{tag}}'
    },

    tag: 'default',

    routed: function (params) {
        this.tag = params.tag;
        
        // this would then update the Breadcrumb.currentPath property
        // alternatively you could explode the route here into its part, and not extend the currentPath observable
        App.Breadcrumb.currentPath = this.options.route;                
    }  
});


// but it would be nice to have a simpler way off accessing the current route/registered routes from the app
// the examples below use App._router. Is there an argument for attatching the getRoute() and getRoutes() methods directly to App?
App.View('Breadcrumb', {
    currentRoute: blocks.observable(),

    updatePath: function () {
        // would return the current route object containing app route, params, and seperated parts of the route
        // the current App._router._route object is empty, and should return an instance of Route()
        // it is important that this also returns an object containing currently mapped URL params to avoid duplication of this task.
        this.currentRoute = App._router._route._routePath;
        // could also be accessed as:
        this.currentRoute = App.getRoute();
    }
})

// here I used this generic event. 
// Does jsblocks have an internal event that fires when it routes successfully? So hash changes could also be caught with one event.
// the event could pass the current Route object as a parameter
// if App._router._route was not empty, or if there was an App.getRoute() method, there would be no reason for an internal event as the data could easily found usinghistory/hashchange events
window.onpopstate = function () {
    App.Breadcrumb.updatePath()
}

// From this property it should remain easy to access the route object for the parameter options and individual parts of a route
routes: App._router._routes
// with the proposed new method
routes: App.getRoutes()