sam2x
commented
8 years ago Good initiative Moritz! I'll help you as much as i can. From my nohm experience, here my feebacks :
- As i said a lot, i'm using zset for relation, it is very useful only for one-to-many, many-to-many relations (eg: in my friends list feature, i use it to have timestamp of relation), could be cool to have it natively.
- On my project, I had to build a small layer on top of nohm to handle "safely" nohm*CRUD operations. This layer allow me:
- To bring Access Control Fields on CRU operation (which imho is missing to nohm)
- To logs errors (model/entity.not found, validations errors), i had to build an ugly 'hack' to have personal validator error message per model. This need to be reworked imho
Here my recommandations about the evolution of Nohm, some features that may bring this framework to the next level :
- Better/Easier errors handling (validators, link, and unfound model error.)
-
Access Control List with granularity in the model definition, examples :
- A model named "User" without role can only read field X, can't create/update/delete;
- A model named "User" with role ADMIN can CRUD model instance;
- A model named "User" with role VENDOR can create field X,Y,Z, Read field W,X,Y,Z, Update X,Y,Z, but cant delete the model;
- A custom rule to be defined in the model definition, and let an argument to be passed to load/factory/save which will be evaluated by this custom rule.
-
Examples 1:
rules:[ { desc:'Rule 1 - User admin can read X,Y,Z, write Z, etc. ' model: 'User', roles: 'ADMIN' // that will check that User has a relation named ADMIN with the current instance model) link_name: 'role' // optional, default is 'role' permission:'CRUD', // or with more granularity, will be used if specified (* => all, '-' except) //permission:{read:['*', '-X'], write:['Z'], etc.} }, { desc:'Rule 2 - Custom rules that will allow delegate some task to specific user', fn: custom_check, } ] [.. somewhere in the model definition ...] /* instance: instance of the current model (loaded or created) context: define the context of the operation; read(model was loaded), create(save was called), update(save was called), a delete(remove was called), maybe useful for complexe check or loggings obj : argument passed to load/factory/save depending the action */ custom_check(instance, context, obj, next){ if (instance.p('delegate_id') == obj.id next({read:['X','Y','Z'], save:['Y','Z'], update:['X'], delete:true} else next(false) }
-
Pub/Sub feature integrated to the model definition (could be scoped to property or model, note: create/delete only scoped to model) :
{ properties: { [...] isOnline: { type:'boolean', // parameter notification subscribe:{ read:null, update:notifyFriendNetworkStatus, } } }; // whole model notification subscribe:{ create:[callback1, callback2], delete:callback1, read:null, update:null, } } -
Having an Instance of the entity as a parameter to the validators (adding a priority field for the chains validations flow?). Related to https://github.com/maritz/nohm/issues/94
{ properties: { [...] sub_category: { type:'string', validations:[ verifyCategory = function(entry, value, options, next){ console.log('instance being processed:', entry); next(myconf.list_cat[entry.p('category')].indexOf(value) >= 0) } ], priority:0, } category:{ type:'string', priority:1, } } -
Having Geodata feature in the model definition:
- a new field type 'geo', which will contains plain geographical coordinate,
- a new field definition (as like type/validation/defaultValue, etc.) named 'geotable'. Its string value which will be used as redis key to create the geo table (http://redis.io/commands#geo). When this plain hash field value will be created/updated, call geoadd to update the geo table defined.
- add inherent method georadius/geoPos etc. to the model, eg:
// will list all model ids within 10km of lat/lng radius Model.georadius('field_name', {lat:lat, lng:lng}, '10km') // algo : read geotable value of field_name, call 'georadius' command with args - Transaction safe ? https://github.com/maritz/nohm/issues/64
- Backup rules via nohm and per models ?
- Having your admin interface being restful compliant ? (have you checked this https://github.com/marmelab/ng-admin ? i use it as client-side interface for my models, it's pretty awesome, and well designed, it uses angular)
- Documentation : moving to the excellent docco (http://jashkenas.github.io/docco/) for better clarity.
- Open questions : redis clustering interests via nohm ? interests of lua scripts(https://github.com/maritz/nohm/issues/93) ? Benchmark/performance graphs (https://github.com/maritz/nohm/issues/79) ? TTL feature (https://github.com/maritz/nohm/issues/97) ?
Hope this remarks are relevants to you.
Regards,
Edit: ps: is this possible to have rights to edit(labels)/close others issues?
maritz
katopz
MegaGM
hfwittmann
fatfatson
At long last I am planning to work on a v2.0.0. My current goal is to have this done this fall.
Must haves:
Should haves:
Research and categorize:
Discussion points:
While this is going on I also want to have the admin interface in a state that is at least read-only complete for v2.0.0.
Discussion & feedback & ideas are welcome.
This was previously labeled as v1.0.0 but has now been changed to v2.0.0 to keep compatibility for dependents.