Hi,
I'm thinking right now about some role and permission stuff for my webapp. But I'm asking myself what will be a good approach for this.
At first I created a lot of classes like AdminRole, MemberRole, CreatePermission, ModifyPermission etc. I used the class objects for this. These only carry some state like index, label. The role objects also carry a set of permissions.
But at the moment I doubt this is a good approach. I'll end up with a lot of classes that have only two mehods. And second (I dislike most) is to use class side initialization for populating the objects at first.
The good thing about it is that I'm able to use something like
anAction requires: Modifypermission and aUser hasPrivilege: AdminRole
What would be a usual approach to solve something like this??
thanks in advance,
Norbert
Nothing wrong with a lot of classes with only a few polymorphic messages. Many of the design patterns leverage this.
I would get the behavior over to the instances. So your examples would look like:
anAction requires: Modifypermission new
and
aUser hasPrivilege: AdminRole new
If you are worried about creating too many Role or Permission objects and then simply throwing them away, you can share them. Note that this qualifies as an optimization. You should really only optimize after you've proven that you need to optimize. The Singleton design pattern is the best known sharable but you could also use a pool dictionary or some other well known object.
I avoid class side behavior like the plague. Instances for objects, classes for making objects. Exceptions rare!
On 6/26/07, Norbert Hartl norbert@hartl.name wrote:
Hi,
I'm thinking right now about some role and permission stuff for my webapp. But I'm asking myself what will be a good approach for this.
At first I created a lot of classes like AdminRole, MemberRole, CreatePermission, ModifyPermission etc. I used the class objects for this. These only carry some state like index, label. The role objects also carry a set of permissions.
But at the moment I doubt this is a good approach. I'll end up with a lot of classes that have only two mehods. And second (I dislike most) is to use class side initialization for populating the objects at first.
The good thing about it is that I'm able to use something like
anAction requires: Modifypermission and aUser hasPrivilege: AdminRole
What would be a usual approach to solve something like this??
thanks in advance,
Norbert
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
Norbert Hartl wrote:
At first I created a lot of classes like AdminRole, MemberRole, CreatePermission, ModifyPermission etc. I used the class objects for this. These only carry some state like index, label. The role objects also carry a set of permissions.
I'm a big fan of instances :-)
Have one Permission class, one for Role etc.
Then you can have instance creation methods (maybe via a cache)
Permission modify, Role admin
Internally you could actually use (symbol) names
Permission>>modify
^Permission new name: #modify
or
self cache at: #modify ifAbsentPut: [...]
This would make it easier to extend the role and permission model later
Permission>>named: permissionID
anAction requires: Modifypermission
anAction requires: Permission modify
Cheers
Michael
On Tue, 2007-06-26 at 15:45 +0200, Michael Rueger wrote:
Norbert Hartl wrote:
At first I created a lot of classes like AdminRole, MemberRole, CreatePermission, ModifyPermission etc. I used the class objects for this. These only carry some state like index, label. The role objects also carry a set of permissions.
I'm a big fan of instances :-)
me too (in general) :)
Have one Permission class, one for Role etc.
Then you can have instance creation methods (maybe via a cache)
Permission modify, Role admin
Yes, this looks very good. So it seems to be all I wanted to have. No class use, shared instances and readable usage. Thanks very much.
Internally you could actually use (symbol) names
Permission>>modify
^Permission new name: #modify
or
self cache at: #modify ifAbsentPut: [...]
I like this one. Without any reason to mention. I think I'll like to use == ;)
This would make it easier to extend the role and permission model later
Permission>>named: permissionID
anAction requires: Modifypermission
anAction requires: Permission modify
perfect. thanks again,
Norbert
On Tue, 2007-06-26 at 15:46 +0200, Michael Rueger wrote:
Norbert Hartl wrote:
Hi,
I'm thinking right now about some role and permission stuff for my webapp. But I'm asking myself what will be a good approach for this.
P.S. have you looked at the SmallWiki permission and role implementation? _______________________________________________
Nope, but I will. I had a look at pier but this is very different I guess.
thanks,
Norbert
beginners@lists.squeakfoundation.org