wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven Meier <s...@meiers.net>
Subject Re: Generic in-app bookmarking mechanism
Date Tue, 24 Sep 2013 11:36:59 GMT
 >> 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 <sven@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-unsubscribe@wicket.apache.org>
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<users-unsubscribe@wicket.apache.org>
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Mime
View raw message