remove Form Persistence from trunk (1.5)

[Juergen Donnerstag]

As suggested in wicket-2213, I'd like to remove all source code
related to FormComponent persistence from trunk and only leave a
CookieHelper class in a utils package. Any objections?

Juergen

[Martijn Dashorst]

Can we make a good note in the release notes for this? Maybe even
start a migration guide?

Martijn

On Sun, Aug 30, 2009 at 12:07 PM, Juergen
Donnerstag<juergen.donnerstag@...> wrote:
> As suggested in wicket-2213, I'd like to remove all source code
> related to FormComponent persistence from trunk and only leave a
> CookieHelper class in a utils package. Any objections?
>
> Juergen
>



--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0

[Juergen Donnerstag]

"rememberMe" (logon) requires someone to store, load and remove the
username and password. Usually that is via a Cookie or two but
everybody preferrs a slightly different approach. Store and load might
be implemented in SignInPanel, SignOut however is via
Session.invalidate() and it would be bad pratice to reference the
signInPanel instance within the session. Whilst implementing all three
(load, save, remove) in SignPanel is awkward, same is true for
implementing them all in a Session subclass. So I decided to implement
a IAuthenticationStrategy, very similar to IAuthorizationStrategy and
provide a default implementation available via ISecuritySettings. Load
and save can easily make use of it, only remove still requires to
subclass WebSession. Calling MySession.signIn() and
MySession.isSignedIn() from within SignInPanel is yet awkward as well.
All that though signIn and isSignedIn is required by 99.5% of all
applications. So I implemented it in WebSession. signIn() itself calls
WebSession.authenticate() which is the only method to be implemented
by your applications. Usually I would make authenticate abstract but
that would require really every application to implement its own
MySession. Not sure this is a good idea, which is why my current
implement throws an exception to remind the developer to subclass and
replace it. Another option would be to delegate to an abstract
Application.authenticate(). What do you think? What would be your
preferred option?

Juergen