Re: Demo Page with User Related Data
Hi,
Sorry for the late answer: work overflow...
I did try the solution you provided which works with the following change:
public class NewsModel extends LoadableDetachableModel> {
private static final MetaDataKey> NEWS_CACHE_KEY = new
MetaDataKey<>() {
};
public NewsModel() {
}
@Override
public List load() {
final RequestCycle requestCycle = RequestCycle.get();
List news = null;
news = requestCycle.getMetaData( NEWS_CACHE_KEY );
if( news == null ){
news = List.of( 12.0, 25.5 );
requestCycle.setMetaData( NEWS_CACHE_KEY, news );
}
return news;
}
}
I had to remove the if condition `if (requestCycle != null)`, because it
seems always true.
Thanks again for your help.
--
Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Demo Page with User Related Data
On Wed, Sep 26, 2018 at 11:37 AM Korbinian Bachl < korbinian.ba...@whiskyworld.de> wrote: > Hi, > > in case of a regular session you can use a HttpSessionListener and use the > public void sessionDestroyed(HttpSessionEvent event), similar to that one > here: > > https://stackoverflow.com/questions/7756054/how-to-call-a-method-before-the-session-object-is-destroyed > (wicket is still a java framework, meaning all underlying java web things > usually just work) > If you use the HttpSession then it will work only if you have one Tomcat node. If you use a cluster then the session replication will be problematic because it will try to serialize the pointers. > > Also AFAIK the page should not get detached as long as the page is still > active, meaning it has AJAX panels on it that are still doing things, maybe > MartinG can shed some light on this; > **Any** component (a Page is a Component) that has been rendered in a http request will be detached at the end of the request. If the page is stateful then for the next request the same page instance will be reused, rendered, and detached again. If the request is Ajax then only the components added to the AjaxRequestTarget will be rendered/detached. > > Best, > > KB > > > - Ursprüngliche Mail - > > Von: "yvus" > > An: users@wicket.apache.org > > Gesendet: Mittwoch, 26. September 2018 08:52:18 > > Betreff: Re: Demo Page with User Related Data > > > Hi, > > > > Thanks for your answer. From reading your answer and the one of KB, I > have > > the feeling that the best place to be sure that the pointers get deleted > is > > to follow your suggestion: creation in Page#onConfigure, deletion in > > Page#onDetach. BUT imagine I have a panel in my page in which I have an > Ajax > > request. Therefore, if I am not mistaken, I would > > - either have to call the pointers construction again in the > > Panel#onConfigure, but that would lead to duplicates of the pointers > (which > > I don't want), > > - either keep the pointers the same as in the Parent page, but then the > > parent page onDetach would kill them. And hence my Ajax request in the > panel > > would have no access to the pointers, correct? > > > > Following your leads I would then propose to override a > > LoadableDetachableModel that would generate the pointers in the onAttach > and > > delete them in the onDetach. This would imply many re-creation of the > > pointers though... > > > > In your second suggestion, you provide a way to keep the pointers alive > > during the Http Session, but this is the case for which we don't know > when > > to delete the pointers, correct? > > > > Thanks again > > > > > > > > -- > > Sent from: > http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html > > > > - > > 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: Demo Page with User Related Data
Hi,
Here is yet another idea.
The following is a model that is a bit smarter than LoadableDetachableModel.
The extra bit is that it stores the model object in the RequestCycle's
metadata.
This way you may have N instances of this model used by N components in
your page but only the first one that asks for the model object will call
newsService.getNews().
All following components which need the model object will reuse it from the
cache (RequestCycle's metadata).
With a normal LDM you need to reuse the same instance of the model class
and this may lead to some coupling.
So, you may create an instance for the Page and another one for the Panel
that is updated via Ajax.
class NewsModel extends LoadableDetachableModel> {
private static final MetaDataKey> NEWS_CACHE_KEY = new
MetaDataKey>() { };
private final NewsService newsService;
NewsModel(final NewsService newsService) {
this.newsService = newsService;
}
@Override
protected List load() {
final RequestCycle requestCycle = RequestCycle.get();
List news = null;
if (requestCycle != null) {
news = requestCycle.getMetaData(NEWS_CACHE_KEY);
}
if (news == null) {
news = newsService.getNews(getUser());
if (requestCycle != null) {
requestCycle.setMetaData(NEWS_CACHE_KEY, news);
}
}
return news;
}
}
On Wed, Sep 26, 2018 at 10:06 AM yvus wrote:
> Hi,
>
> Thanks for your answer. From reading your answer and the one of KB, I have
> the feeling that the best place to be sure that the pointers get deleted is
> to follow your suggestion: creation in Page#onConfigure, deletion in
> Page#onDetach. BUT imagine I have a panel in my page in which I have an
> Ajax
> request. Therefore, if I am not mistaken, I would
> - either have to call the pointers construction again in the
> Panel#onConfigure, but that would lead to duplicates of the pointers (which
> I don't want),
> - either keep the pointers the same as in the Parent page, but then the
> parent page onDetach would kill them. And hence my Ajax request in the
> panel
> would have no access to the pointers, correct?
>
> Following your leads I would then propose to override a
> LoadableDetachableModel that would generate the pointers in the onAttach
> and
> delete them in the onDetach. This would imply many re-creation of the
> pointers though...
>
> In your second suggestion, you provide a way to keep the pointers alive
> during the Http Session, but this is the case for which we don't know when
> to delete the pointers, correct?
>
> Thanks again
>
>
>
> --
> Sent from:
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Demo Page with User Related Data
Hi, in case of a regular session you can use a HttpSessionListener and use the public void sessionDestroyed(HttpSessionEvent event), similar to that one here: https://stackoverflow.com/questions/7756054/how-to-call-a-method-before-the-session-object-is-destroyed (wicket is still a java framework, meaning all underlying java web things usually just work) Also AFAIK the page should not get detached as long as the page is still active, meaning it has AJAX panels on it that are still doing things, maybe MartinG can shed some light on this; Best, KB - Ursprüngliche Mail - > Von: "yvus" > An: users@wicket.apache.org > Gesendet: Mittwoch, 26. September 2018 08:52:18 > Betreff: Re: Demo Page with User Related Data > Hi, > > Thanks for your answer. From reading your answer and the one of KB, I have > the feeling that the best place to be sure that the pointers get deleted is > to follow your suggestion: creation in Page#onConfigure, deletion in > Page#onDetach. BUT imagine I have a panel in my page in which I have an Ajax > request. Therefore, if I am not mistaken, I would > - either have to call the pointers construction again in the > Panel#onConfigure, but that would lead to duplicates of the pointers (which > I don't want), > - either keep the pointers the same as in the Parent page, but then the > parent page onDetach would kill them. And hence my Ajax request in the panel > would have no access to the pointers, correct? > > Following your leads I would then propose to override a > LoadableDetachableModel that would generate the pointers in the onAttach and > delete them in the onDetach. This would imply many re-creation of the > pointers though... > > In your second suggestion, you provide a way to keep the pointers alive > during the Http Session, but this is the case for which we don't know when > to delete the pointers, correct? > > Thanks again > > > > -- > Sent from: > http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html > > - > 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: Demo Page with User Related Data
Hi, Thanks for your answer. From reading your answer and the one of KB, I have the feeling that the best place to be sure that the pointers get deleted is to follow your suggestion: creation in Page#onConfigure, deletion in Page#onDetach. BUT imagine I have a panel in my page in which I have an Ajax request. Therefore, if I am not mistaken, I would - either have to call the pointers construction again in the Panel#onConfigure, but that would lead to duplicates of the pointers (which I don't want), - either keep the pointers the same as in the Parent page, but then the parent page onDetach would kill them. And hence my Ajax request in the panel would have no access to the pointers, correct? Following your leads I would then propose to override a LoadableDetachableModel that would generate the pointers in the onAttach and delete them in the onDetach. This would imply many re-creation of the pointers though... In your second suggestion, you provide a way to keep the pointers alive during the Http Session, but this is the case for which we don't know when to delete the pointers, correct? Thanks again -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Demo Page with User Related Data
On Tue, Sep 25, 2018, 21:11 Korbinian Bachl wrote: > >> and you can use > >> onRemove() > >> to free it up as this is called when the component gets removed from the > >> page / the page itself gets removed; > >> > > > > "the page itself gets removed" > > I think this is not correct. > > > > As far as I understood all pages go after creation und usage to the page > store and get removed from that depending on the configuration? > They got removed from the store eventually but Page#onRemove() will not be called when this happens. > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Demo Page with User Related Data
>> and you can use >> onRemove() >> to free it up as this is called when the component gets removed from the >> page / the page itself gets removed; >> > > "the page itself gets removed" > I think this is not correct. > As far as I understood all pages go after creation und usage to the page store and get removed from that depending on the configuration? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Demo Page with User Related Data
On Tue, Sep 25, 2018 at 3:35 PM Korbinian Bachl <
korbinian.ba...@whiskyworld.de> wrote:
> Hi,
>
> take a look at
> https://ci.apache.org/projects/wicket/guide/8.x/single.html#_components_lifecycle
>
> You might want to move the code from constructor to
> onInitialize()
>
The benefit of using onInitialize() over the constructor is that you have
access to the parent component (getParent() != null) and to the associated
markup.
In case of a Page there is no parent.
> and you can use
> onRemove()
> to free it up as this is called when the component gets removed from the
> page / the page itself gets removed;
>
"the page itself gets removed"
I think this is not correct.
> Keep in mind that wicket stores old pages by default. In your case you
> might also want to have a look at LoadableDetachableModel, so that the
> model can react with "activation"/"passivation" of its data;
>
> The goal should usually be to not store any data at all that can be
> retrieved, so to not waste memory - said, it might be necessary in your
> case to store it with the page as it might be very expensive to (re)create
> the data, then the above onInitialize/ onRemove on the page level would be
> good to use;
>
> Best,
>
> KB
>
>
>
> - Ursprüngliche Mail -
> > Von: "yvus"
> > An: users@wicket.apache.org
> > Gesendet: Dienstag, 25. September 2018 11:22:15
> > Betreff: Demo Page with User Related Data
>
> > Dear All,
> >
> > I have the complex task to develop a webpage GUI for a java/c++ app, i.e.
> > the java app contains objects that wrap c++ classes of a .so library. For
> > example the Frame.java class wraps a corresponding c++ class frame.h
> (which
> > does the math). Therefore we call in the constructor of the Frame.java
> class
> > a c++ constructor through JNA and store the Pointer in a field.
> >
> > public class Frame {
> >private Pointer cppPointer;
> >public Frame() {
> >cppPointer = Wrapper.INSTANCE.frameConstructor(...) // JNA call
> to
> > c++ constructor retrieving the c++ pointer.
> >}
> > }
> >
> > On the webpage, I have the following scenario in which we display a demo
> > page which renders a 3d view. The user is able to displace an object
> which
> > position is determined by the fields of Frame.java and hence the c++
> > classes. Moving the object is done by changing 'values' in a form. Each
> of
> > these 'values' directly modify the Frames and hence the Frame c++-class's
> > attributes.
> >
> > In order to have the pointers created only once per page, we construct
> all
> > the pointers in the constructor of the page and store them in a model
> which
> > serializes the addresses. This allows to have the c++ side created only
> once
> > on the page. This seems fine until we have to destroy the pointers
> memory.
> >
> > How to determine when we leave the page in order to destroy the Pointers?
> > How would you manage this scenario? is it a good thing to construct the
> > pointers in the constructors of the page? When would you allow to destroy
> > the c++ allocated memory?
> >
> > Thanks
> >
> > --
> > Sent from:
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
> >
> > -
> > 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: Demo Page with User Related Data
Hi,
take a look at
https://ci.apache.org/projects/wicket/guide/8.x/single.html#_components_lifecycle
You might want to move the code from constructor to
onInitialize()
and you can use
onRemove()
to free it up as this is called when the component gets removed from the page /
the page itself gets removed;
Keep in mind that wicket stores old pages by default. In your case you might
also want to have a look at LoadableDetachableModel, so that the model can
react with "activation"/"passivation" of its data;
The goal should usually be to not store any data at all that can be retrieved,
so to not waste memory - said, it might be necessary in your case to store it
with the page as it might be very expensive to (re)create the data, then the
above onInitialize/ onRemove on the page level would be good to use;
Best,
KB
- Ursprüngliche Mail -
> Von: "yvus"
> An: users@wicket.apache.org
> Gesendet: Dienstag, 25. September 2018 11:22:15
> Betreff: Demo Page with User Related Data
> Dear All,
>
> I have the complex task to develop a webpage GUI for a java/c++ app, i.e.
> the java app contains objects that wrap c++ classes of a .so library. For
> example the Frame.java class wraps a corresponding c++ class frame.h (which
> does the math). Therefore we call in the constructor of the Frame.java class
> a c++ constructor through JNA and store the Pointer in a field.
>
> public class Frame {
>private Pointer cppPointer;
>public Frame() {
>cppPointer = Wrapper.INSTANCE.frameConstructor(...) // JNA call to
> c++ constructor retrieving the c++ pointer.
>}
> }
>
> On the webpage, I have the following scenario in which we display a demo
> page which renders a 3d view. The user is able to displace an object which
> position is determined by the fields of Frame.java and hence the c++
> classes. Moving the object is done by changing 'values' in a form. Each of
> these 'values' directly modify the Frames and hence the Frame c++-class's
> attributes.
>
> In order to have the pointers created only once per page, we construct all
> the pointers in the constructor of the page and store them in a model which
> serializes the addresses. This allows to have the c++ side created only once
> on the page. This seems fine until we have to destroy the pointers memory.
>
> How to determine when we leave the page in order to destroy the Pointers?
> How would you manage this scenario? is it a good thing to construct the
> pointers in the constructors of the page? When would you allow to destroy
> the c++ allocated memory?
>
> Thanks
>
> --
> Sent from:
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
> -
> 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: Demo Page with User Related Data
Hi,
How expensive is to "construct the pointers" ?
If it is not very expensive operation then I'd suggest you to do it in
Page#onConfigure() and to clean up in Page#onDetach().
Those two methods are called for each http request.
If it is expensive then the best I can think of is to store them in
"transient" fields so that they are null-ified when the Page is stored on
the disk.
Then in #onConfigure() you will have to make a check whether the pointers
are loaded or not.
The benefit here is that the last used page is kept as a live object in the
Http Session, so unless your user navigates to another page, or another
instance of this page, the pointers will be preloaded.
On Tue, Sep 25, 2018 at 12:43 PM yvus wrote:
> Dear All,
>
> I have the complex task to develop a webpage GUI for a java/c++ app, i.e.
> the java app contains objects that wrap c++ classes of a .so library. For
> example the Frame.java class wraps a corresponding c++ class frame.h (which
> does the math). Therefore we call in the constructor of the Frame.java
> class
> a c++ constructor through JNA and store the Pointer in a field.
>
> public class Frame {
> private Pointer cppPointer;
> public Frame() {
> cppPointer = Wrapper.INSTANCE.frameConstructor(...) // JNA call to
> c++ constructor retrieving the c++ pointer.
> }
> }
>
> On the webpage, I have the following scenario in which we display a demo
> page which renders a 3d view. The user is able to displace an object which
> position is determined by the fields of Frame.java and hence the c++
> classes. Moving the object is done by changing 'values' in a form. Each of
> these 'values' directly modify the Frames and hence the Frame c++-class's
> attributes.
>
> In order to have the pointers created only once per page, we construct all
> the pointers in the constructor of the page and store them in a model which
> serializes the addresses. This allows to have the c++ side created only
> once
> on the page. This seems fine until we have to destroy the pointers memory.
>
> How to determine when we leave the page in order to destroy the Pointers?
> How would you manage this scenario? is it a good thing to construct the
> pointers in the constructors of the page? When would you allow to destroy
> the c++ allocated memory?
>
> Thanks
>
> --
> Sent from:
> http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
