No but an application is designed for a given number of roles, what
would you possibly accomplish by adding new roles without editing source
code and account for the new behavior you are putting in?
Seems to me the application would always need to be revised to work with
these new roles (say modify web-pages annotations) no-matter if you do
it with strings or enums. Anyway, perhaps I am being anal about it, but
it doesn't strike me as fitting the Wicket philosophy I've picked up in
other corners of the API. I was hoping for consensus that it would be
beneficial to make it type-safe since it is part of a very visible and
convenient API, but I'll try to write my own Enum version instead then.
Thanks,
Casper
Igor Vaynberg wrote:
because you cannot add custom enum values without editing source code.
there is a version implemented using classes in wicketstuff somewhere.
-igor
On Thu, Nov 27, 2008 at 10:33 AM, Casper Bang <[EMAIL PROTECTED]> wrote:
What attracts me to Wicket is how it tries to do as much in type-safe Java
code as possible, so I was a bit surprised with the finding that the
org.apache.wicket.authorization stuff is not based upon Enum and EnumSet but
rather type-unsafe string tokens.
Are there good reasons for this design that outweighs the benefits of having
code completion and static verification? (Extendability, decoupling,
transitive relationships, runs on Java 1.4 etc.)
Also, before I delve deeper into it, would it be a trivial matter to write a
type safe version?
Thanks in advance,
Casper
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
