I'm not, because as was mentioned elsewhere on the thread, you almost always
need to go back to some (or other - int) mechanism because in reality,
permissions typically end up being:
User has a Role (or multiple roles)
Those Role objects have Permission objects
User can also have Permission objects that are outside of his normal role.
For instance, I'm a regional manager, so I have that role and maybe others
that go with it, but the national manager gives me the extra permission to
view sales reports for while he's gone or because I'm assisting him. I
don't get everything in his role - seeing salaries for instance, but I have
certain permissions in addition to my role-inherited permissions.
Anyway, the idea I gave below is certainly an intriguing one to me, and I
think it's interesting, but there are holes in it. So - nino - I guess it's
your potato :)
On Fri, Dec 5, 2008 at 7:21 AM, Nino Saturnino Martinez Vazquez Wael <
[EMAIL PROTECTED]> wrote:
> Yeah this is a much nicer way.. So whos gonna implement it? :)
>
> regards Nino
>
> Jeremy Thomerson wrote:
>
>> If you were going to do this, it would be much better (IMHO) to use
>> interfaces... This gives you interesting possibilities:
>>
>> (Disclaimer - the following is not an original thought - Igor mentioned
>> this
>> last week - give credit where it's due)
>>
>> interface User
>>
>> interface Admin extends User
>>
>> interface ProjectManager extends Admin
>>
>> interface SalesManager extends Admin
>>
>> HERE'S THE KICKER:
>>
>> interface TheBigBoss extends ProjectManager, SalesManager
>>
>> Since those are just marker interfaces, I guess each of those would need
>> something like a single public static final implementation like:
>> public static final TheBigBoss INSTANCE = new TheBigBoss() {};
>>
>> Something like that - anyway, MULTIPLE INHERITANCE FOR ROLES RULES!
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Jeremy Thomerson
http://www.wickettraining.com
