Michiel Meeuwissen wrote: > Because it does not belong to the interface. I'd rather see that the UserContext of > security > implements the bridge's User interface. BasicCLoud can then simply return the real > security object > in its implementation of getUser(). If really necessary, you can cast it then to you > specific > implementation's class.
I quickly tried it. - BasicUser can be dropped then. - The problem is that bridge.User#getRank returns a String, and security.UserContext#getRank returns a 'Rank' object. This last issue is annoying anyway, because when using bridge, cloud.getUser().getRank() was quite useless, because you often are not intested in the string itself but want to know if it is higher/lower then a certain other rank. So, I often found myself calling security.Rank.getRank(String) then.... The best sollution would be to make getUser().getRank() not return a String anymore but a Rank object. Perhaps a Rank interface could be added to the bridge, and the Rank object of security should implement it then. Sadly, this would break all hacks currently using cloud.getUser().getRank(), but actually I think they would become considerable simpler (if really used as String, it would probably remain working, because the toString() of Rank of course does what you wanted then). - The other problem is that User interface of bridge has methods currently not implemented by UserContext of security. Those 'isValid' and 'getAuthenticationType'. So, I have up at this point... I don't really see the point of two distinct User implementations, where one will wrap and return the other, so I would not mind changing all this, but it will give compatibility issues. Michiel -- Michiel Meeuwissen mihxil' Mediacentrum 140 H'sum [] () +31 (0)35 6772979 nl_NL eo_XX en_US
