How to flush(?) page without using setResponsePage
Hi, our application has a login form on every page, defined in a Base WebPage. So far we have to use setResponsePage(getApplication().getHomePage()); to update the page, otherwise it looks like the login didn't work, even if it did. But we don't want to go to the homepage, the user wants to stay on the current page instead. How can I flush the current page? Thanks Jörn Zaefferer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to flush(?) page without using setResponsePage
If you don't set a responsepage the current page will be served again. For determining what might be the problem of the login not working we need to see some code and a better description of what is not working. Maurice On Mon, Mar 10, 2008 at 11:39 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Hi, our application has a login form on every page, defined in a Base WebPage. So far we have to use setResponsePage(getApplication().getHomePage()); to update the page, otherwise it looks like the login didn't work, even if it did. But we don't want to go to the homepage, the user wants to stay on the current page instead. How can I flush the current page? Thanks Jörn Zaefferer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to flush(?) page without using setResponsePage
Ok. An example for the basic problem: There is a label that displays Loggein as ... when the user is logged in, and Not logged in when he's not. If the user logins in using the login form, the label doesn't change, unless I use setResponsePage. I figured out that I can use setResponsePage(getPage().getClass()); to keep the user on the same page, but that still looks like a workaround to me, not a solution. Jörn On Mon, Mar 10, 2008 at 11:46 AM, Maurice Marrink [EMAIL PROTECTED] wrote: If you don't set a responsepage the current page will be served again. For determining what might be the problem of the login not working we need to see some code and a better description of what is not working. Maurice On Mon, Mar 10, 2008 at 11:39 AM, Jörn Zaefferer [EMAIL PROTECTED] wrote: Hi, our application has a login form on every page, defined in a Base WebPage. So far we have to use setResponsePage(getApplication().getHomePage()); to update the page, otherwise it looks like the login didn't work, even if it did. But we don't want to go to the homepage, the user wants to stay on the current page instead. How can I flush the current page? Thanks Jörn Zaefferer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to flush(?) page without using setResponsePage
The way you describe it, it sounds to me like you are not properly
using a model to update the label.
I am guessing you are doing something like new Label(id,Logged in)
or new Label(id,new Model(Logged in)).
What you have to remember is that you are in the constructor here,
rendering the same page does not trigger a new page object and thus no
constructor call.
In order to solve this you need a model to dynamically return whether
a user is logged in or not.
Something like this should do the job:
class MyModel extends loadableDetachableModel
{
public Object load()
{
//pseudo code:
if(Session.get().getUser()!=null)
return Logged in;
return Not logged in;
}
}
See
http://www.theserverside.com/tt/articles/article.tss?l=IntroducingApacheWicket
for an introduction to Wicket including models
Maurice
On Mon, Mar 10, 2008 at 1:10 PM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
Ok. An example for the basic problem:
There is a label that displays Loggein as ... when the user is
logged in, and Not logged in when he's not. If the user logins in
using the login form, the label doesn't change, unless I use
setResponsePage.
I figured out that I can use setResponsePage(getPage().getClass()); to
keep the user on the same page, but that still looks like a workaround
to me, not a solution.
Jörn
On Mon, Mar 10, 2008 at 11:46 AM, Maurice Marrink [EMAIL PROTECTED] wrote:
If you don't set a responsepage the current page will be served again.
For determining what might be the problem of the login not working we
need to see some code and a better description of what is not working.
Maurice
On Mon, Mar 10, 2008 at 11:39 AM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
Hi,
our application has a login form on every page, defined in a Base
WebPage. So far we have to use
setResponsePage(getApplication().getHomePage()); to update the page,
otherwise it looks like the login didn't work, even if it did. But we
don't want to go to the homepage, the user wants to stay on the
current page instead.
How can I flush the current page?
Thanks
Jörn Zaefferer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to flush(?) page without using setResponsePage
Kudos Maurice! That was the one little thing that fixed most of the
issue I was having with Wicket. I've rewrote now most of the code,
using models and overwriting isVisible methods, works much better now.
Thanks
Jörn
On Mon, Mar 10, 2008 at 1:58 PM, Maurice Marrink [EMAIL PROTECTED] wrote:
The way you describe it, it sounds to me like you are not properly
using a model to update the label.
I am guessing you are doing something like new Label(id,Logged in)
or new Label(id,new Model(Logged in)).
What you have to remember is that you are in the constructor here,
rendering the same page does not trigger a new page object and thus no
constructor call.
In order to solve this you need a model to dynamically return whether
a user is logged in or not.
Something like this should do the job:
class MyModel extends loadableDetachableModel
{
public Object load()
{
//pseudo code:
if(Session.get().getUser()!=null)
return Logged in;
return Not logged in;
}
}
See
http://www.theserverside.com/tt/articles/article.tss?l=IntroducingApacheWicket
for an introduction to Wicket including models
Maurice
On Mon, Mar 10, 2008 at 1:10 PM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
Ok. An example for the basic problem:
There is a label that displays Loggein as ... when the user is
logged in, and Not logged in when he's not. If the user logins in
using the login form, the label doesn't change, unless I use
setResponsePage.
I figured out that I can use setResponsePage(getPage().getClass()); to
keep the user on the same page, but that still looks like a workaround
to me, not a solution.
Jörn
On Mon, Mar 10, 2008 at 11:46 AM, Maurice Marrink [EMAIL PROTECTED]
wrote:
If you don't set a responsepage the current page will be served again.
For determining what might be the problem of the login not working we
need to see some code and a better description of what is not working.
Maurice
On Mon, Mar 10, 2008 at 11:39 AM, Jörn Zaefferer
[EMAIL PROTECTED] wrote:
Hi,
our application has a login form on every page, defined in a Base
WebPage. So far we have to use
setResponsePage(getApplication().getHomePage()); to update the page,
otherwise it looks like the login didn't work, even if it did. But
we
don't want to go to the homepage, the user wants to stay on the
current page instead.
How can I flush the current page?
Thanks
Jörn Zaefferer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
