Yeah, I asked about this last week or so when running into the same
problem. I now also do it the class way, and although that does feel
better than using strings, in my opinion it still isn't type safe. It
gives no syntax lookup and people are free to write Object.class which
will compile just fine. Marker interfaces are better for composability,
however if you are going to make a truly role based system, chances are
you'll want a backing roles table and that can get tricky with inheritance.
I'll probably go back to the enum way, which works fine enough IF you
are ok with having the role definitions mixed with the authorization
code. It's a small price to pay, I rewrote some of the annotation stuff
to make it easier to use anyway (AccessableTo, EnabledTo and VisibleTo )
which now just takes an array of values which means clean code like this:
@VisibleTo({Administrator.class, User.class})
...rather than:
|@AuthorizeAction(action = Action.RENDER, roles = {Roles.ADMIN,
Roles.USER})|
Anyway, just my 2 cents on the topic.
/Casper
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]
