I have a page which displays a [login box] (if not logged in) or an info box
[user name|logout link] if logged in.

I implemented this as follows:

        User user = BaseSession.get().getLoggedInUser();
        if (user == null)
        {
            add(new Login("login"));
        }
        else
        {
            add(new CurrentProfile("login"));
        }

Both Login and CurrentProfile are subclasses of "Panel".  When the login
form is submitted or the logout link is submitted, in order to get the page
to re-render, I had to use this code:

        setResponsePage(getPage().getClass()); // need to use "class" so
page is re-rendered

As a new wicket user, I'd like a clarification on why this is necessary.  If
I used this code:

       setResponsePage(getPage()); 

... which appears to be the default behavior if setResponsePage() isn't
called ... then the page is simply displayed without re-rendering (e.g.,
after login, the login box is still shown).  So, my question is what's the
difference between the two?  Is there a way to mark a page as "needing
re-rendering"?  Is my solution the "correct" way in Wicket?

This also raises the question about how many pages are stored in the page
map.  For example, if I were to login and logout 10 times in a row ... would
there be 20 pages in the page map?  Is there a way to clear out the page map
for a page?

In my case, I invalidate the session on logout, so the above case isn't an
issue in this exact case.  I'm more concerned about someone who navigates my
site and visits hundreds of pages.  How do I keep the session from filling
up with old pages?

Finally, is there a best practice to debug/monitor session size and page map
size?

Thanks,

-Doug
-- 
View this message in context: 
http://www.nabble.com/clarification-on-page-versioning-tp16783638p16783638.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to