Re: Generic in-app bookmarking mechanism
>So you agree that serializing a page instance while the request is still being processed ... is probably a bad idea, yes. Try it out the other way :P. Sven On 09/24/2013 01:49 PM, Tobias Gierke wrote: 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 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 link = new AjaxLink("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 For additional commands, e-mail: users-h...@wicket.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Generic in-app bookmarking mechanism
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 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 link = new AjaxLink("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 For additional commands, e-mail: users-h...@wicket.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@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
Re: Generic in-app bookmarking mechanism
>> 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 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 link = new AjaxLink("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 For additional commands, e-mail: users-h...@wicket.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@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.org
Re: Generic in-app bookmarking mechanism
On Tue, Sep 24, 2013 at 12:51 PM, Sven Meier 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 link = new AjaxLink("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 >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@wicket.**apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Generic in-app bookmarking mechanism
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. 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 link = new AjaxLink("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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Generic in-app bookmarking mechanism
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 link = new AjaxLink("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