You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Casper Bang <ca...@jbr.dk> on 2008/11/27 19:33:19 UTC
Why does org.apache.wicket.authorization revolve around string tokens?
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why does org.apache.wicket.authorization revolve around string
tokens?
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
A really good question. I've heard that it's because that it is a demo
of how you could implement it.
I share the exact same thoughts as you do about this.
Casper Bang 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why does org.apache.wicket.authorization revolve around string tokens?
Posted by Igor Vaynberg <ig...@gmail.com>.
or even something cooler with interfaces and multiple inheritance...
interface admin extends user,publisher {}
-igor
On Thu, Nov 27, 2008 at 7:57 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> this is where the classes variation comes in. class AdminRole extends
> UserRole - done
>
> -igor
>
> On Thu, Nov 27, 2008 at 6:56 PM, Casper Bang <ca...@jbr.dk> wrote:
>> Yeah. First I actually didn't understand why until Igor pointed it out. I'm
>> no longer using wicket-auth-roles, if one can live with the roles being
>> defined along side the authorization code it works quite nicely (and with
>> somewhat cleaner code). I ran into another issue however, trying to model
>> how an ADMIN transitively is also a USER. Sadly the Sun compiler does not
>> allow Enum forward referencing to itself, only the Eclipse compiler does.
>>
>> /Casper
>>
>>
>> Ned Collyer wrote:
>>>
>>> Interestingly we used a similar approach with using classes as pseudo
>>> enums.
>>>
>>> Not being able to extend enums is a bit suckfull.
>>>
>>>
>>> igor.vaynberg wrote:
>>>
>>>>
>>>> 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
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why does org.apache.wicket.authorization revolve around string
tokens?
Posted by Casper Bang <ca...@jbr.dk>.
Yeah I suppose that's the only viable alternative then, but it plays a
little less nice with a JPA backed role table and also appears to be a
step back to rely on inheritance rather than composition. Oh well, can't
have it all - hopefully an extendable and more lenient Enum makes it
into Java at some point to allow that kind of static modeling - it's in
the Kijaro sandbox after all
(http://freddy33.blogspot.com/search/label/abstract%20enum).
/Casper
Igor Vaynberg wrote:
> this is where the classes variation comes in. class AdminRole extends
> UserRole - done
>
> -igor
>
> On Thu, Nov 27, 2008 at 6:56 PM, Casper Bang <ca...@jbr.dk> wrote:
>
>> Yeah. First I actually didn't understand why until Igor pointed it out. I'm
>> no longer using wicket-auth-roles, if one can live with the roles being
>> defined along side the authorization code it works quite nicely (and with
>> somewhat cleaner code). I ran into another issue however, trying to model
>> how an ADMIN transitively is also a USER. Sadly the Sun compiler does not
>> allow Enum forward referencing to itself, only the Eclipse compiler does.
>>
>> /Casper
>>
>>
>> Ned Collyer wrote:
>>
>>> Interestingly we used a similar approach with using classes as pseudo
>>> enums.
>>>
>>> Not being able to extend enums is a bit suckfull.
>>>
>>>
>>> igor.vaynberg wrote:
>>>
>>>
>>>> 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
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why does org.apache.wicket.authorization revolve around string tokens?
Posted by Igor Vaynberg <ig...@gmail.com>.
this is where the classes variation comes in. class AdminRole extends
UserRole - done
-igor
On Thu, Nov 27, 2008 at 6:56 PM, Casper Bang <ca...@jbr.dk> wrote:
> Yeah. First I actually didn't understand why until Igor pointed it out. I'm
> no longer using wicket-auth-roles, if one can live with the roles being
> defined along side the authorization code it works quite nicely (and with
> somewhat cleaner code). I ran into another issue however, trying to model
> how an ADMIN transitively is also a USER. Sadly the Sun compiler does not
> allow Enum forward referencing to itself, only the Eclipse compiler does.
>
> /Casper
>
>
> Ned Collyer wrote:
>>
>> Interestingly we used a similar approach with using classes as pseudo
>> enums.
>>
>> Not being able to extend enums is a bit suckfull.
>>
>>
>> igor.vaynberg wrote:
>>
>>>
>>> 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
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why does org.apache.wicket.authorization revolve around string
tokens?
Posted by Casper Bang <ca...@jbr.dk>.
Yeah. First I actually didn't understand why until Igor pointed it out.
I'm no longer using wicket-auth-roles, if one can live with the roles
being defined along side the authorization code it works quite nicely
(and with somewhat cleaner code). I ran into another issue however,
trying to model how an ADMIN transitively is also a USER. Sadly the Sun
compiler does not allow Enum forward referencing to itself, only the
Eclipse compiler does.
/Casper
Ned Collyer wrote:
> Interestingly we used a similar approach with using classes as pseudo enums.
>
> Not being able to extend enums is a bit suckfull.
>
>
> igor.vaynberg wrote:
>
>> 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
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why does org.apache.wicket.authorization revolve around string
tokens?
Posted by Ned Collyer <ne...@gmail.com>.
Interestingly we used a similar approach with using classes as pseudo enums.
Not being able to extend enums is a bit suckfull.
igor.vaynberg wrote:
>
> 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
>
--
View this message in context: http://www.nabble.com/Why-does-org.apache.wicket.authorization-revolve-around-string-tokens--tp20723820p20728137.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why does org.apache.wicket.authorization revolve around string tokens?
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ca...@jbr.dk> 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 <ca...@jbr.dk> 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: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why does org.apache.wicket.authorization revolve around string
tokens?
Posted by Casper Bang <ca...@jbr.dk>.
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 <ca...@jbr.dk> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why does org.apache.wicket.authorization revolve around string tokens?
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <ca...@jbr.dk> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org