makesites / brisk Goto Github PK

The view can be automatically defined (unless specified) from the path of the request.

Following a convention of fallbacks, for example for page/subpage:

page-subpage.html
page.html
view.html

Every extension may need to have common methods defined as part of it main lib.

An easy way to do that (without asking too much from developers) is by extending a base class that encapsulates those methods.

Initially an app folder wasn't created in the brisk lib, so there is no confusion with the user's app folder.

But in practice containing the base classes using the same organising means there's and easier learning curve for new adopters and discovery when you are looking for the base class(es).

In conclusion, it's best if the controllers, helpers, models, views are moved as subfolders of a (default) app folder

Currently the URL is split and compared against a controller and its methods.

If a method is not found it reverts to index, but the method name that was looked up is passed to the controller unchanged.

Instead of using the method name as a variable in conditioning it is best if it's removed from the passed parameters and added in the query object.

There is of course the manual process of defining a method as private with isPrivate on the first line, which will make all direct requests to the method (through a url) end.

But to automate things even further it is best to stop all requests that have a method that starts with an underscore _, ex. this will not be processed:

http://mydoma.in/_getUsers

This should give enough room in the namespace to define a set of classes in the controller that are not accessible.

It has been an express.js tradition to place the layout with the views.

It's hardly ever the case that a real website will only ever use one layout and when many layouts are populating the views folder it may become cluttered.

As a convention, Brisk could host all layouts in app/layouts, with default being the main layout.

This is the same requirement as in KISSCMS #68

Need a session controller to communicate info to the client-side app

Although having a one level deep controller stack is a clean convention, and a limitation that helps for a cleaner route table, there are cases (especially in plugins) where some controller needs to be nested.

For example, the [twitter] module may have links that belong under the api namespace. So a request to the twitter api may look like:

/api/twitter/[request/uri]

The controller that accepts those requests needs to live either in an api folder or be named api-twitter.js.

Either convention should have the same effect.

Error:

/Users/tracend/Repositories/Websites/cloudvisio.com/node_modules/brisk/app/controllers/main.js:25
        res.locals.site = brisk.loadConfig('site'); 

Obviously most of the time locals is there but for the off shoot where it's not it needs to be set.

Less files in production need to be converted and minified.

A piece of repeated code seems to be switching between different request methods in a REST api fashion.

This could be automated with a generic method in the main controller that redirects the request based on a preset list of methods (variable per endpoint).

Specifically, if the method is named rest then any given endpoint may redirect based on the request method as such:

