Bruno Borges escreveu:
Note that this is really type-safe, and these classes will never be
instantiated.
I don't think this has any value in this context. Where will the roles x
user will be? On the database, certainly...
So why declare dummy classes for them? If yon don't want to repeat
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
Yes Adriano, that's what I said on my last reply. :-)
So, the only way, for now, to have type-safety is using that
Class-thing. I don't vote for this though. A simple class with String
constants does de job quite well. :-D
Cheers,
Bruno
Adriano dos Santos Fernandes wrote:
Bruno Borges
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
I am using this @AuthorizeInstantiation (wicket authetication annotation)
in my pages , the code for this annotation
@Retention(RetentionPolicy.RUNTIME)
@Target( { ElementType.PACKAGE, ElementType.TYPE })
@Documented
@Inherited
public @interface AuthorizeInstantiation {
/**
You simply can't do that because the nature of Annotations.
Even if AuthorizeInstantiation's values were of type Object[] you
wouldn't be able to do that with Enums.
You will have to use Strings.
Although there's some hack you can make using Java 6 to accomplish what
you want. If you are
I've found a way to implement a type-safe check for this. Here it goes:
import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Inherited;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import
I don't know about this. It would work (and break existing code, unless you
use something other than value for the annotation). I don't know if I would
want to have to create a new class for each role in my project. Yes, it
would be a small price to pay, but it just feels wrong.
On Thu, Dec 4,
Well... You don't have to create one java file for each class. You can
put all of them on the same file, like:
public final class MyAppRoles {
private MyAppRoles() {}
public static final class Admin extends Role {
private Admin() {}
}
public static final class User extends
What do you mean by Enums as Objects?
On Thu, Dec 4, 2008 at 11:11 PM, Bruno Borges [EMAIL PROTECTED]wrote:
Well... You don't have to create one java file for each class. You can put
all of them on the same file, like:
public final class MyAppRoles {
private MyAppRoles() {}
public
Well... you can't do this:
@Foo(values={MyEnum.FOO, MyEnum.BAR});
@interface Foo {
Object[] values() default {};
}
James Carman wrote:
What do you mean by Enums as Objects?
On Thu, Dec 4, 2008 at 11:11 PM, Bruno Borges [EMAIL PROTECTED]wrote:
Well... You don't have to create one java
But, you can declare the values property to be of type MyEnum[]. Is what
we're really looking for here the ability to extend an enum (if that even
makes sense)? I've often thought it would be nice if I could add stuff to
an enum from the outside. But, that kind of goes against the idea of an
It is not possible to extend enums nor annotations. And as the question
here is about the use of @AuthorizeInstantiation, there's no way to
declare MyEnum[], of course :-)
So, the only way, for now, to have type-safety is using that
Class-thing. I don't vote for this though. A simple class
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
14 matches
Mail list logo
