Hi,
I'm currently investigating a bug in our application that is most likely
caused by the very "brute-force" way I implemented a generic in-app
bookmarking feature.
The basic requirement is something along the lines of "Users should be
able to create an (internal) bookmark for virtually any Wicket page that
can subsequently be shared with other users". Keep in mind that
everything is happening inside our application, so no browser
bookmarks/URLs involved.
I implemented this by serializing the current WebPage instance using
XStream and storing it as a BLOB in the database. Users then basically
share the DB primary key of this BLOB and whenever a user navigates to
such a bookmark, I just de-serialize the WebPage instance and use "throw
new RestartResponseException( deserializedPage )" to render it.
To create a new bookmark, the user clicks on an AJAX link that does
final AjaxLink<String> link = new AjaxLink<String>("link") {
@Override
public void onClick(AjaxRequestTarget target)
{
final long bookmarkId = serializeCurrentPage();
...
}
};
It seems that my approach is quite fragile for certain constructs, for
example when the page involves components that register AJAX behaviors /
resource listeners in general. Since Wicket itself successfully uses
serialization for page versioning, I suspect the issues I'm having are
caused by serializing the page instance while the request processing is
still in-transit.
Is there some way to safely hook into the processing of the current HTTP
request and get hold of a serialized WebPage instance for my use-case ?
Thanks in advance,
Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
