Skip to content

Recent features and Design ideas

kristianmandrup edited this page Nov 23, 2011 · 4 revisions

This page will contain various ideas and design considerations for CanTango. Feel free to comment on this page and provide your own ideas and suggestions :)

Recent feature additions

CanTango now has support for executing the Ability in both cache and no_cache modes and merging the results. You can configure which mode(s) to enable and even define which engines should participate in which of these modes for maximum control.

A new Engine :user_ac with a Permission model linked to each individual user (or account) has been implemented.

The new, more fine grained and flexible Caching strategy has also recently been implemented :)

CanTango editor

@stanislaw has recently finished his Rails 3 engine Cantango editor that can be mounted on any app in order to edit the static permits stored in the permission store.

We also need to implement an engine (editor) for the new user_ac permissions.

New engine structure

The old Permission engine should be renamed to Permit store engine. These 3 engines combines should handle most real life scenarios that can be imagined and act as good templates to be used in case someone needs to roll their own engine!

In order to register an engine, it should be sufficient just to subclass the CanTango::Engine class and implement the Engine API. Registration should be done via the self.inherited(clazz) hook of CanTango::Engine.

Coming features (November 2011)

The following list some of the planned features. Please help out!

Registration of custom Permits

CanTango should make it easy to define and register custom Permit types. These permits should then also be allowed to be defined as permissions in a permission store.

All Permits should be registered simply via the self.inherited(clazz) hook of the CanTango::Permit class or explicitly via a tango_permit macro, in case the Permit is subclassing an existing Permit subclass.

A Permit should have a #build method that takes care of building a Permit ready for use for the given ability. A base Builder class is available which is easy to extend. The Permit Finder classes should be made obsolete!

A Permit can have a #hash_key method, used for invalidating its own private Cache. The method #valid_for? subject should be used to determine if this Permit should be executed for that particular subject.