the problem is that the enum would have to live *inside* the wicketstuffauth code. so wicketstuffauth would be the library that would need to define the enum - and it doesnt know about your application specific roles. at least this was the issue when it was first being designed. i havent really looked at it since than.
-igor On Thu, Nov 27, 2008 at 11:12 AM, Casper Bang <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
