In the patch for Wicket 7.x in WICKET-5823 you added a new method to the
API, instead of replacing the old one. Having several #save() methods
didn't look OK to me.
sorry for that, I was afraid to break all existing code (wasn't aware
varargs param will not be API break)
#save(String,
Hi Maxim,
On Tue, Feb 24, 2015 at 6:09 PM, Maxim Solodovnik solomax...@gmail.com
wrote:
Hello All,
recently I have proposed the patch to reduce copy/paste while implementing
custom IAuthenticationStrategy.
https://issues.apache.org/jira/browse/WICKET-5823
Actually this interface have 2
Hello All,
recently I have proposed the patch to reduce copy/paste while implementing
custom IAuthenticationStrategy.
Actually this interface have 2 methods which are not correlate to each other
String[] load();
void save(final String username, final String password);
in fact this is getter and
I thought to take a HashMap, because in the save method you could read the keys
- but if the load method also returns String[] and the order of credentials is
well known varags might be ok.
kind regards
Tobias
Am 25.02.2015 um 05:14 schrieb Maxim Solodovnik solomax...@gmail.com:
Actually
Hi Maxim,
I think this isn't a good idea because the order in which the arguments
are added to the save method is important - and what if you want to let
one argument away? Then the rest would not used for their purpose.
Instead I would add another method save method that takes a Map with
Actually load() method return String[] (actually with arbitrary number of
elements and arbitrary order) so I see no issue here, You read parameters
in the same order as you wright them.
MapString,String will make things worst IMHO since the order will not be
the same
On Wed, Feb 25, 2015 at 4:16
