So you agree that serializing a page instance while the request is still
being processed (my current approach) is likely the cause of the
glitches I'm seeing with some (put not all) of the pages , right ?
>> hook into DefaultPageStore#**storePageData()
> custom IPageStore will be needed
That's what I meant.
Sven
On 09/24/2013 01:15 PM, Martin Grigorov wrote:
On Tue, Sep 24, 2013 at 12:51 PM, Sven Meier <s...@meiers.net> wrote:
You could just mark the page to be "bookmarked" (e.g. via MetaData
on the
RequestCycle) and hook into DefaultPageStore#**storePageData() to store
the page alongside in the database.
I don't think this will help much.
The page can be requested from the DB much later when the disk store
has no
info about this page or even the http session that the page belongs to.
Any interaction with the rendered page will lead to PageExpiredException
because the following request will search in the disk store, not in
the DB.
I think a custom IPageStore will be needed ..
Sven
On 09/24/2013 12:06 PM, Tobias Gierke wrote:
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-unsubscribe@wicket.**apache.org<users-unsubscr...@wicket.apache.org>
For additional commands, e-mail: users-h...@wicket.apache.org
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
users-unsubscribe@wicket.**apache.org<users-unsubscr...@wicket.apache.org>
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.or
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
