balderdashy / sails Goto Github PK

Models should look less Sequelize-specific and more like Grails

Allow for immediate, credential-less, setup-less development using the Sails platform by bundling an installation of SQLite.

This could be as simple as a few lines of code in router.js, or we could go with a formal express template engine.

This is a lot of work, and more or less a rewrite of a lot of the socket.io handling stuff.

really helpful in rails. Think this would only make sails better.

... but still work if only one part of the lot is replaced. Right now, replacing layout.ejs does nothing because the metacontroller isn't checking for the newest layout

Needs to support iframe and ajax style uploads

Right now, wildcard routes only work if the url is unmapped

Automatically determine all statically defined roles from access control policy rules and populate the database accordingly

Update to automatically generate the new, correct authentication policy that sends a 403 if this is an ajax or socket request, and redirects to the login page otherwise

Understand Mast's declarative conventions for defining:

• sort fields & order
• search fields & filter
• limit & offset (for pagination)

JugglingDB should probably be the default, because of its in-memory database support (so you don't have to have mySQL installed just to get started)

As for notation, we should enforce an agnostic standard. My biggest beef with sequelize is the promise interface notation for success and error callbacks. This doesn't fit in well with the cb(error,result)-style notation used by our other dependencies (namely async) or our unit testing framework of choice (vows).

I also rather like using the standard Sails CRUD synonyms.

Proposed notation:

Model.create(attributes,callback) (or generate, or add, or new)
Model.find(options,callback) (or read, or view, or show, or detail, or findAll)
Model.update(id,newAttrs,callback) (or edit, or set, or modify, or update)
Model.destroy(id,callback) (or delete, or remove)

`````` Model.findAndUpdate(options,newAttrs,callback) Model.findAndDelete(options,callback)```
```Model.findOrCreate(options,attrsToMatchAgainst,callback)```

Because of the added websocket support, ejs is required as of now. However other users of the framework may very well like Jade or Haml.

Allows for client-side manipulation of shared data source. Pull code that would normally go into controllers into a model which loosely corresponds w/ client-side.

Definitely can't be the only option (doesn't fit in to the philosophy of SOA) , but the idea is to simplify server-side code which is client-specific. The standard REST API can still exist.

i.e. FileSystemNode is a virtual model
FileSystemNode.create:
creates a Directory or File, assigns permissions based on the session, and (if passed a binary) uploads a file to OpenStack. Also cascades permission from parent File or Directory to children.

Bootstrap HTTP and WS clients and provide easy access to them from /test modules.

Then, automatically generate integration test stubs for each controller/action.
In the future, these could be randomly generated if pre and postconditions are defined with Anchor.

http://faye.jcoglan.com/architecture.html

For instance. a job might run every few minutes which does the following:

• If < 100 instances exist:
  • subscribe sockets to the static class room
  • migrate existing sockets to use the static class room if they're not already
• otherwise,
  • subscribe sockets to paginated rooms which broadcast events for up to 100 instances
  • migrate existing sockets to use the appropriate paginated room

This could go further in multi-tiered environments to manage rooms based on # of connected sockets (but we should probably use an existing solution for that piece, like Guillermo's new solution )

In addition to assigning custom middleware to a particular controller and action at build time, the application should be able to modify permissions for specific Accounts to access specific instances of a model using a specific controller and action during runtime.

At build time, specify various role strings that can be attached to Accounts. These role strings will be converted into Role objects at runtime and attached to accounts via a join table.

Look at permissions, do proper database operation, then do a res.json response and broadcast to the model's room

It would be nice to able to do things like:

...
upload: function (req,res) {
  _.each(req.files,function(file) {
    File.create({
      filename: file.filename,
      extension: file.extension,
      mime: file.mime
    }).success(function(fileModel) {
      file.save({
        path: '/public/files',
        name: file.id + "." + file.extension
      });
    });
  });
  res.json({success:true});
}
...

Instead of having to use __dirpath and then navigate back upwards to the appropriate place. Might also make sense to create the specified directory if it doesn't exist.

Route websocket requests from socket.io just like http requests (minus the verb).

Extend ExpressJS with an isWebSocketRequest(), much like their existing is XMLHttpRequest() method.
http://expressjs.com/guide.html#req.isxmlhttprequest

Starting this tonight on a separate branch, express3.

This will get us up to date with the latest Express has to offer, including the much better bodyParser.

If res.render, res.redirect, res.json, or some other response method has not already been called, automatically render the best guess view for a controller at the end of the method.

Instead of:

sample: function () {
this.res.render('pages/sample',{
title: 'the page'
});
}

sample: function () {
this.view.title = 'the page'
}

Replace ExpressJS-specific req,res,next arguments with a Sails proprietary context to execute controller actions from.

Instead of:

exports.sample = function (req,res,next) {
req.render({
title: 'The page'
});
}

sample: function () {
this.view.title = 'the page'
}