endpoint: function( req, res ) { 
      this.rest({ 
            get: readEndpoint, 
            post: createEndpoint, 
            put: updateEndpoint, 
            del: delEndpoint 
        } 
} 

In the above example, readEndpoint, createEndpoint, updateEndpoint, delEndpoint are private methods of the controller.

Brisk is trying to find a config file named brisk.js (which merges with the default config)

If not found the app fails.

It would be better if this was optional - in fact if there is a config object passed maybe this lookup can be excluded...

Currently the app root is expected to be passed as a local var of the app.

app.locals.root = __dirname;

Although it may have meaning in that context its also necessery to be defined as part of the default configuration.

As the location of that file (default.json) is known and fixed, there shouldn't be a problem saying something like:

root : path.normalize(__dirname + "/../../../");

Currently the creation of the session store is left as a choice of the developer.

It makes sense though to expect sessions as a need for all apps that use Brisk.

In addition a reference to the sessions store at site.sessions might be an easy way to pass them onto other modules/middleware.

Expecting a db in the modules init with a fallback to MemoryStore might be enough to get this working in a generic way.

Provide a straightforward middleware for CORS support, along these lines:

http://stackoverflow.com/a/7069902/1247359

When looking up paths there's a warning showing up

path.existsSync is now called `fs.existsSync`.

Need to replace code?

the framework should automatically load (on init) all the helper files located in both the module "helpers/" folder and the "app/helpers/" folder...

Develop a controller that will use a Page() model to save 'static' content in a SQLite db.

This may be the fallback function of Brisk if no dynamic routes are available - hosting for example the 404 page and other static content (ex. an about page)

Current inheritance allows extending existing objects (ex. options) using _.extend

This should be enhanced to allow second level objects to be merged and push items in arrays...

Apart from refusing to access all methods that start with an underscore, there are use cases to list the methods that are private - possibly in an array format in the options.

Some of the helper files might need to add extra configuration to the express server.

Need a simple way to achieve that without disrupting the existing framework

This version of express.js introduces a number of breaking changes, specifically:

• The removal of app.configure
• The automated initialization of app.router

Detailed list of changes:
https://github.com/visionmedia/express/wiki/Migrating-from-3.x-to-4.x

An options object that is inherited from the main controller could be useful for saving setup variables, as it is accustomed for client-side js.

The method getClass is currently the main method to get the parent class when extending any controller/model

The scope of this feature needs to be broaden and specialised based on the type of class.

So for example we might have:

var NewController = brisk.getController("main")

var NewModel = brisk.getModel("base")

These methods may be focused requests of the more generic getClass(), in which case the equivalent syntax would be:

var NewController = brisk.getClass("controllers/main")

var NewModel = brisk.getClass("models/base")

getClass should lookup in all paths using findPath instead of expecting everything in the default location. This means the class may live either in app folder, in a plugins folder or in the default folder - with that priority order.

Instead of creating custom libs for "standard" functions like minification it is better to include components that are specialised for the job.

Including Grunt.js will enable utilizing existing components (like minify) but also allow the extension with more tasks - using the grunt.js framework.

With the increasing demands put on the render method it's only reasonable to pass the ``req` object to assist in the logic.

the variable for the view filename, saved at res.view could be available during rendering to assist in page specific logic.

Rendering web page markup should be cached and template parsing should be conditional.

Currently all the routes are setup on brisk init()

This has a number of side-effects:

1. The routes that are setup by helper files are overwritten
2. The order of the app configuration breaks, with app.router included prematurely

To fix the hierarchy the helper files will need to include their routes on process.nextTick()

And Brisk should respect the routes setup by helpers and execute the setup asynchronously

A base data controller has been included for a while now but not put into real use.

The purpose of this controller is to provide a foundation for creating a data api, used either for a local client app or as a distributed remote service.

Naturally the convention that derives from this decision is that all api URLs will be:

http://domain.na.me/data/{{scope}}

the configuration schema needs to be standardised and the config options need to ba available to all helpers / controllers that are loaded.

Major feature of the framework should be the facilitation of re-usable code by providing an plugins folder to drop in files.

Each plugin should be contained in its own sub-folder and moving a plugin in and out of the plugins folder should be equivalent of installing / uninstalling.

This could be done simply with:

res.locals.config = req.site.config;

Currently the method fallback doesn't work.

When the controller is reverted to the "main" controller, the name we have set as the controller needs to become "main" and the method exec needs to test against that name.

For example, for the URL:

/logout 

if there is no controller named "logout" the main controller should lookup for a method named "logout".

Currently the method always executed is "index"

Models contain normalID and filterData as helpers to filter data but they only process one item at a time.

It would be good if the model could process a whole collection of data (in an array)

Authentication is a big part of any serious service but it shouldn't be assumed that isAuthenticated will always be available in the request object

If not available Brisk currently this returns an exception error.

This error is especially crucial as render is trying to call a method that may not be available.

The main render method can be tweaked to remove whitespace in production mode.

Although highly unlikely it would be better if brisk could operate with no express configuration.

Just makes for one less error report when start building an a new app...

With the advent of Node.js v0.10 and the upcoming 0.12 (->1.0) Brisk needs to be tested for and support fully the latest versions.

On a side note support for older version (<0.8) should be deprecated.

The res.render method supports an options object, to define the layout among other things.

The render method of the main controller does not take into account these settings.

Constant look up on the filesystem may be wearing down the hardware and slow down the response.

As the (app) filesystem doesn't change after the launch it would be best to create a copy of the combined directory structure - which includes all controllers/views from brisk and its modules.

That way many lookups could be done against the object saved in memory (instead of the filesystem).

This information could be saved under req.site.dir

All requests need to be automatocally mapped to controllers based on the Ul of the request.

The convention can be analyzed further in the documentation after it's concluded.

This will be a very common / generic class with getters setters etc.

Console logs are fine for informing the developer but they should be silenced in production.

Practically that can be addressed by reading the NODE_ENV and setting a DEV variable...

To improve the security of the server, certain methods that are not meant to be accessible from the client as direct requests should be captured and ended.

Authentication for a website is a common requirement and steps can be made to make it easier to deal with through automation.

ensureAuthenticated is part of the main controller but it can be joined by an isAuthenticated method that will return a boolean.

In addition the express helper may host a middleware that will broadcast session information to the views.

All style sheets need to be concatinated to one and minified.

In conjunction with caching this will not be required on every request in production.

The public folder was assembled pretty quickly when the library was first created and hasn't had much use since. And update here is overdue.

loadConfig currently works as an internal method but there are cases where it might be called from controllers/helpers.

It also needs to become more generic and merge any "default" & "local" versions of the config.