This was a comment Jonathan made regarding another message he sent (I
believe) where he said something about backporting to 1.1. But that is
not necessary because HEAD is the current stream for 1.1. So no
backporting is necessary for 1.1.
Martijn
David Liebeherr wrote:
Sorry, i don't unders
Sorry, i don't understand fully.
Does this mean i have to simply wait for the final 1.1 version?
Thanks,
Dave
Jonathan Locke wrote:
head==1.1
do nothing
David Liebeherr wrote:
Johan Compagner wrote:
David Liebeherr wrote:
I think i will need to do it without a hardcoded redirect bc i ne
head==1.1
do nothing
David Liebeherr wrote:
Johan Compagner wrote:
David Liebeherr wrote:
I think i will need to do it without a hardcoded redirect bc i need
to give the HomePage a parameter so that it can display a "You have
been logged out" message on the login screen.
But i don't kno
Johan Compagner wrote:
David Liebeherr wrote:
I think i will need to do it without a hardcoded redirect bc i need to
give the HomePage a parameter so that it can display a "You have been
logged out" message on the login screen.
But i don't know how to do that with direct URL redirect.
I wou
David Liebeherr wrote:
I think i will need to do it without a hardcoded redirect bc i need to
give the HomePage a parameter so that it can display a "You have been
logged out" message on the login screen.
But i don't know how to do that with direct URL redirect.
I would like to have someting
I think i will need to do it without a hardcoded redirect bc i need to give the HomePage a parameter
so that it can display a "You have been logged out" message on the login screen.
But i don't know how to do that with direct URL redirect.
I would like to have someting like
class Login extends W
We don't need to backport it to 1.1 because head is still 1.1
backporting to 1.0 is something we don't do anymore automatically, only
on special request.
For developerment you should be able to use head just fine.
You only see some changes (and fixes that you have to do then) a bit
earlier...
i think someone could back-port it to 1.1 and/or 1.0 eventually.
for now, i think it's smarter to stick with the onEndRequest() method i
showed earlier.
HEAD can be pretty unstable. if you want to ensure this backport gets
done, i'd file a bug.
David Liebeherr wrote:
would it be a good ide
would it be a good idea to use a cvs version?
how instable/weak is the cvs version?
i would realy love to use this new behaviour...
thanx,
Dave
BTW: I have a more than one Apps on a domain so this behaviour would be much better in my
environment than redirecting to "/". so thanks for writing
this is tested and checked into head now...
Jonathan Locke wrote:
ooh. i've got a perfect fix for this...
Jonathan Locke wrote:
heh. also, it needs to be implemented that way or currently working
code that calls
Session.invalidate() in onEndRequest() method would actually break!
Jona
ooh. i've got a perfect fix for this...
Jonathan Locke wrote:
heh. also, it needs to be implemented that way or currently working
code that calls
Session.invalidate() in onEndRequest() method would actually break!
Jonathan Locke wrote:
btw, since onEndRequest is actually called last i
heh. also, it needs to be implemented that way or currently working
code that calls
Session.invalidate() in onEndRequest() method would actually break!
Jonathan Locke wrote:
btw, since onEndRequest is actually called last in the sequence, this
flag
check and invalidate functionality shoul
btw, since onEndRequest is actually called last in the sequence, this flag
check and invalidate functionality should /not/ be added in
internalOnEndRequest.
it should be done at line 448 of RequestCycle.java, just before the
thread is detached
from the request. that way, users can still do wic
yes. that makes good sense to me. i think we should add a note to the
method however that this is what will happen (flag and invalidate on end
of request) and why... and that if anyone really needs to invalidate the
request immediately, they should do that through the underlying servlet
object.
sounds a like a good idea to me. It simplifies the usage for users.
Juergen
On 8/7/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
> Why is Session.invalidate() immediately also making the websession invalid?
> Why aren't we just setting a flag (that we are already doing)
> And then on the end of
Why is Session.invalidate() immediately also making the websession invalid?
Why aren't we just setting a flag (that we are already doing)
And then on the end of everything we are invalidating the sesssion.
This way no session is invalid errors will happen.
johan
Jonathan Locke wrote:
we need
you may take a look at the sign2 examples as well
Juergen
On 8/7/05, Matej Knopp <[EMAIL PROTECTED]> wrote:
> getWebRequestCycle().getWebRequest().getContextPath()+getWebRequestCycle().getWebRequest().getServletPath()
> should do it.
>
> -Matej
>
> David Liebeherr wrote:
> > Is there a way to g
getWebRequestCycle().getWebRequest().getContextPath()+getWebRequestCycle().getWebRequest().getServletPath()
should do it.
-Matej
David Liebeherr wrote:
Is there a way to get the url of the current App/servlet?
I don't realy like the idea of a hardcoded url...
Thanx,
Dave
Jonathan Locke wrote:
what are you talking about? the url "/" is always the root of whatever
website you are using. unless you have a multi-app website, i'd say
app/servlet is hardcoding it.
David Liebeherr wrote:
Is there a way to get the url of the current App/servlet?
I don't realy like the idea of a hardco
it's won't. redirect(String) will always just redirect to the String url.
Matej Knopp wrote:
Much much nicer, indeed.
I just wanted to bypass calls to wicket response wrapper, because I
wasn't sure that it won't touch the session. I should at least look at
it :)
-Matej
Jonathan Locke wr
Is there a way to get the url of the current App/servlet?
I don't realy like the idea of a hardcoded url...
Thanx,
Dave
Jonathan Locke wrote:
yup. worked for me.
Jonathan Locke wrote:
uh, in fact, i think you can just say this:
getResponse().redirect("/")
much cleaner that way.
Jonatha
Much much nicer, indeed.
I just wanted to bypass calls to wicket response wrapper, because I
wasn't sure that it won't touch the session. I should at least look at it :)
-Matej
Jonathan Locke wrote:
uh, in fact, i think you can just say this:
getResponse().redirect("/")
much cleaner that
yup. worked for me.
Jonathan Locke wrote:
uh, in fact, i think you can just say this:
getResponse().redirect("/")
much cleaner that way.
Jonathan Locke wrote:
that's about what i was going to suggest you try. i think it can be
a little cleaner. maybe something more like this:
getR
uh, in fact, i think you can just say this:
getResponse().redirect("/")
much cleaner that way.
Jonathan Locke wrote:
that's about what i was going to suggest you try. i think it can be a
little cleaner. maybe something more like this:
getRequestCycle().getResponse().redirect("/");
reg
that's about what i was going to suggest you try. i think it can be a
little cleaner. maybe something more like this:
getRequestCycle().getResponse().redirect("/");
regardless, you can't do session-related stuff once the session is
invalidated in wicket because the session holds all the pa
This is the way I do it. After logout it redirect to the home page
(Servlet name without any arguments)
public class LogoutPage extends BasePage {
public LogoutPage() {
}
protected void onEndRequest() {
getSession().invalidate();
try {
getWebRequestCycle().getWebRes
i got some problems to understand how this works.
I just want to provide a logout-link which invalidates the session and then _automticly_ redirects
the user to the HomePage. Is this possible?
I tried that:
public class Logout extends WebPage {
public Logout() {
setResponsePage(getA
we need to add this to the faq.
you have to invalidate the session in onEndRequest() like this:
@Override
protected void onEndRequest()
{
getSession().invalidate();
}
David Liebeherr wrote:
add(new Link("logout") {
public void onClick() {
add(new Link("logout") {
public void onClick() {
getSession().invalidate();
redirectToInterceptPage(newPage(getApplication().getPages().getHomePage()));
}
});
results in
java.lang.IllegalStateExcept
just invalidate the session
Juergen
On 8/7/05, David Liebeherr <[EMAIL PROTECTED]> wrote:
> Hi all!
>
> How can i end a session and start a new one for logout function for exmaple?
> Is there a method in wicket for this?
>
> Thanx,
> Dave
>
>
>
Hi all!
How can i end a session and start a new one for logout function for exmaple?
Is there a method in wicket for this?
Thanx,
Dave
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisc
31 matches
Mail list logo
