AppFoundation view module reset

I’m using the appfoundation add-on. When I leave a page (a.k.a. view) like this:

ViewHandler.deactivateView(Foo.class, this);
ViewHandler.activateView(Foo2.class, this);

I also call the finalize() method before: this.finalize();
I also remove all reference to it.

The problem is when I want to get back to Foo, I want a new Foo object, but I get the old one, and the constructor doesn’t get called, so my app doesn’t work properly. Is there a workaround, or can I somehow reset the view? I even logout than login again, but I still get the same Foo instance :frowning:

The instance of your view is stored as a field in the ViewItem within the ViewHandler. You have two options - if you really want to discard the reference to the view, you need to get the ViewItem and reset the view instance in it


ViewItem viewItem = ViewHandler.getViewItem(Foo.class);
viewItem.setView(null);

How it was designed to be used, is that you would use the activated() method in the view interface. This method is called whenever the view is activated. So instead of rebuilding your view in the view’s constructor, do it in the activated method.

Anyway, I’ve added a new
task
for creating a helper for removing the view references, if that is really what one wants to do.

Thank you for the help.

I just simply inserted the code you give me in the deactivated method, and looks like it works fine.
(BTW I have other views, I only need one of them to be destroyed after leaving it, I know it’s unusual :slight_smile: )

I left activated() blank, as I need to call the super constructor anyway, because class extends AbstractView

I also wanted to ask, why do you have to give at least one parameter to the activated, deactivated method?

ViewHandler.activateView(Foo.class, this);

If i remove the the second reference to the object, my views doesn’t get to be activated. But if I understand it right, the activated/deactivated method uses that second parameter, but I don’t have any code in there. So it’s strange to me, that it doesn’t work properly without a second parameter. Although I might have done something wrong when removing all the this reference (maybe left it there somewhere…).

Anyway, I’m just asking this out of curiosity, and because someone might ask why do I have to use that parameter, then I could give him real answer instead of something made up :slight_smile:

Your add-on was a great help in my project (still is, but I hope I’ll be finished soon).

I needed to extend the User class, but for me to do that, I would have to extend a whole other classes, so I used your source code, leave everything as it is, and comment the part I’ve made change to. Hope that’s OK?

Thanks for your help again, and for writing this great add-on! Very useful, I’ve use all modules except i18n, as so far I’ve only have one language supported :slight_smile:

Only the first parameter is required, so ViewHandler.activateView(Foo.class); should be just fine.

Actually, with the current implementation, extending the User class can be a bit painful, but it does work, you’ll just have to copy&paste the protected username and password fields to your extended class in order for the authentication mechanism to work. I intend to improve significantly the possibility to extends AppFoundation in upcoming releases, but that won’t be anytime soon.